{"threads":[{"id":"e1","k":"e","s":"cryptography","t":"Bitcoin P2P e-cash paper","u":"http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html","su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/1/","m":[{"f":"Satoshi Nakamoto","d":1225476600,"b":[["t","I've been working on a new electronic cash system that's fully\npeer-to-peer, with no trusted third party.\n\nThe paper is available at:\nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe main properties:\n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also powers the\n    network to prevent double-spending.\n\nBitcoin: A Peer-to-Peer Electronic Cash System\n\nAbstract.  A purely peer-to-peer version of electronic cash would\nallow online payments to be sent directly from one party to another\nwithout the burdens of going through a financial institution.\nDigital signatures provide part of the solution, but the main\nbenefits are lost if a trusted party is still required to prevent\ndouble-spending.  We propose a solution to the double-spending\nproblem using a peer-to-peer network.  The network timestamps\ntransactions by hashing them into an ongoing chain of hash-based\nproof-of-work, forming a record that cannot be changed without\nredoing the proof-of-work.  The longest chain not only serves as\nproof of the sequence of events witnessed, but proof that it came\nfrom the largest pool of CPU power.  As long as honest nodes control\nthe most CPU power on the network, they can generate the longest\nchain and outpace any attackers.  The network itself requires\nminimal structure.  Messages are broadcasted on a best effort basis,\nand nodes can leave and rejoin the network at will, accepting the\nlongest proof-of-work chain as proof of what happened while they\nwere gone.\n\nFull paper at:\nhttp://www.bitcoin.org/bitcoin.pdf\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html","s":1,"n":1,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/1/","qt":["I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.","The main properties: \n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also powers the network to prevent double-spending."],"qc":["bitcoin-design"],"od":"Fri Oct 31 14:10:00 EDT 2008"},{"f":"James A. Donald","d":1225669583,"b":[["q","I've been working on a new electronic cash system that's fully\npeer-to-peer, with no trusted third party.\n\nThe paper is available at:\nhttp://www.bitcoin.org/bitcoin.pdf","Satoshi Nakamoto wrote:"],["t","We very, very much need such a system, but the way I understand your\nproposal, it does not seem to scale to the required size.\n\nFor transferable proof of work tokens to have value, they must have\nmonetary value.  To have monetary value, they must be transferred within\na very large network - for example a file trading network akin to\nbittorrent.\n\nTo detect and reject a double spending event in a timely manner, one\nmust have most past transactions of the coins in the transaction, which,\n  naively implemented, requires each peer to have most past\ntransactions, or most past transactions that occurred recently. If\nhundreds of millions of people are doing transactions, that is a lot of\nbandwidth - each must know all, or a substantial part thereof."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html","od":"Sun Nov  2 18:46:23 EST 2008"},{"f":"Satoshi Nakamoto","d":1225676263,"b":[["q","Satoshi Nakamoto wrote:\n> I've been working on a new electronic cash system that's fully\n> peer-to-peer, with no trusted third party.\n>\n> The paper is available at:\n> http://www.bitcoin.org/bitcoin.pdf\n\nWe very, very much need such a system, but the way I understand your\nproposal, it does not seem to scale to the required size.\n\nFor transferable proof of work tokens to have value, they must have\nmonetary value.  To have monetary value, they must be transferred within\na very large network - for example a file trading network akin to\nbittorrent.\n\nTo detect and reject a double spending event in a timely manner, one\nmust have most past transactions of the coins in the transaction, which,\n naively implemented, requires each peer to have most past\ntransactions, or most past transactions that occurred recently. If\nhundreds of millions of people are doing transactions, that is a lot of\nbandwidth - each must know all, or a substantial part thereof."],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html","s":1,"n":2,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/2/","qt":["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."],"qc":["double-spending","nodes"],"od":"Sun Nov  2 20:37:43 EST 2008"},{"f":"John Levine","d":1225719159,"b":[["q","As long as honest nodes control the most CPU power on the network,\nthey can generate the longest chain and outpace any attackers."],["t","But they don't.  Bad guys routinely control zombie farms of 100,000\nmachines or more.  People I know who run a blacklist of spam sending\nzombies 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\n-- the good guys have vastly less computational firepower than the bad\nguys.\n\nI also have my doubts about other issues, but this one is the killer.\n\nR's,\nJohn"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014817.html","od":"Mon Nov  3 08:32:39 EST 2008"},{"f":"Satoshi Nakamoto","d":1225729429,"b":[["q","> As long as honest nodes control the most CPU power on the network,\n> they can generate the longest chain and outpace any attackers.\n\nBut they don't.  Bad guys routinely control zombie farms of 100,000\nmachines or more.  People I know who run a blacklist of spam sending\nzombies 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\n-- the good guys have vastly less computational firepower than the bad\nguys."],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014818.html","s":1,"n":3,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/3/","qt":["The requirement is that the good guys collectively have more CPU power than any single attacker.","There 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.","Even 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.","The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead."],"qc":["mining"],"od":"Mon Nov  3 11:23:49 EST 2008"},{"f":"James A. Donald","d":1225743613,"b":[["t","James A. Donald:"],["q","> To detect and reject a double spending event in a\n> timely manner, one must have most past transactions\n> of the coins in the transaction, which, naively\n> implemented, requires each peer to have most past\n> transactions, or most past transactions that\n> occurred recently. If hundreds of millions of people\n> are doing transactions, that is a lot of bandwidth -\n> each must know all, or a substantial part thereof."],["q","Long before the network gets anywhere near as large as\nthat, it would be Safe for users to use Simplified\nPayment Verification (section 8) to check for double\nspending, which only requires having the chain of\nblock headers,","Satoshi Nakamoto wrote:"],["t","If I understand Simplified Payment Verification\ncorrectly:\n\nNew coin issuers need to store all coins and all recent\ncoin transfers.\n\nThere are many new coin issuers, as many as want to be\nissuers, but far more coin users.\n\nOrdinary entities merely transfer coins.  To see if a\ncoin transfer is OK, they report it to one or more new\ncoin issuers and see if the new coin issuer accepts it.\nNew coin issuers check transfers of old coins so that\ntheir new coins have valid form, and they report the\noutcome of this check so that people will report their\ntransfers to the new coin issuer.\n\nIf someone double spends a coin, and one expenditure is\nreported to one new coin issuer, and the other\nsimultaneously reported to another new coin issuer, then\nboth issuers to swifly agree on a unique sequence order\nof payments.  This, however, is a non trivial problem of\na massively distributed massive database, a notoriously\ntricky problem, for which there are at present no peer\nto peer solutions.  Obiously it is a solvable problem,\npeople solve it all the time, but not an easy problem.\nPeople fail to solve it rather more frequently.\n\n  But let us suppose that the coin issue network is\ndominated by a small number of issuers as seems likely.\n\nIf a small number of entities are issuing new coins,\nthis is more resistant to state attack that with a\nsingle issuer, but the government regularly attacks\nfinancial networks, with the financial collapse ensuing\nfrom the most recent attack still under way as I write\nthis.\n\nGovernment sponsored enterprises enter the business, in\ndue course bad behavior is made mandatory, and the evil\nfinancial network is bigger than the honest financial\nnetwork, with the result that even though everyone knows\nwhat is happening, people continue to use the paper\nissued by the evil financial network, because of network\neffects - the big, main issuers, are the issuers you use\nif you want to do business.\n\nThen knowledgeable people complain that the evil\nfinancial network is heading for disaster, that the\ngovernment sponsored enterprises are about to cause a\n\"collapse of the total financial system\", as Wallison\nand Alan Greenspan complained in 2005, the government\ndebates shrinking the evil government sponsored\nenterprises, as with \"S. 190 [109th]: Federal Housing\nEnterprise Regulatory Reform Act of 2005\" but they find\neasy money too seductive, and S. 190 goes down in flames\nbefore a horde of political activists chanting that easy\nmoney is sound, and opposing it is racist, nazi,\nignorant, and generally hateful, the recent S. 190\ndebate on limiting portfolios (bond issue supporting dud\nmortgages) by government sponsored enterprises being a\nperfect reprise of the debates on limiting the issue of\nnew assignats in the 1790s.\n\nThe big and easy government attacks on money target a\nsingle central money issuer, as with the first of the\nmodern political attacks, the French Assignat of 1792,\nbut in the late nineteenth century political attacks on\nfinancial networks began, as for example the Federal\nreserve act of 1913, the goal always being to wind up\nthe network into a single too big to fail entity, and\nthey have been getting progressively bigger, more\nserious, and more disastrous, as with the most recent\none.  Each attack is hugely successful, and after the\ncataclysm that the attack causes the attackers are\nhailed as saviors of the poor, the oppressed, and the\nnation generally, and the blame for the the bad\nconsequences is dumped elsewhere, usually on Jews,\ngreedy bankers, speculators, etc, because such attacks\nare difficult for ordinary people understand.  I have\ntrouble understanding your proposal - ordinary users\nwill be easily bamboozled by a government sponsored\nsecurity update.  Further, when the crisis hits, to\ndisagree with the line, to doubt that the regulators are\nright, and the problem is the evil speculators, becomes\npolitical suicide, as it did in America in 2007,\nsometimes physical suicide, as in Weimar Germany.\n\nStill, it is better, and more resistant to attack by\ngovernment sponsored enterprises, than anything I have\nseen so far."],["q","Visa processed 37 billion transactions in FY2008, or\nan average of 100 million transactions per day.  That\nmany transactions would take 100GB of bandwidth, or\nthe size of 12 DVD or 2 HD quality movies, or about\n$18 worth of bandwidth at current prices."],["q","If the network were to get that big, it would take\nseveral years, and by then, sending 2 HD movies over\nthe Internet would probably not seem like a big deal."],["t","If there were a hundred or a thousand money issuers by\nthe time the government attacks, the kind of government\nattacks on financial networks that we have recently seen\nmight well be more difficult.\n\nBut I think we need to concern ourselves with minimizing\nthe data and bandwidth required by money issuers - for\nsmall coins, the protocol seems wasteful.  It would be\nnice to have the full protocol for big coins, and some\nshortcut for small coins wherein people trust account\nbased money for small amounts till they get wrapped up\ninto big coins.\n\nThe smaller the data storage and bandwidth required for\nmoney issuers, the more resistant the system is the kind\nof government attacks on financial networks that we have\nrecently seen."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014819.html","od":"Mon Nov  3 15:20:13 EST 2008"},{"f":"Ray Dillinger","d":1225948477,"b":[["q","If I understand Simplified Payment Verification\ncorrectly:\n\nNew coin issuers need to store all coins and all recent\ncoin transfers.\n\nThere are many new coin issuers, as many as want to be\nissuers, but far more coin users.\n\nOrdinary entities merely transfer coins.  To see if a\ncoin transfer is OK, they report it to one or more new\ncoin issuers and see if the new coin issuer accepts it.\nNew coin issuers check transfers of old coins so that\ntheir new coins have valid form, and they report the\noutcome of this check so that people will report their\ntransfers to the new coin issuer.","On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote:"],["t","I think the real issue with this system is the market\nfor bitcoins.\n\nComputing proofs-of-work have no intrinsic value.  We\ncan have a limited supply curve (although the \"currency\"\nis inflationary at about 35% as that's how much faster\ncomputers get annually) but there is no demand curve\nthat intersects it at a positive price point.\n\nI know the same (lack of intrinsic value) can be said of\nfiat currencies, but an artificial demand for fiat\ncurrencies is created by (among other things) taxation\nand legal-tender laws.  Also, even a fiat currency can\nbe an inflation hedge against another fiat currency's\nhigher rate of inflation.   But in the case of bitcoins\nthe inflation rate of 35% is almost guaranteed by the\ntechnology, there are no supporting mechanisms for\ntaxation, and no legal-tender laws.  People will not\nhold assets in this highly-inflationary currency if\nthey can help it.\n\n   Bear"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014822.html","od":"Thu Nov  6 00:14:37 EST 2008"},{"f":"Satoshi Nakamoto","d":1226002540,"b":[["q","[Lengthy exposition of vulnerability of a systm to use-of-force\nmonopolies ellided.]\n\nYou will not find a solution to political problems in cryptography."],["t","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.\n\nSatoshi"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014823.html","s":1,"n":4,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/4/","qt":["Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.","Governments 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."],"qc":["government","motives","p2p-networks"],"od":"Thu Nov  6 15:15:40 EST 2008"},{"f":"Hal Finney","d":1226101212,"b":[["t","Bitcoin seems to be a very promising idea. I like the idea of basing\nsecurity on the assumption that the CPU power of honest participants\noutweighs that of the attacker. It is a very modern notion that exploits\nthe power of the long tail. When Wikipedia started I never thought it\nwould work, but it has proven to be a great success for some of the\nsame reasons.\n\nI also do think that there is potential value in a form of unforgeable\ntoken whose production rate is predictable and can't be influenced\nby corrupt parties. This would be more analogous to gold than to fiat\ncurrencies. Nick Szabo wrote many years ago about what he called \"bit\ngold\"[1] and this could be an implementation of that concept. There have\nalso been proposals for building light-weight anonymous payment schemes on\ntop of heavy-weight non-anonymous systems, so Bitcoin could be leveraged\nto allow for anonymity even beyond the mechanisms discussed in the paper.\n\nUnfortunately I am having trouble fully understanding the system. The\npaper describes key concepts and some data structures, but does not\nclearly specify the various rules and verifications that the participants\nin the system would have to follow.\n\nIn particular I don't understand exactly what verifications P2P nodes\nperform when they receive new blocks from other nodes, and how they\nhandle transactions that have been broadcast to them. For example, it\nis mentioned that if a broadcast transaction does not reach all nodes,\nit is OK, as it will get into the block chain before long. How does this\nhappen - what if the node that creates the \"next\" block (the first node\nto find the hashcash collision) did not hear about the transaction,\nand then a few more blocks get added also by nodes that did not hear\nabout that transaction? Do all the nodes that did hear it keep that\ntransaction around, hoping to incorporate it into a block once they get\nlucky enough to be the one which finds the next collision?\n\nOr for example, what if a node is keeping two or more chains around as\nit waits to see which grows fastest, and a block comes in for chain A\nwhich would include a double-spend of a coin that is in chain B? Is that\nchecked for or not? (This might happen if someone double-spent and two\ndifferent sets of nodes heard about the two different transactions with\nthe same coin.)\n\nThis kind of data management, and the rules for handling all the packets\nthat are flowing around is largely missing from the paper.\n\nI also don't understand exactly how double-spending, or cancelling\ntransactions, is accomplished by a superior attacker who is able to muster\nmore computing power than all the honest participants. I see that he can\ncreate new blocks and add them to create the longest chain, but how can\nhe erase or add old transactions in the chain? As the attacker sends out\nhis new blocks, aren't there consistency checks which honest nodes can\nperform, to make sure that nothing got erased? More explanation of this\nattack would be helpful, in order to judge the gains to an attacker from\nthis, versus simply using his computing power to mint new coins honestly.\n\nAs far as the spending transactions, what checks does the recipient of a\ncoin have to perform? Does she need to go back through the coin's entire\nhistory of transfers, and make sure that every transaction on the list is\nindeed linked into the \"timestamp\" block chain? Or can she just do the\nlatest one? Do the timestamp nodes check transactions, making sure that\nthe previous transaction on a coin is in the chain, thereby enforcing\nthe rule that all transactions in the chain represent valid coins?\n\nSorry about all the questions, but as I said this does seem to be a\nvery promising and original idea, and I am looking forward to seeing\nhow the concept is further developed. It would be helpful to see a more\nprocess oriented description of the idea, with concrete details of the\ndata structures for the various objects (coins, blocks, transactions),\nthe data which is included in messages, and algorithmic descriptions\nof the procedures for handling the various events which would occur in\nthis system. You mentioned that you are working on an implementation,\nbut I think a more formal, text description of the system would be a\nhelpful next step.\n\nHal Finney\n\n[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html","od":"Fri Nov  7 18:40:12 EST 2008"},{"f":"Satoshi Nakamoto","d":1226170478,"b":[["t","Ray Dillinger:"],["q","the \"currency\" is inflationary at about 35%\nas that's how much faster computers get annually\n... the inflation rate of 35% is almost guaranteed\nby the technology"],["t","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.\"\n\nAs 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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014831.html","s":1,"n":5,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/5/","qt":["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.","The 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. Coins have to get initially distributed somehow, and a constant rate seems like the best formula."],"qc":["bitcoin-economics","difficulty","mining"],"od":"Sat Nov  8 13:54:38 EST 2008"},{"f":"Satoshi Nakamoto","d":1226195928,"b":[["q","it is mentioned that if a broadcast transaction does not reach all nodes,\nit is OK, as it will get into the block chain before long. How does this\nhappen - what if the node that creates the \"next\" block (the first node\nto find the hashcash collision) did not hear about the transaction,\nand then a few more blocks get added also by nodes that did not hear\nabout that transaction? Do all the nodes that did hear it keep that\ntransaction around, hoping to incorporate it into a block once they get\nlucky enough to be the one which finds the next collision?","Hal Finney wrote:"],["t","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."],["q","Or for example, what if a node is keeping two or more chains around as\nit waits to see which grows fastest, and a block comes in for chain A\nwhich would include a double-spend of a coin that is in chain B? Is that\nchecked for or not? (This might happen if someone double-spent and two\ndifferent sets of nodes heard about the two different transactions with\nthe same coin.)"],["t","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."],["q","I also don't understand exactly how double-spending, or cancelling\ntransactions, is accomplished by a superior attacker who is able to muster\nmore computing power than all the honest participants. I see that he can\ncreate new blocks and add them to create the longest chain, but how can\nhe erase or add old transactions in the chain? As the attacker sends out\nhis new blocks, aren't there consistency checks which honest nodes can\nperform, to make sure that nothing got erased? More explanation of this\nattack would be helpful, in order to judge the gains to an attacker from\nthis, versus simply using his computing power to mint new coins honestly."],["t","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."],["q","As far as the spending transactions, what checks does the recipient of a\ncoin have to perform? Does she need to go back through the coin's entire\nhistory of transfers, and make sure that every transaction on the list is\nindeed linked into the \"timestamp\" block chain? Or can she just do the\nlatest one? "],["t","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."],["q","Do the timestamp nodes check transactions, making sure that\nthe previous transaction on a coin is in the chain, thereby enforcing\nthe rule that all transactions in the chain represent valid coins?"],["t","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."],["q","Sorry about all the questions, but as I said this does seem to be a\nvery promising and original idea, and I am looking forward to seeing\nhow the concept is further developed. It would be helpful to see a more\nprocess oriented description of the idea, with concrete details of the\ndata structures for the various objects (coins, blocks, transactions),\nthe data which is included in messages, and algorithmic descriptions\nof the procedures for handling the various events which would occur in\nthis system. You mentioned that you are working on an implementation,\nbut I think a more formal, text description of the system would be a\nhelpful next step."],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014832.html","s":1,"n":6,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","qt":["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.","Receivers 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.","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.","It 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.","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.","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."],"qc":["double-spending","mining","nodes","proof-of-work","transactions"],"od":"Sat Nov  8 20:58:48 EST 2008"},{"f":"Satoshi Nakamoto","d":1226200189,"b":[["q","The core concept is that lots of entities keep complete and consistent\ninformation as to who owns which bitcoins.\n\nBut maintaining consistency is tricky. It is not clear to me what\nhappens when someone reports one transaction to one maintainer, and\nsomeone else transports another transaction to another maintainer. The\ntransaction cannot be known to be valid until it has been incorporated\ninto a globally shared view of all past transactions, and no one can\nknow that a globally shared view of all past transactions is globally\nshared until after some time has passed, and after many new\ntransactions have arrived.\n\nDid you explain how to do this, and it just passed over my head, or\nwere you confident it could be done, and a bit vague as to the details?","James A. Donald wrote:"],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014833.html","s":1,"n":7,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/7/","qt":["It's not a problem if transactions have to wait one or a few extra cycles to get into a block."],"qc":["transactions"],"od":"Sat Nov  8 22:09:49 EST 2008"},{"f":"James A. Donald","d":1226206523,"b":[["q","The bandwidth might not be as prohibitive as you\nthink.  A typical transaction would be about 400 bytes\n(ECC is nicely compact).  Each transaction has to be\nbroadcast twice, so lets say 1KB per transaction.\nVisa processed 37 billion transactions in FY2008, or\nan average of 100 million transactions per day.  That\nmany transactions would take 100GB of bandwidth, or\nthe size of 12 DVD or 2 HD quality movies, or about\n$18 worth of bandwidth at current prices.","Satoshi Nakamoto wrote:"],["t","The trouble is, you are comparing with the Bankcard\nnetwork.\n\nBut a new currency cannot compete directly with an old,\nbecause network effects favor the old.\n\nYou have to go where Bankcard does not go.\n\nAt present, file sharing works by barter for bits. This,\nhowever requires the double coincidence of wants. People\nonly upload files they are downloading, and once the\ndownload is complete, stop seeding. So only active\nfiles, files that quite a lot of people want at the same\ntime, are available.\n\nFile sharing requires extremely cheap transactions,\nseveral transactions per second per client, day in and\nday out, with monthly transaction costs being very small\nper client, so to support file sharing on bitcoins, we\nwill need a layer of account money on top of the\nbitcoins, supporting transactions of a hundred\nthousandth the size of the smallest coin, and to support\nanonymity, chaumian money on top of the account money.\n\nLet us call a bitcoin bank a bink.  The bitcoins stand\nin the same relation to account money as gold stood in\nthe days of the gold standard.  The binks, not trusting\neach other to be liquid when liquidity is most needed,\nsettle out any net discrepancies with each other by\nmoving bit coins around once every hundred thousand\nseconds or so, so bitcoins do not change owners that\noften,   Most transactions cancel out at the account\nlevel.  The binks demand bitcoins of each other only\nbecause they don't want to hold account money for too\nlong. So a relatively small amount of bitcoins\ninfrequently transacted can support a somewhat larger\namount of account money frequently transacted."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014834.html","od":"Sat Nov  8 23:55:23 EST 2008"},{"f":"James A. Donald","d":1226221013,"b":[["t","     --"],["q","The proof-of-work chain is the solution to the\nsynchronisation problem, and to knowing what the\nglobally shared view is without having to trust\nanyone.\n\nA transaction will quickly propagate throughout the\nnetwork, so if two versions of the same transaction\nwere reported at close to the same time, the one with\nthe head start would have a big advantage in reaching\nmany more nodes first.  Nodes will only accept the\nfirst one they see, refusing the second one to arrive,\nso the earlier transaction would have many more nodes\nworking on incorporating it into the next\nproof-of-work.  In effect, each node votes for its\nviewpoint of which transaction it saw first by\nincluding it in its proof-of-work effort.","Satoshi Nakamoto wrote:"],["t","OK, suppose one node incorporates a bunch of\ntransactions in its proof of work, all of them honest\nlegitimate single spends and another node incorporates a\nslightly different bunch of transactions in its proof of\nwork, all of them equally honest legitimate single\nspends, and both proofs are generated at about the same\ntime.\n\nWhat happens then?"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014835.html","od":"Sun Nov  9 03:56:53 EST 2008"},{"f":"James A. Donald","d":1226225105,"b":[["q","Increasing hardware speed is handled: \"To compensate\nfor increasing hardware speed and varying interest in\nrunning nodes over time, the proof-of-work difficulty\nis determined by a moving average targeting an average\nnumber of blocks per hour. If they're generated too\nfast, the difficulty increases.\"","Satoshi Nakamoto wrote:"],["t","This does not work - your proposal involves\ncomplications I do not think you have thought through.\n\nFurthermore, it cannot be made to work, as in the\nproposed system the work of tracking who owns what coins\nis paid for by seigniorage, which requires inflation.\n\nThis is not an intolerable flaw - predictable inflation\nis less objectionable than inflation that gets jiggered\naround from time to time to transfer wealth from one\nvoting block to another."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014837.html","od":"Sun Nov  9 05:05:05 EST 2008"},{"f":"Satoshi Nakamoto","d":1226248286,"b":[["q","OK, suppose one node incorporates a bunch of\ntransactions in its proof of work, all of them honest\nlegitimate single spends and another node incorporates a\ndifferent bunch of transactions in its proof of\nwork, all of them equally honest legitimate single\nspends, and both proofs are generated at about the same\ntime.\n\nWhat happens then?","James A. Donald wrote:"],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014838.html","s":1,"n":8,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/8/","qt":["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.","A 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. If 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.","When 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.","The 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."],"qc":["nodes","proof-of-work"],"od":"Sun Nov  9 11:31:26 EST 2008"},{"f":"James A. Donald","d":1226260674,"b":[["t","     --"],["q","James A. Donald wrote:\n> OK, suppose one node incorporates a bunch of\n> transactions in its proof of work, all of them honest\n> legitimate single spends and another node\n> incorporates a different bunch of transactions in its\n> proof of work, all of them equally honest legitimate\n> single spends, and both proofs are generated at about\n> the same time.\n>\n> What happens then?"],["q","They both broadcast their blocks.  All nodes receive\nthem and keep both, but only work on the one they\nreceived first.  We'll suppose exactly half received\none first, half the other.\n\nIn a short time, all the transactions will finish\npropagating so that everyone has the full set.  The\nnodes working on each side will be trying to add the\ntransactions that are missing from their side.  When\nthe next proof-of-work is found, whichever previous\nblock that node was working on, that branch becomes\nlonger and the tie is broken.  Whichever side it is,\nthe new block will contain the other half of the\ntransactions, so in either case, the branch will\ncontain all transactions.  Even in the unlikely event\nthat a split happened twice in a row, both sides of\nthe second split would contain the full set of\ntransactions anyway.\n\nIt's not a problem if transactions have to wait one or\na few extra cycles to get into a block.","Satoshi Nakamoto wrote:"],["t","So what happened to the coin that lost the race?\n\nOn the one hand, we want people who make coins to be\nmotivated to keep and record all transactions, and\nobtain an up to date record of all transactions in a\ntimely manner.  On the other hand, it is a bit harsh if\nthe guy who came second is likely to lose his coin.\n\nFurther, your description of events implies restrictions\non timing and coin generation - that the entire network\ngenerates coins slowly compared to the time required for\nnews of a new coin to flood the network, otherwise the\nchains diverge more and more, and no one ever knows\nwhich chain is the winner.\n\nYou need to make these restrictions explicit, for\nnetwork flood time may well be quite slow.\n\nWhich implies that the new coin rate is slower.\n\nWe want spenders to have certainty that their\ntransaction is valid at the time it takes a spend to\nflood the network, not at the time it takes for branch\nraces to be resolved.\n\nAt any given time, for example at 1 040 689 138 seconds\nwe can look back at the past and say:\n\n At 1 040 688 737 seconds, node 5 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about on top of the previous link\n\n At 1 040 688 792 seconds, node 2 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about into the chain on top of node 5's\n link.\n\n At 1 040 688 745 seconds, node 7 was *it*, and\n he incorporated all the coins he had discovered\n into the chain, and all the new transactions he\n knew about into the chain on top of node 2's\n link.\n\nBut no one can know who is *it* right now\n\nSo how does one know when to reveal one's coins?  One\nsolution is that one does not.  One incorporates a hash\nof the coin secret whenever one thinks one might be\n*it*, and after that hash is securely in the chain,\nafter one knows that one was *it* at the time, one can\nthen safely spend the coin that one has found, revealing\nthe secret.\n\nThis solution takes care of the coin revelation problem,\nbut does not solve the spend recording problem.  If one\nnode is ignoring all spends that it does not care about,\nit suffers no adverse consequences.  We need a protocol\nin which your prospects of becoming *it* also depend on\nbeing seen by other nodes as having a reasonably up to\ndate and complete list of spends - which this protocol\nis not, and your protocol is not either."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014841.html","od":"Sun Nov  9 14:57:54 EST 2008"},{"f":"Satoshi Nakamoto","d":1226283270,"b":[["q","Furthermore, it cannot be made to work, as in the\nproposed system the work of tracking who owns what coins\nis paid for by seigniorage, which requires inflation.","James A. Donald wrote:"],["t","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.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014842.html","s":1,"n":9,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/9/","qt":["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."],"qc":["bitcoin-economics","fees"],"od":"Sun Nov  9 21:14:30 EST 2008"},{"f":"Satoshi Nakamoto","d":1226355500,"b":[["q","So what happened to the coin that lost the race?\n\n... it is a bit harsh if the guy who came second\nis likely to lose his coin.","James A. Donald wrote:"],["t","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."],["q","Further, your description of events implies restrictions\non timing and coin generation - that the entire network\ngenerates coins slowly compared to the time required for\nnews of a new coin to flood the network"],["t","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."],["q","We want spenders to have certainty that their\ntransaction is valid at the time it takes a spend to\nflood the network, not at the time it takes for branch\nraces to be resolved."],["t","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."],["q","If one node is ignoring all spends that it does not\ncare about, it suffers no adverse consequences."],["t","With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014843.html","s":1,"n":10,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","qt":["When there are multiple double-spent versions of the same transaction, one and only one will become valid.","The 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.","The 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.","The target time between blocks will probably be 10 minutes. Every 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.","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.","With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive."],"qc":["difficulty","double-spending","nodes","transactions"],"od":"Mon Nov 10 17:18:20 EST 2008"},{"f":"James A. Donald","d":1226556991,"b":[["q","When there are multiple double-spent versions of the\nsame transaction, one and only one will become valid.","Satoshi Nakamoto wrote:"],["t","That is not the question I am asking.\n\nIt is not trust that worries me, it is how it is\npossible to have a  a globally shared view even if\neveryone is well behaved.\n\nThe process for arriving at a globally shared view of\nwho owns what bitgold coins is insufficiently specified.\nOnce specified, then we can start considering whether\neveryone has incentives to behave correctly.\n\nIt is not sufficient that everyone knows X.  We also\nneed everyone to know that everyone knows X, and that\neveryone knows that everyone knows that everyone knows X\n- which, as in the Byzantine Generals problem, is the\nclassic hard problem of distributed data processing.\n\nThis problem becomes harder when X is quite possibly a\nvery large amount of data - agreement on who was the\nowner of every bitgold coin at such and such a time.\n\nAnd then on top of that we need everyone to have a\nmotive to behave in such a fashion that agreement\narises.  I cannot see that they have motive when I do\nnot know the behavior to be motivated.\n\nYou keep repeating your analysis of the system under\nattack.  We cannot say how the system will behave under\nattack until we know how the system is supposed to\nbehave when not under attack.\n\nIf there are a lot of transactions, it is hard to\nefficiently discover the discrepancies between one\nnode's view and another node's view, and because new\ntransactions are always arriving, no two nodes will ever\nhave the same view, even if all nodes are honest, and\nall reported transactions are correct and true single\nspends.\n\nWe should be able to accomplish a system where two nodes\nare likely to come to agreement as to who owned what\nbitgold coins at some very recent past time, but it is\nnot simple to do so.\n\nIf one node constructs a hash that represents its\nknowledge of who owned what bitgold coins at a\nparticular time, and another node wants to check that\nhash, it is not simple to do it in such a way that\nagreement is likely, and disagreement between honest\nwell behaved nodes is efficiently detected and\nefficiently resolved.\n\nAnd if we had a specification of how agreement is\ngenerated, it is not obvious why the second node has\nincentive to check that hash.\n\nThe system has to work in such a way that nodes can\neasily and cheaply change their opinion about recent\ntransactions, so as to reach consensus, but in order to\nprovide finality and irreversibility, once consensus has\nbeen reached, and then new stuff has be piled on top of\nold consensus, in particular new bitgold has been piled\non top of old consensus, it then becomes extremely\ndifficult to go back and change what was decided.\n\nSaying that is how it works, does not give us a method\nto make it work that way."],["q","The receiver of a payment must wait an hour or so\nbefore believing that it's valid.  The network will\nresolve any possible double-spend races by then."],["t","You keep discussing attacks.  I find it hard to think\nabout response to attack when it is not clear to me what\nnormal behavior is in the case of good conduct by each\nand every party.\n\nDistributed databases are *hard* even when all the\ndatabases perfectly follow the will of a single owner.\nMessages get lost, links drop, syncrhonization delays\nbecome abnormal, and entire machines go up in flames,\nand the network as a whole has to take all this in its\nstride.\n\nFiguring out how to do this is hard, even in the\ncomplete absence of attacks.  Then when we have figured\nout how to handle all this, then come attacks."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014847.html","od":"Thu Nov 13 01:16:31 EST 2008"},{"f":"Hal Finney","d":1226593458,"b":[["q","Satoshi Nakamoto wrote:\n > When there are multiple double-spent versions of the\n > same transaction, one and only one will become valid.\n\nThat is not the question I am asking.\n\nIt is not trust that worries me, it is how it is\npossible to have a  a globally shared view even if\neveryone is well behaved.\n\nThe process for arriving at a globally shared view of\nwho owns what bitgold coins is insufficiently specified.","James A. Donald writes:"],["t","I agree that the description is not completely clear on how these matters\nare handled. Satoshi has suggested that releasing source code may be the\nbest way to clarify the design. As I have tried to work through details on\nmy own, it does appear that the rules become rather complicated and indeed\none needs at least a pseudo-code algorithm to specify the behavior. So\nperhaps writing real code is not a bad way to go. I found that there is\na sourceforge project set up for bitgold, although it does not have any\ncode yet.\n\nIn answer to James' specific question, about what happens when different\nnodes see different sets of transactions, due to imperfect broadcast, here\nis how I understand it. Each node must be prepared to maintain potentially\nseveral \"candidate\" block chains, each of which may eventually turn out\nto become the longest one, the one which wins. Once a given block chain\nbecomes sufficiently longer than a competitor, the shorter one can be\ndeleted. This length differential is a parameter which depends on the\nnode's threat model for how much compute power an attacker can marshall,\nin terms of the fraction of the \"honst\" P2P network's work capacity,\nand is estimated in the paper. The idea is that once a chain gets far\nenough behind the longest one, there is essentially no chance that it\ncan ever catch up.\n\nIn order to resolve the issue James raised, I think it is necessary\nthat nodes keep a separate pending-transaction list associated with\neach candidate chain. This list would include all transactions the node\nhas received (via broadcast by the transactees) but which have not yet\nbeen incorporated into that block chain. At any given time, the node is\nworking to extend the longest block chain, and the block it is working\nto find a hash collision for will include all of the pending transactions\nassociated with that chain.\n\nI think that this way, when a candidate chain is deleted because it\ngot too much shorter than the longest one, transactions in it are\nnot lost, but have continued to be present in the pending-transaction\nlist associated with the longest chain, in those nodes which heard the\noriginal transaction broadcast. (I have also considered whether nodes\nshould add transactions to their pending-transaction list that they\nlearn about through blocks from other nodes, even if those blocks do\nnot end up making their way into the longest block chain; but I'm not\nsure if that is necessary or helpful.)\n\nOnce these rules are clarified, more formal modeling will be helpful in\nunderstanding the behavior of the network given imperfect reliability. For\nexample, if on average a fraction f of P2P nodes receive a given\ntransaction broadcast, then I think one would expect 1/f block-creation\ntimes to elapse before the transaction appears in what is destined to\nbecome the longest chain. One might also ask, given that the P2P network\nbroadcast is itself imperfectly reliable, how many candidate chains\nmust a given node keep track of at one time, on average? Or as James\nraised earlier, if the network broadcast is reliable but depends on a\npotentially slow flooding algorithm, how does that impact performance?"],["q","And then on top of that we need everyone to have a\nmotive to behave in such a fashion that agreement\narises.  I cannot see that they have motive when I do\nnot know the behavior to be motivated."],["t","I am somewhat less worried about motivation. I'd be satisfied if the\nsystem can meet the following criteria:\n\n1. No single node operator, or small collection of node operators\nwhich controls only a small fraction of overall network resources,\ncan effectively cheat, if other players are honest.\n\n2. The long tail of node operators is sufficiently large that no small\ncollection of nodes can control more than a small fraction of overall\nresources. (Here, the \"tail\" refers to a ranking based on amount of\nresources controlled by each operator.)\n\n3. The bitcoin system turns out to be socially useful and valuable, so\nthat node operators feel that they are making a beneficial contribution\nto the world by their efforts (similar to the various \"@Home\" compute\nprojects 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\nnetwork running properly."],["q","Distributed databases are *hard* even when all the\ndatabases perfectly follow the will of a single owner.\nMessages get lost, links drop, syncrhonization delays\nbecome abnormal, and entire machines go up in flames,\nand the network as a whole has to take all this in its\nstride."],["t","A very good point, and a more complete specification is necessary in order\nto understand how the network will respond to imperfections like this. I\nam looking forward to seeing more detail emerge.\n\nOne thing I might mention is that in many ways bitcoin is two independent\nideas: a way of solving the kinds of problems James lists here, of\ncreating a globally consistent but decentralized database; and then using\nit for a system similar to Wei Dai's b-money (which is referenced in the\npaper) but transaction/coin based rather than account based. Solving the\nglobal, massively decentralized database problem is arguably the harder\npart, as James emphasizes. The use of proof-of-work as a tool for this\npurpose is a novel idea well worth further review IMO.\n\nHal Finney"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014848.html","od":"Thu Nov 13 11:24:18 EST 2008"},{"f":"Satoshi Nakamoto","d":1226617015,"b":[["q","It is not sufficient that everyone knows X. We also\nneed everyone to know that everyone knows X, and that\neveryone knows that everyone knows that everyone knows X\n- which, as in the Byzantine Generals problem, is the\nclassic hard problem of distributed data processing.","James A. Donald wrote:"],["t","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."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014849.html","s":1,"n":11,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/11/","qt":["The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\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 They 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. They 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 After 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 The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved."],"qc":["proof-of-work"],"od":"Thu Nov 13 17:56:55 EST 2008"},{"f":"Satoshi Nakamoto","d":1226688935,"b":[["q","I think it is necessary that nodes keep a separate\npending-transaction list associated with each candidate chain.\n... One might also ask ... how many candidate chains must\na given node keep track of at one time, on average?","Hal Finney wrote:"],["t","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."],["q","Or as James raised earlier, if the network broadcast\nis reliable but depends on a potentially slow flooding\nalgorithm, how does that impact performance?"],["t","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."],["q","3. The bitcoin system turns out to be socially useful and valuable, so\nthat node operators feel that they are making a beneficial contribution\nto the world by their efforts (similar to the various \"@Home\" compute\nprojects 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\nnetwork running properly."],["t","It's very attractive to the libertarian viewpoint if we can explain it properly.  I'm better with code than with words though.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014853.html","s":1,"n":12,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/12/","qt":["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.","It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though."],"qc":["mining","motives","nodes"],"od":"Fri Nov 14 13:55:35 EST 2008"},{"f":"Ray Dillinger","d":1226715623,"b":[["t","Okay.... I'm going to summarize this protocol as I understand it.\n\nI'm filling in some operational details that aren't in the paper\nby supplementing what you wrote with what my own \"design sense\"\ntells me are critical missing bits or \"obvious\" methodologies for\nuse.\n\nFirst, people spend computer power creating a pool of coins to use\nas money.  Each coin is a proof-of-work meeting whatever criteria\nwere in effect for money at the time it was created.  The time of\ncreation (and therefore the criteria) is checkable later because\npeople can see the emergence of this particular coin in the\ntransaction chain and track it through all its \"consensus view\"\nspends.  (more later on coin creation tied to adding a link).\n\nWhen a coin is spent, the buyer and seller digitally sign a (blinded)\ntransaction record, and broadcast it to a bunch of nodes whose purpose\nis keeping track of consensus regarding coin ownership.  If someone\ndouble spends, then the transaction record can be unblinded revealing\nthe identity of the cheater.  This is done via a fairly standard cut-\nand-choose algorithm where the buyer responds to several challenges\nwith secret shares, and the seller then asks him to \"unblind\" and\nchecks all but one, verifying that they do contain secret shares any\ntwo of which are sufficient to identify the buyer.  In this case the\nseller accepts the unblinded spend record as \"probably\" containing\na valid secret share.\n\nThe nodes keeping track of consensus regarding coin ownership are in\na loop where they are all trying to \"add a link\" to the longest chain\nthey've so far recieved.  They have a pool of reported transactions\nwhich they've not yet seen in a \"consensus\" signed chain.  I'm going\nto call this pool \"A\".  They attempt to add a link to the chain by\nmoving everything from pool A into a pool \"L\" and using a CPU-\nintensive digital signature algorithm to sign the chain including\nthe new block L.  This results in a chain extended by a block\ncontaining all the transaction records they had in pool L, plus\nthe node's digital signature.  While they do this, new\ntransaction records continue to arrive and go into pool A again\nfor the next cycle of work.\n\nThey may also recieve chains as long as the one they're trying to\nextend while they work, in which the last few \"links\" are links\nthat are *not* in common with the chain on which they're working.\nThese they ignore.  (?  Do they ignore them?  Under what\ncircumstances would these become necessary to ever look at again,\nbearing in mind that any longer chain based on them will include\nthem?)\n\nBut if they recieve a _longer_ chain while working, they\nimmediately check all the transactions in the new links to make\nsure it contains no double spends and that the \"work factors\" of\nall new links are appropriate.  If it contains a double spend,\nthen they create a \"transaction\" which is a proof of double\nspending, add it to their pool A, broadcast it, and continue work.\nIf one of the \"new\" links has an inappropriate work factor (ie,\nsomeone didn't put enough CPU into it for it to be \"licit\"\naccording to the rules) a new \"transaction\" which is a proof\nof the protocol violation by the link-creating node is created,\nbroadcast, and added to pool A, and the chain is rejected.  In\nthe case of no double spends and appropriate work factors for\nall links not yet seen, they accept the new chain as consensus.\n\nIf the new chain is accepted, then they give up on adding their\ncurrent link, dump all the transactions from pool L back into pool\nA (along with transactions they've recieved or created since\nstarting work), eliminate from pool A those transaction records\nwhich are already part of a link in the new chain, and start work\nagain trying to extend the new chain.\n\nIf they complete work on a chain extended with their new link, they\nbroadcast it and immediately start work on another new link with\nall the transactions that have accumulated in pool A since they\nbegan work.\n\nDo I understand it correctly?\n\nBiggest Technical Problem:\n\nIs there a mechanism to make sure that the \"chain\" does not consist\nsolely of links added by just the 3 or 4 fastest nodes?  'Cause a\nbroadcast transaction record could easily miss those 3 or 4 nodes\nand if it does, and those nodes continue to dominate the chain, the\ntransaction might never get added.\n\nTo remedy this, you need to either ensure provable propagation of\ntransactions, or vary the work factor for a node depending on how\nmany links have been added since that node's most recent link.\n\nUnfortunately, both measures can be defeated by sock puppets.\nThis is probably the worst problem with your protocol as it\nstands right now; you need some central point to control the\nidentities (keys) of the nodes and prevent people from making\nnew sock puppets.\n\nProvable propagation would mean that When Bob accepts a new chain\nfrom Alice, he needs to make sure that Alice has (or gets) all\ntransactions in his \"A\" and \"L\" pools.  He sends them, and\nAlice sends back a signed hash to prove she got them. Once\nAlice has recieved this block of transactions, if any subsequent\nchains including a link added by Alice do not include those\ntransactions at or before that link, then Bob should be able to\npublish the block he sent Alice, along with her signature, in a\ntransaction as proof that Alice violated protocol.  Sock puppets\ndefeat this because Alice just signs subsequent chains using a\nnew key, pretending to be a different node.\n\nIf we go with varying the work factor depending on how many new\nlinks there are,  then we're right back to domination by the 3\nor 4 fastest nodes, except now they're joined by 600 or so\nsock puppets which they use to avoid the work factor penalty.\n\nIf we solve the sock-puppet issue, or accept that there's a central\npoint controlling the generation of new keys, then generation of\ncoins should be tied to the act of successfully adding a block to\nthe \"consensus\" chain.  This is simple to do; creation of a coin\nis a transaction, it gets added along with all the other transactions\nin the block.  But you can only create one coin per link, and of\ncourse if your version of the chain isn't the one that gets accepted,\nthen in the \"accepted\" view you don't have the coin and can't spend\nit.  This gives the people maintaining the consensus database a\nreason to spend CPU cycles, especially since the variance in work\nfactor by number of links added since their own last link (outlined\nabove) guarantees that everyone, not just the 3 or 4 fastest nodes,\noccasionally gets the opportunity to create a coin.\n\nAlso, the work requirement for adding a link to the chain should\nvary (again exponentially) with the number of links added to that\nchain in the previous week, causing the rate of coin generation\n(and therefore inflation) to be strictly controlled.\n\nYou need coin aggregation for this to scale.  There needs to be\na \"provable\" transaction where someone retires ten single coins\nand creates a new coin with denomination ten, etc.  This is not\ntoo hard, using the same infrastructure you've already got; it\nsimply becomes part of the chain, and when the chain is accepted\nconsensus, then everybody can see that it happened.\n\n    Bear"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014857.html","od":"Fri Nov 14 21:20:23 EST 2008"},{"f":"Satoshi Nakamoto","d":1226724180,"b":[["t","I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions."],["q","When a coin is spent, the buyer and seller digitally sign a (blinded)\ntransaction record.","Ray Dillinger (Bear) wrote:"],["t","Only the buyer signs, and there's no blinding."],["q","If someone double spends, then the transaction record\ncan be unblinded revealing the identity of the cheater. "],["t","Identities are not used, and there's no reliance on recourse.  It's all prevention."],["q","This is done via a fairly standard cut-and-choose\nalgorithm where the buyer responds to several challenges\nwith secret shares"],["t","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."],["q","They may also receive chains as long as the one they're trying to\nextend while they work, in which the last few \"links\" are links\nthat are *not* in common with the chain on which they're working.\nThese they ignore. "],["t","Right, if it's equal in length, ties are broken by keeping the earliest one received."],["q","If it contains a double spend, then they create a \"transaction\"\nwhich is a proof of double spending, add it to their pool A,\nbroadcast it, and continue work."],["t","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."],["q","If the new chain is accepted, then they give up on adding their\ncurrent link, dump all the transactions from pool L back into pool\nA (along with transactions they've received or created since\nstarting work), eliminate from pool A those transaction records\nwhich are already part of a link in the new chain, and start work\nagain trying to extend the new chain."],["t","Right.  They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time."],["q","CPU-intensive digital signature algorithm to\nsign the chain including the new block L. "],["t","It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature."],["q","Is there a mechanism to make sure that the \"chain\" does not consist\nsolely of links added by just the 3 or 4 fastest nodes? 'Cause a\nbroadcast transaction record could easily miss those 3 or 4 nodes\nand if it does, and those nodes continue to dominate the chain, the\ntransaction might never get added."],["t","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."],["q","Also, the work requirement for adding a link to the chain should\nvary (again exponentially) with the number of links added to that\nchain in the previous week, causing the rate of coin generation\n(and therefore inflation) to be strictly controlled."],["t","Right."],["q","You need coin aggregation for this to scale. There needs to be\na \"provable\" transaction where someone retires ten single coins\nand creates a new coin with denomination ten, etc. "],["t","Every transaction is one of these.  Section 9, Combining and Splitting Value.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014858.html","s":1,"n":13,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","qt":["I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.","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.","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 Same 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.","We'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.","The 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.","There 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."],"qc":["bitcoin-economics","double-spending","mining","proof-of-work","releases","transactions"],"od":"Fri Nov 14 23:43:00 EST 2008"},{"f":"Ray Dillinger","d":1226732661,"b":[["q","I'll try and hurry up and release the sourcecode as soon as possible\nto serve as a reference to help clear up all these implementation\nquestions.","On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:"],["q","Ray Dillinger (Bear) wrote:\n> When a coin is spent, the buyer and seller digitally sign a (blinded)\n> transaction record.\n\nOnly the buyer signs, and there's no blinding.\n\n> If someone double spends, then the transaction record\n> can be unblinded revealing the identity of the cheater.\n\nIdentities are not used, and there's no reliance on recourse.  It's all prevention."],["t","Okay, that's surprising.  If you're not using buyer/seller\nidentities, then you are not checking that a spend is being made\nby someone who actually is the owner of (on record as having\nrecieved) the coin being spent.\n\nThere are three categories of identity that are useful to\nthink about.  Category one: public.  Real-world identities\nare a matter of record and attached to every transaction.\nCategory two: Pseudonymous.  There are persistent \"identities\"\nwithin the system and people can see if something was done by\nthe same nym that did something else, but there's not necessarily\nany way of linking the nyms with real-world identities.  Category\nthree: unlinkably anonymous.  There is no concept of identity,\npersistent or otherwise.  No one can say or prove whether the\nagents involved in any transaction are the same agents as involved\nin any other transaction.\n\nAre you claiming category 3 as you seem to be, or category 2?\nLots of people don't distinguish between anonymous and\npseudonymous protocols, so it's worth asking exactly what\nyou mean here.\n\nAnyway:  I'll proceed on the assumption that you meant very\nnearly (as nearly as I can imagine, anyway) what you said,\nunlinkably anonymous.  That means that instead of an \"identity\",\na spender has to demonstrate knowledge of a secret known only\nto the real owner of the coin.  One way to do this would be\nto have the person recieving the coin generate an asymmetric\nkey pair, and then have half of it published with the\ntransaction.  In order to spend the coin later, s/he must\ndemonstrate posession of the other half of the asymmetric\nkey pair, probably by using it to sign the key provided by\nthe new seller.  So we cannot prove anything about \"identity\",\nbut we can prove that the spender of the coin is someone who\nknows a secret that the person who recieved the coin knows.\n\nAnd what you say next seems to confirm this:"],["q","No challenges or secret shares.  A basic transaction is just\nwhat you see in the figure in section 2.  A signature (of the\nbuyer) satisfying the public key of the previous transaction,\nand a new public key (of the seller) that must be satisfied to\nspend it the next time."],["t","Note, even though this doesn't involve identity per se, it still\nmakes the agent doing the spend linkable to the agent who\nearlier recieved the coin, so these transactions are linkable.\nIn order to counteract this, the owner of the coin needs to\nmake a transaction, indistinguishable to others from any\nnormal transaction, in which he creates a new key pair and\ntransfers the coin to its posessor (ie, has one sock puppet\n\"spend\" it to another). No change in real-world identity of\nthe owner, but the transaction \"linkable\" to the agent who spent\nthe coin is unlinked.  For category-three unlinkability, this\nhas to be done a random number of times - maybe one to six\ntimes?\n\nBTW, could you please learn to use carriage returns??  Your\nlines are scrolling stupidly off to the right and I have to\nscroll to see what the heck you're saying, then edit to add\ncarriage returns before I respond."],["q","> If it contains a double spend, then they create a \"transaction\"\n> which is a proof of double spending, add it to their pool A,\n> broadcast it, and continue work."],["q","There's no need for reporting of \"proof of double spending\" like\nthat.  If the same chain contains both spends, then the block is\ninvalid and rejected.  "],["q","Same if a block didn't have enough proof-of-work.  That block is\ninvalid and rejected.  There's no need to circulate a report\nabout it.  Every node could see that and reject it before relaying it."],["t","Mmmm.  I don't know if I'm comfortable with that.  You're saying\nthere's no effort to identify and exclude nodes that don't\ncooperate?  I suspect this will lead to trouble and possible DOS\nattacks."],["q","If there are two competing chains, each containing a different\nversion of the same transaction, with one trying to give money\nto one person and the other trying to give the same money to\nsomeone else, resolving which of the spends is valid is what\nthe whole proof-of-work chain is about."],["t","Okay, when you say \"same\" transaction, and you're talking about\ntransactions that are obviously different, you mean a double\nspend, right?  Two transactions signed with the same key?"],["q","We're not \"on the lookout\" for double spends to sound the alarm\nand catch the cheater.  We merely adjudicate which one of the\nspends is valid.  Receivers of transactions must wait a few\nblocks to make sure that resolution has had time to complete. "],["t","Until.... until what?  How does anybody know when a transaction\nhas become irrevocable?   Is \"a few\" blocks three?  Thirty?  A\nhundred?  Does it depend on the number of nodes?  Is it logarithmic\nor linear in number of nodes?\n\n "],["q","Would be cheaters can try and simultaneously double-spend all\nthey want, and all they accomplish is that within a few blocks,\none of the spends becomes valid and the others become invalid."],["t","But in the absence of identity, there's no downside to them\nif spends become invalid, if they've already recieved the\ngoods they double-spent for (access to website, download,\nwhatever).  The merchants are left holding the bag with\n\"invalid\" coins, unless they wait that magical \"few blocks\"\n(and how can they know how many?) before treating the spender\nas having paid.\n\nThe consumers won't do this if they spend their coin and it takes\nan hour to clear before they can do what they spent their coin on.\nThe merchants won't do it if there's no way to charge back a\ncustomer when they find the that their coin is invalid because\nthe customer has doublespent."],["q","Even if an earlier spend wasn't in the chain yet, if it was\nalready in all the nodes' pools, then the second spend would\nbe turned away by all those nodes that already have the first\nspend."],["t","So there's a possibility of an early catch when the broadcasts of\nthe initial simultaneous spends interfere with each other.  I assume\nhere that the broadcasts are done by the sellers, since the buyer\nhas a possible disincentive to broadly disseminate spends."],["q","> If the new chain is accepted, then they give up on adding their\n> current link ... and start work again trying to extend the new\n> chain.\n\nRight.  They also refresh whenever a new transaction comes in,\nso L pretty much contains everything in A all the time."],["t","Okay, that's a big difference between a proof of work that takes\na huge set number of CPU cycles and a proof of work that takes a\ntiny number of CPU cycles but has a tiny chance of success.  You\ncan change the data set while working, and it doesn't mean you\nneed to start over. This is good in this case, as it means nobody\nhas to hold recently recieved transactions out of the link they're\nworking on."],["q","> Is there a mechanism to make sure that the \"chain\" does not consist\n> solely of links added by just the 3 or 4 fastest nodes? "],["q","If you're thinking of it as a CPU-intensive digital signing, then\nyou may be thinking of a race to finish a long operation first and\nthe fastest always winning."],["t","Right.  That was the misconception I was working with.  Again, the\ndifference between a proof taking a huge set number of CPU cycles\nand a proof that takes a tiny number of CPU cycles but has a tiny\nchance of success."],["q","Anyone's chance of finding a solution at any\ntime is proportional to their CPU power."],["t","It's like a random variation in the work factor; in this way it works\nin your favor."],["q","There will be transaction fees, so nodes will have an incentive\nto receive and include all the transactions they can.  Nodes\nwill eventually be compensated by transaction fees alone when\nthe total coins created hits the pre-determined ceiling."],["t","I don't understand how \"transaction fees\" would work, and how the money\nwould find its way from the agents doing transactions to those running\nthe network.  But the economic effect is the same (albeit somewhat\nrandomized) if adding a link to the chain allows the node to create\na coin, so I would stick with that.\n\nAlso, be aware that the compute power of different nodes can be\nexpected to vary by two orders of magnitude at any given moment in\nhistory.\n\n    Bear"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014859.html","od":"Sat Nov 15 02:04:21 EST 2008"},{"f":"Satoshi Nakamoto","d":1226772120,"b":[["q","One way to do this would be\nto have the person recieving the coin generate an asymmetric\nkey pair, and then have half of it published with the\ntransaction. In order to spend the coin later, s/he must\ndemonstrate posession of the other half of the asymmetric\nkey pair, probably by using it to sign the key provided by\nthe new seller.","Ray Dillinger wrote:"],["t","Right, it's ECC digital signatures.  A new key pair is used for every\ntransaction.\n\nIt's not pseudonymous in the sense of nyms identifying people, but it\nis at least a little pseudonymous in that the next action on a coin\ncan be identified as being from the owner of that coin."],["q","Mmmm. I don't know if I'm comfortable with that. You're saying\nthere's no effort to identify and exclude nodes that don't\ncooperate? I suspect this will lead to trouble and possible DOS\nattacks."],["t","There is no reliance on identifying anyone.  As you've said, it's\nfutile and can be trivially defeated with sock puppets.\n\nThe credential that establishes someone as real is the ability to\nsupply CPU power."],["q","Until.... until what? How does anybody know when a transaction\nhas become irrevocable? Is \"a few\" blocks three? Thirty? A\nhundred? Does it depend on the number of nodes? Is it logarithmic\nor linear in number of nodes?"],["t","Section 11 calculates the worst case under attack.  Typically, 5 or\n10 blocks is enough for that.  If you're selling something that\ndoesn't merit a network-scale attack to steal it, in practice you\ncould cut it closer."],["q","But in the absence of identity, there's no downside to them\nif spends become invalid, if they've already received the\ngoods they double-spent for (access to website, download,\nwhatever). The merchants are left holding the bag with\n\"invalid\" coins, unless they wait that magical \"few blocks\"\n(and how can they know how many?) before treating the spender\nas having paid.\n\nThe consumers won't do this if they spend their coin and it takes\nan hour to clear before they can do what they spent their coin on.\nThe merchants won't do it if there's no way to charge back a\ncustomer when they find the that their coin is invalid because\nthe customer has doublespent."],["t","This is a version 2 problem that I believe can be solved fairly\nsatisfactorily for most applications.\n\nThe race is to spread your transaction on the network first.  Think 6\ndegrees of freedom -- it spreads exponentially.  It would only take\nsomething like 2 minutes for a transaction to spread widely enough\nthat a competitor starting late would have little chance of grabbing\nvery many nodes before the first one is overtaking the whole network.\n During those 2 minutes, the merchant's nodes can be watching for a\ndouble-spent transaction.  The double-spender would not be able to\nblast his alternate transaction out to the world without the merchant\ngetting it, so he has to wait before starting.\n\nIf the real transaction reaches 90% and the double-spent tx reaches\n10%, the double-spender only gets a 10% chance of not paying, and 90%\nchance his money gets spent.  For almost any type of goods, that's\nnot going to be worth it for the scammer.\n\nInformation based goods like access to website or downloads are\nnon-fencible.  Nobody is going to be able to make a living off\nstealing access to websites or downloads.  They can go to the file\nsharing networks to steal that.  Most instant-access products aren't\ngoing to have a huge incentive to steal.\n\nIf a merchant actually has a problem with theft, they can make the\ncustomer wait 2 minutes, or wait for something in e-mail, which many\nalready do.  If they really want to optimize, and it's a large\ndownload, they could cancel the download in the middle if the\ntransaction comes back double-spent.  If it's website access,\ntypically it wouldn't be a big deal to let the customer have access\nfor 5 minutes and then cut off access if it's rejected.  Many such\nsites have a free trial anyway.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014860.html","s":1,"n":14,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/14/","qt":["The credential that establishes someone as real is the ability to supply CPU power.","The 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. During 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 If 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.","If 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."],"qc":["double-spending","proof-of-work","transactions"],"od":"Sat Nov 15 13:02:00 EST 2008"},{"f":"James A. Donald","d":1226793604,"b":[["q","Fortunately, it's only necessary to keep a\npending-transaction pool for the current best branch.","Satoshi Nakamoto wrote:"],["t","This requires that we know, that is to say an honest\nwell behaved peer whose communications and data storage\nis working well knows, what the current best branch is -\nbut of course, the problem is that we are trying to\ndiscover, trying to converge upon, a best branch, which\nis not easy at the best of times, and becomes harder\nwhen another peer is lying about its connectivity and\ncapabilities, and yet another peer has just had a major\ndisk drive failure obfuscated by a software crash, and\nthe international fibers connecting yet a third peer\nhave been attacked by terrorists."],["q"," When a new block arrives for the best branch,\n ConnectBlock removes the block's transactions from\n the pending-tx pool.  If a different branch becomes\n longer"],["t","Which presupposes the branches exist, that they are\nfully specified and complete.  If they exist as complete\nworks, rather than works in progress, then the problem\nis already solved, for the problem is making progress."],["q","Broadcasts will probably be almost completely\nreliable."],["t","There is a trade off between timeliness and reliability.\nOne can make a broadcast arbitrarily reliable if time is\nof no consequence.  However, when one is talking of\ndistributed data, time is always of consequence, because\nit is all about synchronization (that peers need to have\ncorresponding views at corresponding times) so when one\ndoes distributed data processing, broadcasts are always\nhighly unreliable Attempts to ensure that each\nmessage arrives at least once result in increased timing\nvariation. Thus one has to make a protocol that is\neither UDP or somewhat UDP like, in that messages are\nsmall, failure of messages to arrive is common, messages\ncan arrive in different order to the order in which they\nwere sent, and the same message may arrive multiple\ntimes.  Either we have UDP, or we need to accommodate\nthe same problems as UDP has on top of TCP connections.\n\nRather than assuming that each message arrives at least\nonce, we have to make a mechanism such that the\ninformation arrives even though conveyed by messages\nthat frequently fail to arrive."],["q","TCP transmissions are rarely ever dropped these days"],["t","People always load connections near maximum.  When a\nconnection is near maximum, TCP connections suffer\nfrequent unreasonably long delays, and connections\nsimply fail a lot - your favorite web cartoon somehow\nshows it is loading forever, and you try again, or it\ncomes up with a little x in place of a picture, and you\ntry again\n\nFurther very long connections - for example ftp\ndownloads of huge files,  seldom complete. If you try to\nftp a movie, you are unlikely to get anywhere unless\nboth client and server have a resume mechanism so that\nthey can talk about partially downloaded files.\n\nUDP connections, for example Skype video calls, also\nsuffer frequent picture freezes, loss of quality, and so\nforth, and have to have mechanisms to keep going\nregardless."],["q","It's very attractive to the libertarian viewpoint if\nwe can explain it properly.  I'm better with code than\nwith words though."],["t","No, it is very attractive to the libertarian if we can\ndesign a mechanism that will scale to the point of\nproviding the benefits of rapidly irreversible payment,\nimmune to political interference, over the internet,\nto very large numbers of people. You have an outline\nand proposal for such a design, which is a big step\nforward, but the devil is in the little details.\n\nI really should provide a fleshed out version of your\nproposal, rather than nagging you to fill out the blind\nspots."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014861.html","od":"Sat Nov 15 19:00:04 EST 2008"},{"f":"Satoshi Nakamoto","d":1226942683,"b":[["q","> Fortunately, it's only necessary to keep a\n> pending-transaction pool for the current best branch.\n\nThis requires that we know, that is to say an honest\nwell behaved peer whose communications and data storage\nis working well knows, what the current best branch is -","James A. Donald wrote:"],["t","I mean a node only needs the pending-tx pool for the best branch it\nhas.  The branch that it currently thinks is the best branch.\nThat's the branch it'll be trying to make a block out of, which is\nall it needs the pool for."],["q","> Broadcasts will probably be almost completely\n> reliable.\n\nRather than assuming that each message arrives at least\nonce, we have to make a mechanism such that the\ninformation arrives even though conveyed by messages\nthat frequently fail to arrive."],["t","I think I've got the peer networking broadcast mechanism covered.\n\nEach node sends its neighbours an inventory list of hashes of the\nnew blocks and transactions it has.  The neighbours request the\nitems they don't have yet.  If the item never comes through after a\ntimeout, they request it from another neighbour that had it.  Since\nall or most of the neighbours should eventually have each item,\neven if the coms get fumbled up with one, they can get it from any\nof the others, trying one at a time.\n\nThe inventory-request-data scheme introduces a little latency, but\nit ultimately helps speed more by keeping extra data blocks off the\ntransmit queues and conserving bandwidth."],["q","You have an outline\nand proposal for such a design, which is a big step\nforward, but the devil is in the little details."],["t","I believe I've worked through all those little details over the\nlast year and a half while coding it, and there were a lot of them.\nThe functional details are not covered in the paper, but the\nsourcecode is coming soon.  I sent you the main files.\n(available by request at the moment, full release soon)\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014863.html","s":1,"n":15,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/15/","qt":["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. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)"],"qc":["bitcoin-design","releases"],"od":"Mon Nov 17 12:24:43 EST 2008"},{"f":"Nicolas Williams","d":1226958868,"b":[["q","On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:\n> > If someone double spends, then the transaction record\n> > can be unblinded revealing the identity of the cheater.\n>\n> Identities are not used, and there's no reliance on recourse.  It's all prevention.\n\nOkay, that's surprising.  If you're not using buyer/seller\nidentities, then you are not checking that a spend is being made\nby someone who actually is the owner of (on record as having\nrecieved) the coin being spent.  ","On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:"],["t","How do identities help?  It's supposed to be anonymous cash, right?  And\nsay you identify a double spender after the fact, then what?  Perhaps\nyou're looking at a disposable ID.  Or perhaps you can't chase them\ndown.\n\nDouble spend detection needs to be real-time or near real-time.\n\nNico\n--"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014864.html","od":"Mon Nov 17 16:54:28 EST 2008"},{"f":"James A. Donald","d":1226966259,"b":[["q","Okay.... I'm going to summarize this protocol as I\nunderstand it.\n\nI'm filling in some operational details that aren't in\nthe paper by supplementing what you wrote with what my\nown \"design sense\" tells me are critical missing bits\nor \"obvious\" methodologies for use.","Ray Dillinger wrote:"],["t","There are a number of significantly different ways this\ncould be implemented.  I have been working on my own\nversion based on Patricia hash trees, (not yet ready to\npost, will post in a week or so) with the consensus\ngeneration being a generalization of file sharing using\nMerkle hash trees. Patricia hash trees where the high\norder part of the Patricia key represents the high order\npart of the time can be used to share data that evolves\nin time.  The algorithm, if implemented by honest\ncorrectly functioning peers, regularly generates\nconsensus hashes of the recent past - thereby addressing\nthe problem I have been complaining about - that we have\na mechanism to protect against consensus distortion by\ndishonest or malfunctioning peers, which is useless\nabsent a definition of consensus generation by honest\nand correctly functioning peers."],["q","First, people spend computer power creating a pool of\ncoins to use as money.  Each coin is a proof-of-work\nmeeting whatever criteria were in effect for money at\nthe time it was created.  The time of creation (and\ntherefore the criteria) is checkable later because\npeople can see the emergence of this particular coin\nin the transaction chain and track it through all its\n\"consensus view\" spends.  (more later on coin creation\ntied to adding a link).\n\nWhen a coin is spent, the buyer and seller digitally\nsign a (blinded) transaction record, and broadcast it\nto a bunch of nodes whose purpose is keeping track of\nconsensus regarding coin ownership."],["t","I don't think your blinding works.\n\nIf there is a public record of who owns what coin, we\nhave to generate a  public diff on changes in that\nrecord, so the record will show that a coin belonged to\nX, and soon thereafter belonged to Y.  I don't think\nblinding can be made to work.  We can blind the\ntransaction details easily enough, by only making hashes\nof the details public, (X paid Y for\n49vR7xmwYcKXt9zwPJ943h9bHKC2pG68m) but that X paid Y is\ngoing to be fairly obvious.\n\nIf when Joe spends a coin to me, then I have to have the\nability to ask \"Does Joe rightfully own this coin\", then\nit is difficult to see how this can be implemented in a\ndistributed protocol without giving people the ability\nto trawl through data detecting that Joe paid me.\n\nTo maintain a consensus on who owns what coins, who owns\nwhat coins has to be public.\n\nWe can build a privacy layer on top of this - account\nmoney and chaumian money based on bitgold coins, much as\nthe pre 1915 US banking system layered account money and\nbank notes on top of gold coins, and indeed we have to\nbuild a layer on top to bring the transaction cost down\nto the level that supports agents performing micro\ntransactions, as needed for bandwidth control, file\nsharing, and charging non white listed people to send us\ncommunications.\n\nSo the entities on the public record are entities\nfunctioning like pre 1915 banks - let us call them\nbinks, for post 1934 banks no longer function like that."],["q","But if they recieve a _longer_ chain while working,\nthey immediately check all the transactions in the new\nlinks to make sure it contains no double spends and\nthat the \"work factors\" of all new links are\nappropriate."],["t","I am troubled that this involves frequent\nretransmissions of data that is already mostly known.\nConsensus and widely distributed beliefs about bitgold\nownership already involves significant cost.  Further,\neach transmission of data is subject to data loss, which\ncan result in thrashing, with the risk that the\ngeneration of consensus may slow below the rate of new\ntransactions.  We already have problems getting the cost\ndown to levels that support micro transactions by\nsoftware agents, which is the big unserved market -\nbandwidth control, file sharing, and charging non white\nlisted people to send us communications.\n\nTo work as useful project, has to be as efficient as it\ncan be - hence my plan to use a Patricia hash tree\nbecause it identifies and locate small discrepancies\nbetween peers that are mostly in agreement already,\nwithout them needing to transmit their complete data.\n\nWe also want to avoid very long hash chains that have to\nbe frequently checked in order to validate things.  Any\ntime a hash chain can potentially become enormously long\nover time, we need to ensure that no one ever has to\nrewalk the full length.  Chains that need to be\nre-walked can only be permitted to grow as the log of\nthe total number of transactions - if they grow as the\nlog of the transactions in any one time period plus the\ntotal number of time periods, we have a problem."],["q","Biggest Technical Problem:\n\nIs there a mechanism to make sure that the \"chain\"\ndoes not consist solely of links added by just the 3\nor 4 fastest nodes?  'Cause a broadcast transaction\nrecord could easily miss those 3 or 4 nodes and if it\ndoes, and those nodes continue to dominate the chain,\nthe transaction might never get added.\n\nTo remedy this, you need to either ensure provable\npropagation of transactions, or vary the work factor\nfor a node depending on how many links have been added\nsince that node's most recent link.\n\nUnfortunately, both measures can be defeated by sock\npuppets. This is probably the worst problem with your\nprotocol as it stands right now; you need some central\npoint to control the identities (keys) of the nodes\nand prevent people from making new sock puppets."],["t","We need a protocol wherein to be a money tracking peer\n(an entity that validates spends) you have to be\naccepted by at least two existing peers who agree to\nsynchronize data with you - presumably through human\nintervention by the owners of existing peers, and these\ntwo human approved synchronization paths indirectly\nconnect you to the other peers in the network through\nat least one graph cycle.\n\nIf peer X is only connected to the rest of the network\nby one existing peer, peer Y, perhaps because X's\ndirectly connecting peer has dropped out, then X is\ndemoted to a client, not a peer - any transactions X\nsubmits are relabeled by Y as submitted to Y, not X, and\nthe time of submission (which forms part of the Patricia\nkey) is the time X submitted them to Y, not the time\nthey were submitted to X.\n\nThe algorithm must be able swiftly detect malfunctioning\npeers, and automatically exclude them from the consensus\ntemporarily - which means that transactions submitted\nthrough malfunctioning peers do not get included in the\nconsensus, therefore have to be resubmitted, and peers\nmay find themselves temporarily demoted to clients,\nbecause one of the peers through which they were\nformerly connected to the network has been dropped by\nthe consensus.\n\nIf a peer gets a lot of automatic temporary exclusions,\nthere may be human intervention by the owners of those\npeers to which it exchanges data directly to permanently\ndrop them.\n\nSince peers get accepted by human invite, they have\nreputation to lose, therefore we can make the null\nhypothesis (the primary Bayesian prior) honest intent,\nvalid data, but  unreliable data transmission - trust\nwith infrequent random verification.  Designing the\nsystem on this basis considerably reduces processing\ncosts.\n\nRecall that SET died on its ass in large part because\nevery transaction involved innumerable public key\noperations.  Similarly, we have huge security flaws in\nhttps because it has so many redundant public key\noperations that web site designers try to minimize the\nuse of https to cover only those areas that truly need\nit - and they always get the decision as to what truly\nneeds it subtly wrong.\n\nEfficiency is critical, particularly as the part of the\nmarket not yet served is the market for very low cost\ntransactions."],["q","If we solve the sock-puppet issue, or accept that\nthere's a central point controlling the generation of\nnew keys,"],["t","A central point will invite attack, will be attacked.\n\nThe problem with computer networked money is that the\npast can so easily be revised, so nodes come under\npressure to adjust the past - \"I did not pay that\"\nswiftly becomes \"I should not have paid that\", which\nrequires arbitration, which is costly, and introduces\nuncertainty, which is costly, and invites government\nregulation, which is apt to be utterly ruinous and\nwholly devastating.\n\nFor many purposes, reversal and arbitration is highly\ndesirable, but there is no way anyone can compete with\nthe arbitration provided by Visa and Mastercard, for\nthey have network effects on their side, and they do a\nreally good job of arbitration, at which they have vast\nexperience, accumulated skills, wisdom, and good repute.\nSo any new networked transaction system has to target\nthe demand for final and irreversible transactions.\n\nThe idea of a distributed network consensus is that one\nhas a lot of peers in a lot of jurisdictions, and once a\ntransaction has entered into the consensus, undoing it\nis damn near impossible - one would have to pressure\nmost of the peers in most of the jurisdictions to agree,\nand many of them don't even talk your language, and\nthose that do, will probably pretend that they do not.\nSo people will not even try.\n\nTo avoid pressure, the network has to avoid any central\npoint at which pressure can be applied.  Recall Nero's\nwish that Rome had a single throat that he could cut. If\nwe provide them with such a throat, it will be cut."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014865.html","od":"Mon Nov 17 18:57:39 EST 2008"},{"f":"James A. Donald","d":1226971591,"b":[["q","How do identities help?  It's supposed to be anonymous\ncash, right?","Nicolas Williams wrote:"],["t","Actually no.  It is however supposed to be pseudonymous,\nso dinging someone's reputation still does not help\nmuch."],["q","And say you identify a double spender after the fact,\nthen what?  Perhaps you're looking at a disposable ID.\nOr perhaps you can't chase them down.\n\nDouble spend detection needs to be real-time or near\nreal-time."],["t","Near real time means we have to use UDP or equivalent,\nrather than TCP or equivalent, and we have to establish\nan approximate consensus, not necessarily the final\nconsensus, not necessarily exact agreement, but close to\nit, in a reasonably small number of round trips."],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2008-November/014866.html","od":"Mon Nov 17 20:26:31 EST 2008"}]},{"id":"e2","k":"e","s":"cryptography","t":"Bitcoin v0.1 released","u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html","su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/threads/2/","m":[{"f":"Satoshi Nakamoto","d":1231442860,"b":[["t","Announcing the first release of Bitcoin, a new electronic cash\nsystem that uses a peer-to-peer network to prevent double-spending.\nIt's completely decentralized with no server or central authority.\n\nSee bitcoin.org for screenshots.\n\nDownload link:\nhttp://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar\n\nWindows only for now.  Open source C++ code is included.\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections,\nyou'll really be helping the network a lot.  Port 8333 on your\nfirewall needs to be open to receive incoming connections.\n\nThe software is still alpha and experimental.  There's no guarantee\nthe system's state won't have to be restarted at some point if it\nbecomes necessary, although I've done everything I can to build in\nextensibility and versioning.\n\nYou can get coins by getting someone to send you some, or turn on\nOptions->Generate Coins to run a node and generate blocks.  I made\nthe proof-of-work difficulty ridiculously easy to start with, so\nfor a little while in the beginning a typical PC will be able to\ngenerate coins in just a few hours.  It'll get a lot harder when\ncompetition makes the automatic adjustment drive up the difficulty.\nGenerated coins must wait 120 blocks to mature before they can be\nspent.\n\nThere are two ways to send money.  If the recipient is online, you\ncan enter their IP address and it will connect, get a new public\nkey and send the transaction with comments.  If the recipient is\nnot online, it is possible to send to their Bitcoin address, which\nis a hash of their public key that they give you.  They'll receive\nthe transaction the next time they connect and get the block it's\nin.  This method has the disadvantage that no comment information\nis sent, and a bit of privacy may be lost if the address is used\nmultiple times, but it is a useful alternative if both users can't\nbe online at the same time or the recipient can't receive incoming\nconnections.\n\nTotal circulation will be 21,000,000 coins.  It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if\nneeded.  It's based on open market competition, and there will\nprobably always be nodes willing to process transactions for free.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html","s":1,"n":16,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","qt":["Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.","If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections.","You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent.","There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.","Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free."],"qc":["bitcoin-economics","mining","nodes","releases","transactions"],"od":"Thu Jan  8 14:27:40 EST 2009"},{"f":"Hal Finney","d":1231640521,"b":[["q","Announcing the first release of Bitcoin, a new electronic cash\nsystem that uses a peer-to-peer network to prevent double-spending.\nIt's completely decentralized with no server or central authority.\n\nSee bitcoin.org for screenshots.\n\nDownload link:\nhttp://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar","Satoshi Nakamoto writes:"],["t","Congratulations to Satoshi on this first alpha release.  I am looking\nforward to trying it out."],["q","Total circulation will be 21,000,000 coins.  It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc..."],["t","It's interesting that the system can be configured to only allow a\ncertain maximum number of coins ever to be generated. I guess the\nidea is that the amount of work needed to generate a new coin will\nbecome more difficult as time goes on.\n\nOne immediate problem with any new currency is how to value it. Even\nignoring the practical problem that virtually no one will accept it\nat first, there is still a difficulty in coming up with a reasonable\nargument in favor of a particular non-zero value for the coins.\n\nAs an amusing thought experiment, imagine that Bitcoin is successful and\nbecomes the dominant payment system in use throughout the world.  Then the\ntotal value of the currency should be equal to the total value of all\nthe wealth in the world. Current estimates of total worldwide household\nwealth that I have found range from $100 trillion to $300 trillion. With\n20 million coins, that gives each coin a value of about $10 million.\n\nSo the possibility of generating coins today with a few cents of compute\ntime may be quite a good bet, with a payoff of something like 100 million\nto 1! Even if the odds of Bitcoin succeeding to this degree are slim,\nare they really 100 million to one against? Something to think about...\n\nHal"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015004.html","od":"Sat Jan 10 21:22:01 EST 2009"},{"f":"Satoshi Nakamoto","d":1232121794,"b":[["q","Dustin D. Trammell wrote:\n> Satoshi Nakamoto wrote:\n> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based systems\n> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the BitCoins so that they become\ncurrency."],["t","I would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites.  Initially it can be used in proof-of-work applications\nfor 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\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on.  If\nenough people think the same way, that becomes a self fulfilling\nprophecy.  Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015014.html","s":1,"n":17,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/17/","qt":["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.","It 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. It'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.","It 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."],"qc":["bitcoin-economics","cryptocurrency","micropayments"],"od":"Fri Jan 16 11:03:14 EST 2009"},{"f":"Jonathan Thornburg","d":1232210985,"b":[["t","On Sat, 17 Jan 2009, Satoshi Nakamoto wrote:\n[[various possible uses of Bitcoin et al]]"],["q","Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine.  "],["t","In the modern world, no major government wants to allow untracable\ninternational financial transactions above some fairly modest size\nthresholds.  (The usual catch-phrases are things like \"laundering\ndrug money\", \"tax evasion\", and/or \"financing terrorist groups\".)\nTo this end, electronic financial transactions are currently monitored\nby various governments & their agencies, and any but the smallest of\ntransactions now come with various ID requirements for the humans\non each end.\n\nBut if each machine in a million-node botnet sends 10 cents to a\nrandomly chosen machine in another botnet on the other side of the\nworld, you've just moved $100K, in a way that seems very hard to\ntrace.  To me, this means that no major government is likely to allow\nBitcoin in its present form to operate on a large scale.\n\nI also worry about other \"domestic\" ways nasty people could exploit\na widespread Bitcoin deployment:\n* Spammer botnets could burn through pay-per-send email filters\n  trivially (as usual, the costs would fall on people other than the\n  botnet herders & spammers).\n* If each machine in a botnet sends 1 cent to a herder, that can add\n  up to a significant amount of money.  In other words, Bitcoin would\n  make botnet herding and the assorted malware industry even more\n  profitable than it already is.\n\nIs there something obvious I've missed?  Is there a clever aspect of\nthe design which prevents botnets from exploiting the system?  Is there\na way for every major government to monitor all Bitcoin transactions\nto watch for botnet-to-botnet sending?\n\n--\n-- From: \"Jonathan Thornburg [remove -animal to reply]\" <jthorn at astro.indiana-zebra.edu>\n   Dept of Astronomy, Indiana University, Bloomington, Indiana, USA\n   \"Washing one's hands of the conflict between the powerful and the\n    powerless means to side with the powerful, not to be neutral.\"\n                                      -- quote by Freire / poster by Oxfam"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015016.html","od":"Sat Jan 17 11:49:45 EST 2009"},{"f":"Hal Finney","d":1232815683,"b":[["q","In the modern world, no major government wants to allow untracable\ninternational financial transactions above some fairly modest size\nthresholds.  (The usual catch-phrases are things like \"laundering\ndrug money\", \"tax evasion\", and/or \"financing terrorist groups\".)\nTo this end, electronic financial transactions are currently monitored\nby various governments & their agencies, and any but the smallest of\ntransactions now come with various ID requirements for the humans\non each end.\n\nBut if each machine in a million-node botnet sends 10 cents to a\nrandomly chosen machine in another botnet on the other side of the\nworld, you've just moved $100K, in a way that seems very hard to\ntrace.  To me, this means that no major government is likely to allow\nBitcoin in its present form to operate on a large scale.","Jonathan Thornburg writes:"],["t","Certainly a valid point, and one which has been widely discussed in\nthe debates over the years about electronic cash. Bitcoin has a couple\nof things going for it: one is that it is distributed, with no single\npoint of failure, no \"mint\", no company with officers that can be\nsubpoenaed and arrested and shut down. It is more like a P2P network,\nand as we have seen, despite degrees of at least governmental distaste,\nthose are still around.\n\nBitcoin could also conceivably operate in a less anonymous mode, with\ntransfers being linked to individuals, rather than single-use keys. It\nwould still be useful to have a large scale, decentralized electronic\npayment system.\n\nIt also might be possible to refactor and restructure Bitcoin to separate\nout the key new idea, a decentralized, global, irreversible transaction\ndatabase. Such a functionality might be useful for other purposes. Once\nit exists, using it to record monetary transfers would be a sort of side\neffect and might be harder to shut down."],["q","I also worry about other \"domestic\" ways nasty people could exploit\na widespread Bitcoin deployment:\n* Spammer botnets could burn through pay-per-send email filters\n  trivially (as usual, the costs would fall on people other than the\n  botnet herders & spammers).\n* If each machine in a botnet sends 1 cent to a herder, that can add\n  up to a significant amount of money.  In other words, Bitcoin would\n  make botnet herding and the assorted malware industry even more\n  profitable than it already is."],["t","It's important to understand that the proof-of-work (POW) aspect of\nBitcoin is primarily oriented around ensuring the soundness of the\nhistorical transaction database. Each Bitcoin data block records a set\nof transactions, and includes a hash collision. Subsequent data blocks\nhave their own transactions, their own collisions, and also chain to\nall earlier hashes.  The result is that once a block is \"buried\" under\nenough new blocks, it is essentially certain (given the threat model,\nnamely that attackers cannot muster more than X% of the compute power\nof legitimate node operators) that old transactions can't be reversed.\n\nCreating new coins is indeed currently also being done by POW, but I\nthink that is seen as a temporary expedient, and in fact the current\nsoftware phases that out over several years. Hence worries about botnets\nbeing able to manufacture large quantities of POW tokens are only a\ntemporary concern, in the context of Bitcoin.\n\nThere have been a number of discussions in the past about POW tokens as\nanti spam measures, given the botnet threat. References are available from\n\"Proof-of-work system\" on Wikipedia. Analyses have yielded mixed results,\ndepending on the assumptions and system design.\n\nIf POW tokens do become useful, and especially if they become money,\nmachines will no longer sit idle. Users will expect their computers to\nbe earning them money (assuming the reward is greater than the cost to\noperate). A computer whose earnings are being stolen by a botnet will\nbe more noticeable to its owner than is the case today, hence we might\nexpect that in that world, users will work harder to maintain their\ncomputers and clean them of botnet infestations.\n\nCountermeasures by botnet operators would include moderating their take,\nperhaps only stealing 10% of the productive capacity of invaded computers,\nso that their owners would be unlikely to notice. This kind of thinking\nquickly degenerates into unreliable speculation, but it points out the\ndifficulties of analyzing the full ramifications of a world where POW\ntokens are valuble.\n\nHal Finney"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015036.html","od":"Sat Jan 24 11:48:03 EST 2009"},{"f":"Bill Frantz","d":1232839341,"b":[["q","Countermeasures by botnet operators would include moderating their take,\nperhaps only stealing 10% of the productive capacity of invaded computers,\nso that their owners would be unlikely to notice. This kind of thinking\nquickly degenerates into unreliable speculation, but it points out the\ndifficulties of analyzing the full ramifications of a world where POW\ntokens are valuble.","hal at finney.org (\"Hal Finney\") on Saturday, January 24, 2009 wrote:"],["t","Some people tell me that the 0wned machines are among the most secure on\nthe network because botnet operators work hard to keep others from\ncompromising \"their\" machines. I could see the operators moving toward\nbeing legitimate security firms, protecting computers against compromise in\nexchange for some of the proof of work (POW) money.\n\nCheers - Bill\n\n-------------------------------------------------------------------------\nBill Frantz        | When it comes to the world     | Periwinkle\n(408)356-8506      | around us, is there any choice | 16345 Englewood Ave\nwww.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015038.html","od":"Sat Jan 24 18:22:21 EST 2009"},{"f":"dan at geer.org","d":1232856437,"b":[["t","Bill Frantz writes:\n-+-----------------\n | Some people tell me that the 0wned machines are among the most\n | secure on the network because botnet operators work hard to\n | keep others from compromising \"their\" machines. I could see the\n | operators moving toward being legitimate security firms,\n | protecting computers against compromise in exchange for some of\n | the proof of work (POW) money.\n\nI'm one of those people.  Quoting from my speech of 1/20:"],["q","Virus attacks have, of course, become rarer over time, which is\nto say that where infectious agents once ruled, today it is\nparasites.  Parasites have no reason to kill their hosts -- on\nthe contrary they want their hosts to survive well enough to\nfeed the parasite.  A parasite will generally not care to be all\nthat visible, either.  The difference between parasitism and\nsymbiosis can be a close call in some settings, and of the folks\nwho famously bragged of being able to take the Internet down in\ntwenty minutes, one has said that a computer may be better\nmanaged once it is in a botnet than before since the bot-master\nwill be serious about closing the machine up tight against\nfurther penetration and similarly serious about patch\nmanagement.  Therefore, since one can then say that both the\nmachine's nominal owner and the bot master are mutually helped,\nwhat we see is evolution from parasite to symbiont in action.\nAccording to Margulis and Sagan, \"Life did not take over the\nglobe by combat, but by networking.\"  On this basis and others,\nbot-nets are a life form."],["t","Rest of text upon request.  Incidentally, I *highly* recommend\nDaniel Suarez's _Daemon_; trust me as to its relevance.  Try\nthis for a non-fiction taste:\n\nhttp://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality\n\n--dan"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015040.html","od":"Sat Jan 24 23:07:17 EST 2009"},{"f":"Satoshi Nakamoto","d":1232898430,"b":[["q","> * Spammer botnets could burn through pay-per-send email filters\n>   trivially\nIf POW tokens do become useful, and especially if they become money,\nmachines will no longer sit idle. Users will expect their computers to\nbe earning them money (assuming the reward is greater than the cost to\noperate). A computer whose earnings are being stolen by a botnet will\nbe more noticeable to its owner than is the case today, hence we might\nexpect that in that world, users will work harder to maintain their\ncomputers and clean them of botnet infestations.","Hal Finney wrote:"],["t","Another factor that would mitigate spam if POW tokens have value:\nthere would be a profit motive for people to set up massive\nquantities of fake e-mail accounts to harvest POW tokens from\nspam.  They'd essentially be reverse-spamming the spammers with\nautomated mailboxes that collect their POW and don't read the\nmessage.  The ratio of fake mailboxes to real people could become\ntoo high for spam to be cost effective.\n\nThe process has the potential to establish the POW token's value\nin the first place, since spammers that don't have a botnet could\nbuy tokens from harvesters.  While the buying back would\ntemporarily let more spam through, it would only hasten the\nself-defeating cycle leading to too many harvesters exploiting the\nspammers.\n\nInterestingly, one of the e-gold systems already has a form of\nspam called \"dusting\".  Spammers send a tiny amount of gold dust\nin order to put a spam message in the transaction's comment field.\n If the system let users configure the minimum payment they're\nwilling to receive, or at least the minimum that can have a\nmessage with it, users could set how much they're willing to get\npaid to receive spam.\n\nSatoshi Nakamoto"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo at metzdowd.com"]],"u":"http://www.metzdowd.com/pipermail/cryptography/2009-January/015041.html","s":1,"n":18,"su":"https://satoshi.nakamotoinstitute.org/emails/cryptography/18/","od":"Sun Jan 25 10:47:10 EST 2009"}]},{"id":"e3","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Welcome","u":"https://sourceforge.net/p/bitcoin/mailman/message/21033408/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/3/","m":[{"f":"Satoshi Nakamoto","d":1228928423,"b":[["t","Welcome to the Bitcoin mailing list!"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21033408/","s":1,"n":19,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/19/"}]},{"id":"e4","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin v0.1 released","u":"https://sourceforge.net/p/bitcoin/mailman/message/21312757/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/4/","m":[{"f":"Hal Finney","d":1231643803,"b":[["q","Announcing the first release of Bitcoin, a new electronic cash\nsystem that uses a peer-to-peer network to prevent double-spending.\nIt's completely decentralized with no server or central authority.\n\nSee bitcoin.org for screenshots.\n\nDownload link:\nhttp://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar","Satoshi Nakamoto writes:"],["t","Congratulations to Satoshi on this first alpha release.  I am looking\nforward to trying it out."],["q","Total circulation will be 21,000,000 coins.  It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc..."],["t","It's interesting that the system can be configured to only allow a\ncertain maximum number of coins ever to be generated. I guess the\nidea is that the amount of work needed to generate a new coin will\nbecome more difficult as time goes on.\n\nOne immediate problem with any new currency is how to value it. Even\nignoring the practical problem that virtually no one will accept it\nat first, there is still a difficulty in coming up with a reasonable\nargument in favor of a particular non-zero value for the coins.\n\nAs an amusing thought experiment, imagine that Bitcoin is successful and\nbecomes the dominant payment system in use throughout the world.  Then the\ntotal value of the currency should be equal to the total value of all\nthe wealth in the world. Current estimates of total worldwide household\nwealth that I have found range from $100 trillion to $300 trillion. With\n20 million coins, that gives each coin a value of about $10 million.\n\nSo the possibility of generating coins today with a few cents of compute\ntime may be quite a good bet, with a payoff of something like 100 million\nto 1! Even if the odds of Bitcoin succeeding to this degree are slim,\nare they really 100 million to one against? Something to think about...\n\nHal"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21312757/","sj":"Re: [bitcoin-list] Bitcoin v0.1 released"},{"f":"Satoshi Nakamoto","d":1232130932,"b":[["q","Dustin D. Trammell wrote:\n> Satoshi Nakamoto wrote:\n> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based systems\n> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the BitCoins so that they become\ncurrency."],["t","I would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites.  Initially it can be used in proof-of-work applications\nfor 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\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on.  If\nenough people think the same way, that becomes a self fulfilling\nprophecy.  Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21356305/","s":1,"n":23,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/23/","sj":"Re: [bitcoin-list] Bitcoin v0.1 released"}]},{"id":"e5","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin v0.1.2 now available","u":"https://sourceforge.net/p/bitcoin/mailman/message/21303153/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/5/","m":[{"f":"Satoshi Nakamoto","d":1231713138,"b":[["t","Bitcoin v0.1.2 is now available for download.\n\nSee http://www.bitcoin.org for the download link.\n\nAll the problems I've been finding are in the code that\nautomatically finds and connects to other nodes, since I wasn't\nable to test it in the wild until now.  There are many more ways\nfor connections to get screwed up on the real Internet.\n\nBugs fixed:\n- Fixed various problems that were making it hard for new nodes to\nsee other nodes to connect to.\n- If you're behind a firewall, it could only receive one\nconnection, and the second connection would constantly disconnect\nand reconnect.\n\nThese problems are kind of screwing up the network and will get\nworse as more users arrive, so please make sure to upgrade.\n\nSatoshi Nakamoto"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21303153/","s":1,"n":20,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/20/"}]},{"id":"e6","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin v0.1 Alpha release notes","u":"https://sourceforge.net/p/bitcoin/mailman/message/21312004/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/6/","m":[{"f":"Satoshi Nakamoto","d":1231791647,"b":[["t","Release notes for Bitcoin v0.1 Alpha\n\nBitcoin is a new electronic cash system that uses a peer-to-peer\nnetwork to prevent double-spending.  It's completely decentralized\nwith no server or central authority.\n\nYou can find screenshots and the download link at:\nhttp://www.bitcoin.org\n\nWindows only for now.  Open source C++ code is included.\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections,\nyou'll really be helping the network a lot.  Port 8333 on your\nfirewall needs to be open to receive incoming connections.\n\nThe software is still alpha and experimental.  There's no guarantee\nthe system's state won't have to be restarted at some point if it\nbecomes necessary, although I've done everything I can to build in\nextensibility and versioning.\n\nYou can get coins by getting someone to send you some, or turn on\nOptions->Generate Coins to run a node and generate blocks.  I made\nthe proof-of-work difficulty ridiculously easy to start with, so\nfor a little while in the beginning a typical PC will be able to\ngenerate coins in just a few hours.  It'll get a lot harder when\ncompetition makes the automatic adjustment drive up the difficulty.\nGenerated coins must wait 120 blocks to mature before they can be\nspent.\n\nThere are two ways to send money.  If the recipient is online, you\ncan enter their IP address and it will connect, get a new public\nkey and send the transaction with comments.  If the recipient is\nnot online, it is possible to send to their Bitcoin address, which\nis a hash of their public key that they give you.  They'll receive\nthe transaction the next time they connect and get the block it's\nin.  This method has the disadvantage that no comment information\nis sent, and a bit of privacy may be lost if the address is used\nmultiple times, but it is a useful alternative if both users can't\nbe online at the same time or the recipient can't receive incoming\nconnections.\n\nTotal circulation will be 21,000,000 coins.  It'll be distributed\nto network nodes when they make blocks, with the amount cut in half\nevery 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if\nneeded.  It's based on open market competition, and there will\nprobably always be nodes willing to process transactions for free.\n\nSatoshi Nakamoto"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21312004/","s":1,"n":21,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/21/"}]},{"id":"e7","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin v0.1.3","u":"https://sourceforge.net/p/bitcoin/mailman/message/21313152/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/7/","m":[{"f":"Satoshi Nakamoto","d":1231800503,"b":[["t","It looks like we're through with the worst of the Internet\nconnection issues.  0.1.3 fixed a problem where your node's\ncommunications could go dead after a while.  The network is\nrunning much more smoothly now with this version.\n\nIf you've successfully generated a block, you've seen it has a\nmaturation countdown before you can spend it.  Once it matures,\nthe Credit column will change from 0.00 to 50.00.  For a block to\nbe valid, it has to be broadcasted to the network and get into the\nblock chain, which is why Generate does not run if you're not\nconnected.  If you generated a block without being connected, the\nnetwork wouldn't know about it and would continue building the\nchain without it, leaving it behind, and the maturation countdown\nwould change to \"(not accepted)\" when your node sees that it\nwasn't used.  If you subtract 1 from the status column, that's how\nmany blocks have been chained after yours.\n\nSatoshi Nakamoto"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21313152/","s":1,"n":22,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/22/"}]},{"id":"e8","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Problems","u":"https://sourceforge.net/p/bitcoin/mailman/message/21423198/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/8/","m":[{"f":"Nicholas Bohm","d":1232878672,"b":[["t","I have had a couple of problems running bitcoin:  is this an appropriate\nlist for reporting them (with about 70kb of attachments)?\n\nNicholas Bohm"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21423198/"},{"f":"Satoshi Nakamoto","d":1232901925,"b":[["t","From: Nicholas Bohm 2009-01-25 10:17"],["q","I have had a couple of problems running bitcoin: is this an appropriate\nlist for reporting them (with about 70kb of attachments)?"],["t","What's the problem you're having?\n\nIf you send me your debug.log file directly (best not to send attachments\nto the list), I can take a look at what's happening.\n\nSatoshi Nakamoto\nbitcoin-help at vistomail dot com"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21424626/","s":1,"n":24,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/24/","sj":"Re: [bitcoin-list] Problems"}]},{"id":"e9","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin v0.1.5 released","u":"https://sourceforge.net/p/bitcoin/mailman/message/21500063/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/9/","m":[{"f":"Satoshi Nakamoto","d":1233776764,"b":[["t","Version 0.1.5 is now available.  It includes the fix for the problem\nNicholas had, checking for disk full and changes to try to improve\nthings that were confusing.\n\nSpecial thanks to Nicholas and Dustin for all their help and feedback!\n\nDownload link:\nhttp://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441\n\nChanges:\n- disk full warning\n- fixed a bug that could occur if dns lookup failed\n- prevent entering your own address in the address book,\n    which confusingly changed the label for your own address\n- moved change address button to menu under options\n- tweaks to make it get connected faster\n- close sockets on exit\n- created minimum fee for transactions less than 1 cent\n- hid the transaction-type selection box that only had one choice\n- cleaned up ParseMoney a little\n- slightly cleaner reformatting of message text\n- changed the font in transaction details dialog\n- added some explanation text to transaction details for generated coins\n- reworded the description for transactions received with bitcoin address\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21500063/","s":1,"n":25,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/25/"},{"f":"Nicholas Bohm","d":1234968950,"b":[["t","Version 0.1.5 seems to be running trouble free.  I have a list of 201\ntransactions, I've accumulated about bc8550.  Transfers in and out seem\nto work fine (after a bit of head-scratching to understand the labelling\nof incoming transactions).\n\nWhat's next?\n\nNicholas Bohm"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21610990/"},{"f":"Satoshi Nakamoto","d":1235324872,"b":[["q","What's next?"],["t","The next thing for v0.1.6 is to take advantage of multiple\nprocessors to generate blocks.  Currently it only starts one\nthread.  If you have a multi-core processor like a Core Duo or\nQuad this will double or quadruple your production.\n\nLater I want to add interfaces to make it really easy to integrate\ninto websites from any server side language.\n\nSatoshi\n\nhttp://www.bitcoin.org"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21646307/","s":1,"n":26,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/26/","sj":"Re: [bitcoin-list] Bitcoin v0.1.5 released"},{"f":"Hal Finney","d":1235764812,"b":[["q","> What's next?\n\nThe next thing for v0.1.6 is to take advantage of multiple\nprocessors to generate blocks.  Currently it only starts one\nthread.  If you have a multi-core processor like a Core Duo or\nQuad this will double or quadruple your production.","On Sun, Feb 22, 2009 at 9:35 AM, Satoshi Nakamoto <satoshi@...> wrote:"],["t","That sounds good. I'd also like to be able to run multiple coin/block\ngenerators on multiple machines, all behind a single NAT address. I\nhaven't tried this yet so I don't know if it works on the current\nsoftware.\n\nBTW I don't remember if we talked about this, but the other day some\npeople were mentioning secure timestamping. You want to be able to\nprove that a certain document existed at a certain time in the past.\nSeems to me that bitcoin's stack of blocks would be perfect for this."],["q","Later I want to add interfaces to make it really easy to integrate\ninto websites from any server side language."],["t","Right, and I'd like to see more of a library interface that could be\ncalled from programming or scripting languages, on the client side as\nwell.\n\nHal"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21697543/","sj":"Re: [bitcoin-list] Bitcoin v0.1.5 released"},{"f":"Satoshi Nakamoto","d":1236185952,"b":[["q","That sounds good. I'd also like to be able to run multiple coin/block\ngenerators on multiple machines, all behind a single NAT address. I\nhaven't tried this yet so I don't know if it works on the current\nsoftware.","Hal Finney wrote:"],["t","The current version will work fine.  They'll each connect over the\nInternet, while incoming connections only come to the host that\nport 8333 is routed to.\n\nAs an optimisation, I'll make a switch \"-connect=1.2.3.4\" to make\nit only connect to a specific address.  You could make your extra\nnodes connect to your primary, and only the primary connects over\nthe Internet.  It doesn't really matter for now, since the network\nwould have to get huge before the bandwidth is anything more than\ntrivial."],["q","BTW I don't remember if we talked about this, but the other day some\npeople were mentioning secure timestamping. You want to be able to\nprove that a certain document existed at a certain time in the past.\nSeems to me that bitcoin's stack of blocks would be perfect for this."],["t","Indeed, Bitcoin is a distributed secure timestamp server for\ntransactions.  A few lines of code could create a transaction with\nan extra hash in it of anything that needs to be timestamped.\nI should add a command to timestamp a file that way."],["q","> > Later I want to add interfaces to make it really easy to integrate\n> > into websites from any server side language.\n\nRight, and I'd like to see more of a library interface that could be\ncalled from programming or scripting languages, on the client side as\nwell."],["t","Exactly.\n\nSatoshi Nakamoto\n\nhttp://www.bitcoin.org"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/21740046/","s":1,"n":27,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/27/","sj":"Re: [bitcoin-list] Bitcoin v0.1.5 released"}]},{"id":"e10","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Does Bitcoin Crash in Windows?","u":"https://sourceforge.net/p/bitcoin/mailman/message/23818861/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/10/","m":[{"f":"Liberty Standard","d":1256298610,"b":[["t"," Do you Windows users experience occasional Bitcoin crashes?\n\nLately Bitcoin running in wine-1.0.1 has been crashing frequently. I was\njust wondering whether this is a Wine issue or a Bitcoin issue. I speculate\nit might have something to do with how many Bitcoins I have since it would\ncrash less when I had less bitcoins and now crashes more now that I have\nmore bitcoins. It makes me hesitant to send my balance of bitcoins to my\nfresh Bitcoin installation. But this might just be my imagination since it\nhas crashed a few times after installing Bitcoin afresh.\n\nThe following four lines print from the terminal when I start Bitcoin.\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\n\nI previously wasn't starting Bitcoin from the terminal, so I don't know what\ngets printed out when it crashes, but I'll reply with the results the next\ntime it crashes.\n\nWhile Bitcoin first downloads previously completed blocks, the file\ndebug.log grows grows to 17.4 MB and then stops growing. I imagine it will\ncontinue to grow as more bitcoins are completed.\n\n~NewLibertyStandard~"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/23818861/"},{"f":"Satoshi Nakamoto","d":1256342271,"b":[["q"," Do you Windows users experience occasional Bitcoin crashes?\nLately Bitcoin running in wine-1.0.1 has been crashing frequently. I was\njust wondering whether this is a Wine issue or a Bitcoin issue. ","Liberty Standard wrote:"],["t","I haven't had any reports of crashes in v0.1.5.  It's been rock solid\nfor me on Windows.  I think it must be Wine related.  If you get another\ncrash in Wine and it prints anything on the terminal, e-mail me and I\nmay be able to figure out what happened, maybe something I can work\naround.  Martti and I have been working on a new version to release soon\nand it would be nice to get any Wine fixes in there."],["q","The following four lines print from the terminal when I start Bitcoin.\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub"],["t","Those don't look like anything to worry about.  Probably functions\nunimplemented by Wine that are harmlessly stubbed out."],["q","I previously wasn't starting Bitcoin from the terminal, so I don't know what\ngets printed out when it crashes, but I'll reply with the results the next\ntime it crashes.\n\nWhile Bitcoin first downloads previously completed blocks, the file\ndebug.log grows grows to 17.4 MB and then stops growing. I imagine it will\ncontinue to grow as more bitcoins are completed."],["t","You can delete debug.log occasionally if you don't want to take the disk\nspace.  It's just status messages that help with debugging.\n\nbitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing\nsome maintenance.\n\nSatoshi"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/23824064/","s":1,"n":28,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/28/","sj":"Re: [bitcoin-list] Does Bitcoin Crash in Windows?"},{"f":"Mike Hearn","d":1256396707,"b":[["q","The following four lines print from the terminal when I start Bitcoin.\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub"],["t","That just means it failed to create a minidump, so yeah, not the cause of\nthe crash.\n\nTo find the cause of the crash you'd need to run it with a +seh,+relay trace\nand find out what the app was doing before it crashed, or look in the\nbitcoin logs."]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/23827020/","sj":"Re: [bitcoin-list] Does Bitcoin Crash in Windows?"},{"f":"Eugen Leitl","d":1256561187,"b":[["q","bitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing ","On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:"],["t","Doesn't work right now."],["q","some maintenance."],["t","Still no .deb packages for Bitcoin?\n\n--\nEugen* Leitl leitl; http://leitl.org\n______________________________________________________________\nICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org\n8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/23838155/","sj":"Re: [bitcoin-list] Does Bitcoin Crash in Windows?"}]},{"id":"e11","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin 0.2 released","u":"https://sourceforge.net/p/bitcoin/mailman/message/24205662/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/11/","m":[{"f":"Satoshi Nakamoto","d":1261032729,"b":[["t","Bitcoin 0.2 is here!\n\nDownload (Windows, and now Linux version available)\nhttp://sourceforge.net/projects/bitcoin/files/\n\nNew Features\n\nMartti Malmi\n  - Minimize to system tray option\n  - Autostart on boot option so you can keep it running in the\nbackground automatically\n  - New options dialog layout for future expansion\n  - Setup program for Windows\n  - Linux version (tested on Ubuntu)\nSatoshi Nakamoto\n  - Multi-processor support for coin generation\n  - Proxy support for use with TOR\n  - Fixed some slowdowns in the initial block download\n\nWe also have a new forum at http://www.bitcoin.org/smf/\n\nMany thanks to Martti (sirius-m) for all his development work, and to\nNew Liberty Standard for his help with testing the Linux version.\n\nSatoshi Nakamoto"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/24205662/","s":1,"n":29,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/29/"}]},{"id":"e12","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin 0.3 released!","u":"https://sourceforge.net/p/bitcoin/mailman/message/25686730/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/12/","m":[{"f":"Satoshi Nakamoto","d":1278453233,"b":[["t","Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a\ndigital currency using cryptography and a distributed network to replace\nthe need for a trusted central server.  Escape the arbitrary inflation\nrisk of centrally managed currencies!  Bitcoin's total circulation is\nlimited to 21 million coins.  The coins are gradually released to the\nnetwork's nodes based on the CPU power they contribute, so you can get a\nshare of them by contributing your idle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Transaction filter tabs\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie\nand Joozero)\n\nGet it at http://www.bitcoin.org, and read the forum to find out more."]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/25686730/","s":1,"n":30,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/30/"}]},{"id":"e13","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Alert: upgrade to bitcoin 0.3.6","u":"https://sourceforge.net/p/bitcoin/mailman/message/25843947/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/13/","m":[{"f":"Satoshi Nakamoto","d":1280469758,"b":[["t","Please upgrade to 0.3.6 ASAP to get an important bugfix.\n\nSee the bitcoin.org homepage for download links."]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/25843947/","s":1,"n":31,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/31/"}]},{"id":"e14","k":"e","s":"bitcoin-list","t":"[bitcoin-list] ALERT - we are investigating a problem","u":"https://sourceforge.net/p/bitcoin/mailman/message/25954806/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/14/","m":[{"f":"Satoshi Nakamoto","d":1281904713,"b":[["t","*** WARNING ***  We are investigating a problem.  DO NOT TRUST ANY\nTRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638)\nuntil the issue is resolved."]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/25954806/","s":1,"n":32,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/32/"}]},{"id":"e15","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin 0.3.18 is released","u":"https://sourceforge.net/p/bitcoin/mailman/message/26722835/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/15/","m":[{"f":"Satoshi Nakamoto","d":1291849915,"b":[["t","Version 0.3.18 is now available.\n\nChanges:\n- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17\nand then upgraded again\n- IsStandard() check to only include known transaction types in blocks\n- Jgarzik's optimisation to speed up the initial block download a little\n\nThe main addition in this release is the Accounts-based JSON-RPC\ncommands that Gavin's been working on (more details at\nhttp://www.bitcoin.org/smf/index.php?topic=1886.0).\n- getaccountaddress\n- sendfrom\n- move\n- getbalance\n- listtransactions\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/26722835/","s":1,"n":33,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/33/"}]},{"id":"e16","k":"e","s":"bitcoin-list","t":"[bitcoin-list] Bitcoin 0.3.19 is released","u":"https://sourceforge.net/p/bitcoin/mailman/message/26744510/","su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/threads/16/","m":[{"f":"Satoshi Nakamoto","d":1292256729,"b":[["t","This is a minor release to add some DoS protection.\n\nChanges:\n- Added some DoS limits, though it's still far from DoS resistant.\n- Removed \"safe mode\" alerts.\n\nhttp://www.bitcoin.org/smf/index.php?topic=2228.0\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/"]],"u":"https://sourceforge.net/p/bitcoin/mailman/message/26744510/","s":1,"n":34,"su":"https://satoshi.nakamotoinstitute.org/emails/bitcoin-list/34/"}]},{"id":"e17","k":"e","s":"p2p-research","t":"[p2p-research] Bitcoin open source implementation of P2P currency","u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001347.html","su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/threads/17/","m":[{"f":"Satoshi Nakamoto","d":1234391874,"b":[["t","I've developed a new open source P2P e-cash system called Bitcoin.  It's\ncompletely decentralized, with no central server or trusted parties,\nbecause everything is based on crypto proof instead of trust.  Give it a\ntry, or take a look at the screenshots and design paper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe root problem with conventional currency is all the trust that's\nrequired to make it work.  The central bank must be trusted not to\ndebase the currency, but the history of fiat currencies is full of\nbreaches of that trust.  Banks must be trusted to hold our money and\ntransfer it electronically, but they lend it out in waves of credit\nbubbles with barely a fraction in reserve.  We have to trust them with\nour privacy, trust them not to let identity thieves drain our accounts.\n  Their massive overhead costs make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a similar\nproblem.  Before strong encryption, users had to rely on password\nprotection to secure their files, placing trust in the system\nadministrator to keep their information private.  Privacy could always\nbe overridden by the admin based on his judgment call weighing the\nprinciple of privacy against other concerns, or at the behest of his\nsuperiors.  Then strong encryption became available to the masses, and\ntrust was no longer required.  Data could be secured in a way that was\nphysically impossible for others to access, no matter for what reason,\nno matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money.  With e-currency based on\ncryptographic proof, without the need to trust a third party middleman,\nmoney can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital\nsignatures.  A digital coin contains the public key of its owner.  To\ntransfer it, the owner signs the coin together with the public key of\nthe next owner.  Anyone can check the signatures to verify the chain of\nownership.  It works well to secure ownership, but leaves one big\nproblem unsolved: double-spending.  Any owner could try to re-spend an\nalready spent coin by signing it again to another owner.  The usual\nsolution is for a trusted company with a central database to check for\ndouble-spending, but that just gets back to the trust model.  In its\ncentral position, the company can override the users, and the fees\nneeded to support the company make micropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for\ndouble-spending.  In a nutshell, the network works like a distributed\ntimestamp server, stamping the first transaction to spend a coin.  It\ntakes advantage of the nature of information being easy to spread but\nhard to stifle.  For details on how it works, see the design paper at\nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe result is a distributed system with no single point of failure.\nUsers hold the crypto keys to their own money and transact directly with\neach other, with the help of the P2P network to check for double-spending.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001347.html","s":1,"n":35,"su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/35/","od":"Wed Feb 11 23:30:54 CET 2009"},{"f":"Michel Bauwens","d":1234404930,"b":[["t","Thanks for sharing this initiative, I hope some of our more expert members\nwill intervene.\n\nI have an extra request if possible, our pages on Japanese initiatives, I'm\nassuming that is where you are based, though I could of course be wrong, are\nstill very undeveloped, so I'm wondering if you could not add a few of the\nimportant open/free and commons oriented initiatives that you know about,\nincluding your own.\n\nSee http://p2pfoundation.net/Japan\n\nMichel"],["q","I've developed a new open source P2P e-cash system called Bitcoin.  It's\ncompletely decentralized, with no central server or trusted parties, because\neverything is based on crypto proof instead of trust.  Give it a try, or\ntake a look at the screenshots and design paper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe root problem with conventional currency is all the trust that's\nrequired to make it work.  The central bank must be trusted not to debase\nthe currency, but the history of fiat currencies is full of breaches of that\ntrust.  Banks must be trusted to hold our money and transfer it\nelectronically, but they lend it out in waves of credit bubbles with barely\na fraction in reserve.  We have to trust them with our privacy, trust them\nnot to let identity thieves drain our accounts.  Their massive overhead\ncosts make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a similar\nproblem.  Before strong encryption, users had to rely on password protection\nto secure their files, placing trust in the system administrator to keep\ntheir information private.  Privacy could always be overridden by the admin\nbased on his judgment call weighing the principle of privacy against other\nconcerns, or at the behest of his superiors.  Then strong encryption became\navailable to the masses, and trust was no longer required.  Data could be\nsecured in a way that was physically impossible for others to access, no\nmatter for what reason, no matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money.  With e-currency based on\ncryptographic proof, without the need to trust a third party middleman,\nmoney can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital\nsignatures.  A digital coin contains the public key of its owner.  To\ntransfer it, the owner signs the coin together with the public key of the\nnext owner.  Anyone can check the signatures to verify the chain of\nownership.  It works well to secure ownership, but leaves one big problem\nunsolved: double-spending.  Any owner could try to re-spend an already spent\ncoin by signing it again to another owner.  The usual solution is for a\ntrusted company with a central database to check for double-spending, but\nthat just gets back to the trust model.  In its central position, the\ncompany can override the users, and the fees needed to support the company\nmake micropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for\ndouble-spending.  In a nutshell, the network works like a distributed\ntimestamp server, stamping the first transaction to spend a coin.  It takes\nadvantage of the nature of information being easy to spread but hard to\nstifle.  For details on how it works, see the design paper at\nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe result is a distributed system with no single point of failure. Users\nhold the crypto keys to their own money and transact directly with each\nother, with the help of the P2P network to check for double-spending.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n_______________________________________________\np2presearch mailing list\np2presearch at listcultures.org\nhttp://listcultures.org/mailman/listinfo/p2presearch_listcultures.org","On Thu, Feb 12, 2009 at 5:30 AM, Satoshi Nakamoto <satoshin at gmx.com> wrote:"],["t","--\nThe P2P Foundation researches, documents and promotes peer to peer\nalternatives.\n\nWiki and Encyclopedia, at http://p2pfoundation.net; Blog, at\nhttp://blog.p2pfoundation.net; Newsletter, at\nhttp://integralvisioning.org/index.php?topic=p2p\n\nBasic essay at http://www.ctheory.net/articles.aspx?id=499; interview at\nhttp://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html\nBEST VIDEO ON P2P:\nhttp://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU\n\nKEEP UP TO DATE through our Delicious tags at http://del.icio.us/mbauwens\n\nThe work of the P2P Foundation is supported by SHIFTN,\nhttp://www.shiftn.com/"],["f","An HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/41b802b7/attachment-0001.html>"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001348.html","od":"Thu Feb 12 03:08:30 CET 2009"},{"f":"Martien van Steenbergen","d":1234424873,"b":[["t","Very interesting. Is this akin to David Chaum's anonymous digital\nmoney? His concept makes sure money is anonymous unless it is\ncompromised, i.e. the same money spent more than once. As soon as it's\ncompromised, the ‘counterfeiter’ is immediately publicly exposed.\n\nAlso, in bitcoin, is there a limited supply of money (that must be\nmanaged)? Or is money created exaclty at the moment of transaction?\n\nSucces en plezier,\n\nMartien."],["q","I've developed a new open source P2P e-cash system called Bitcoin.\nIt's completely decentralized, with no central server or trusted\nparties, because everything is based on crypto proof instead of\ntrust.  Give it a try, or take a look at the screenshots and design\npaper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe root problem with conventional currency is all the trust that's\nrequired to make it work.  The central bank must be trusted not to\ndebase the currency, but the history of fiat currencies is full of\nbreaches of that trust.  Banks must be trusted to hold our money and\ntransfer it electronically, but they lend it out in waves of credit\nbubbles with barely a fraction in reserve.  We have to trust them\nwith our privacy, trust them not to let identity thieves drain our\naccounts.  Their massive overhead costs make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a\nsimilar problem.  Before strong encryption, users had to rely on\npassword protection to secure their files, placing trust in the\nsystem administrator to keep their information private.  Privacy\ncould always be overridden by the admin based on his judgment call\nweighing the principle of privacy against other concerns, or at the\nbehest of his superiors.  Then strong encryption became available to\nthe masses, and trust was no longer required.  Data could be secured\nin a way that was physically impossible for others to access, no\nmatter for what reason, no matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money.  With e-currency based on\ncryptographic proof, without the need to trust a third party\nmiddleman, money can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital\nsignatures.  A digital coin contains the public key of its owner.\nTo transfer it, the owner signs the coin together with the public\nkey of the next owner.  Anyone can check the signatures to verify\nthe chain of ownership.  It works well to secure ownership, but\nleaves one big problem unsolved: double-spending.  Any owner could\ntry to re-spend an already spent coin by signing it again to another\nowner.  The usual solution is for a trusted company with a central\ndatabase to check for double-spending, but that just gets back to\nthe trust model.  In its central position, the company can override\nthe users, and the fees needed to support the company make\nmicropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for\ndouble-spending.  In a nutshell, the network works like a\ndistributed timestamp server, stamping the first transaction to\nspend a coin.  It takes advantage of the nature of information being\neasy to spread but hard to stifle.  For details on how it works, see\nthe design paper at http://www.bitcoin.org/bitcoin.pdf\n\nThe result is a distributed system with no single point of failure.\nUsers hold the crypto keys to their own money and transact directly\nwith each other, with the help of the P2P network to check for\ndouble-spending.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\n_______________________________________________\np2presearch mailing list\np2presearch at listcultures.org\nhttp://listcultures.org/mailman/listinfo/p2presearch_listcultures.org","On 11 Feb 2009, at 23:30 , Satoshi Nakamoto wrote:"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001355.html","od":"Thu Feb 12 08:40:53 CET 2009"},{"f":"Satoshi Nakamoto","d":1234465704,"b":[["q","Very interesting. Is this akin to David Chaum's anonymous digital money?\nHis concept makes sure money is anonymous unless it is compromised, i.e.\nthe same money spent more than once. As soon as it's compromised, the\n‘counterfeiter’ is immediately publicly exposed.","Martien van Steenbergen wrote:"],["t","It's similar in that it uses digital signatures for coins, but different\nin the approach to privacy and preventing double-spending.  The\nrecipient of a Bitcoin payment is able to check whether it is the first\nspend or not, and second-spends are not accepted.  There isn't an\noff-line mode where double-spenders are caught and shamed after the\nfact, because that would require participants to have identities.\n\nTo protect privacy, key pairs are used only once, with a new one for\nevery transaction.  The owner of a coin is just whoever has its private key.\n\nOf course, the biggest difference is the lack of a central server.  That\nwas the Achilles heel of Chaumian systems; when the central company shut\ndown, so did the currency."],["q","Also, in bitcoin, is there a limited supply of money (that must be\nmanaged)? Or is money created exaclty at the moment of transaction?"],["t","There is a limited supply of money.  Circulation will be 21,000,000\ncoins.  Transactions only transfer ownership.\n\nThank you for your questions,\n\nSatoshi\n\nhttp://www.bitcoin.org"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001356.html","s":1,"n":36,"su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/36/","od":"Thu Feb 12 20:01:24 CET 2009"},{"f":"Martien van Steenbergen","d":1234469283,"b":[["q","Martien van Steenbergen wrote:\n> Very interesting. Is this akin to David Chaum's anonymous digital\n> money? His concept makes sure money is anonymous unless it is\n> compromised, i.e. the same money spent more than once. As soon as\n> it's compromised, the ‘counterfeiter’ is immediately publicly\n> exposed.\n\nIt's similar in that it uses digital signatures for coins, but\ndifferent in the approach to privacy and preventing double-\nspending.  The recipient of a Bitcoin payment is able to check\nwhether it is the first spend or not, and second-spends are not\naccepted.  There isn't an off-line mode where double-spenders are\ncaught and shamed after the fact, because that would require\nparticipants to have identities.","On 12 Feb 2009, at 20:01 , Satoshi Nakamoto wrote:"],["t","Thanks for clearing this up."],["q","To protect privacy, key pairs are used only once, with a new one for\nevery transaction.  The owner of a coin is just whoever has its\nprivate key."],["t","IC."],["q","Of course, the biggest difference is the lack of a central server.\nThat was the Achilles heel of Chaumian systems; when the central\ncompany shut down, so did the currency."],["t","Yes, that's really great. Reminds me of:\n\nAardRock » Wizard Rabbit Treasurer; and\nAardRock » Pekunio"],["q","> Also, in bitcoin, is there a limited supply of money (that must be\n> managed)? Or is money created exaclty at the moment of transaction?\n\nThere is a limited supply of money.  Circulation will be 21,000,000\ncoins.  Transactions only transfer ownership."],["t","Would love to also see support for not having to supply and managing\nmoney. Would make it easier and cheaper to maintain and results in\nhave sufficient money, always and everywhere. No scarcity, no\nabundance, exactly the right amount all times, self-organizing.\n\nAre you familiar with Ripple?\n\nIs bitcoin also available as a protocol spec (facilitating differen\nlanguage bindings and implementations; unite on specs, compete on\nimplementation).\n\nSucces en plezier,\n\nMartien."],["f","An HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/9c83bdd1/attachment.html>"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001357.html","od":"Thu Feb 12 21:01:03 CET 2009"},{"f":"Satoshi Nakamoto","d":1234492700,"b":[["q","Would love to also see support for not having to supply and\nmanaging  money. Would make it easier and cheaper to maintain\nand results in have sufficient money, always and everywhere.\nNo scarcity, no abundance, exactly the right amount all times,\nself-organizing.","Martien van Steenbergen wrote:"],["t","That's do-able.  It can be programmed to follow any set of rules.\n\nI see Bitcoin as a foundation and first step if you want to implement\nprogrammable P2P social currencies like Marc's ideas and others\ndiscussed here.  First you need normal, basic P2P currency working.\nOnce that is established and proven out, dynamic smart money is an easy\nnext step.\n\nI love the idea of virtual, non-geographic communities experimenting\nwith new economic paradigms."],["q","Reminds me of:\n\n    * AardRock » Wizard Rabbit Treasurer\n      <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and\n    * AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>"],["t","Indeed, it is much like Pekunio in the concept of spraying redundant\ncopies of every transaction to a number of peers on the network, but the\nimplementation is not a reputation network like Wizard Rabbit Treasurer.\n  In fact, Bitcoin does not use reputation at all.  It sees the network\nas just a big crowd and doesn't much care who it talks to or who tells\nit something, as long as at least one of them relays the information\nbeing broadcast around the network.  It doesn't care because there's no\nway to lie to it.  Either you tell it crypto proof of something, or it\nignores you."],["q","Are you familiar with Ripple?"],["t","As trust systems go, Ripple is unique in spreading trust around rather\nthan concentrating it."],["q","Is bitcoin also available as a protocol spec (facilitating differen\nlanguage bindings and implementations; unite on specs, compete on\nimplementation)."],["t","It would be best to refer to the C++ source code.  I plan to implement\ninterfaces for using the software to send and receive transactions from\nany language, so server side code can easily use it for web based\ne-commerce sites.\n\nSatoshi"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001362.html","s":1,"n":37,"su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/37/","od":"Fri Feb 13 03:31:20 CET 2009"},{"f":"Michel Bauwens","d":1234505958,"b":[["t","Hi Satoshi,\n\nhow operational is your project? how soon do you think people will be able\nto use it in real life?\n\nMichel"],["q","Martien van Steenbergen wrote:\n> Would love to also see support for not having to supply and\n> managing  money. Would make it easier and cheaper to maintain\n> and results in have sufficient money, always and everywhere.\n> No scarcity, no abundance, exactly the right amount all times,\n> self-organizing.\n\nThat's do-able.  It can be programmed to follow any set of rules.\n\nI see Bitcoin as a foundation and first step if you want to implement\nprogrammable P2P social currencies like Marc's ideas and others discussed\nhere.  First you need normal, basic P2P currency working. Once that is\nestablished and proven out, dynamic smart money is an easy next step.\n\nI love the idea of virtual, non-geographic communities experimenting with\nnew economic paradigms.\n\n Reminds me of:\n>\n>    * AardRock » Wizard Rabbit Treasurer\n>      <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and\n>    * AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>\n>\n\nIndeed, it is much like Pekunio in the concept of spraying redundant copies\nof every transaction to a number of peers on the network, but the\nimplementation is not a reputation network like Wizard Rabbit Treasurer.  In\nfact, Bitcoin does not use reputation at all.  It sees the network as just a\nbig crowd and doesn't much care who it talks to or who tells it something,\nas long as at least one of them relays the information being broadcast\naround the network.  It doesn't care because there's no way to lie to it.\n Either you tell it crypto proof of something, or it ignores you.\n\n Are you familiar with Ripple?\n>\n\nAs trust systems go, Ripple is unique in spreading trust around rather than\nconcentrating it.\n\n Is bitcoin also available as a protocol spec (facilitating differen\n> language bindings and implementations; unite on specs, compete on\n> implementation).\n>\n\nIt would be best to refer to the C++ source code.  I plan to implement\ninterfaces for using the software to send and receive transactions from any\nlanguage, so server side code can easily use it for web based e-commerce\nsites.\n\nSatoshi\n\n_______________________________________________\np2presearch mailing list\np2presearch at listcultures.org\nhttp://listcultures.org/mailman/listinfo/p2presearch_listcultures.org","On Fri, Feb 13, 2009 at 9:31 AM, Satoshi Nakamoto <satoshin at gmx.com> wrote:"],["t","--\nThe P2P Foundation researches, documents and promotes peer to peer\nalternatives.\n\nWiki and Encyclopedia, at http://p2pfoundation.net; Blog, at\nhttp://blog.p2pfoundation.net; Newsletter, at\nhttp://integralvisioning.org/index.php?topic=p2p\n\nBasic essay at http://www.ctheory.net/articles.aspx?id=499; interview at\nhttp://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html\nBEST VIDEO ON P2P:\nhttp://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU\n\nKEEP UP TO DATE through our Delicious tags at http://del.icio.us/mbauwens\n\nThe work of the P2P Foundation is supported by SHIFTN,\nhttp://www.shiftn.com/"],["f","An HTML attachment was scrubbed...\nURL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090213/148aa6a5/attachment.html>"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001366.html","od":"Fri Feb 13 07:12:18 CET 2009"},{"f":"Satoshi Nakamoto","d":1234550205,"b":[["q","how operational is your project? how soon do you think people will be\nable to use it in real life?","Michel Bauwens wrote:"],["t","It's fully operational and the network is growing.  If you try the\nsoftware, e-mail me your Bitcoin address and I'll send you a few coins.\n\nWe just need to spread the word and keep getting more people interested.\n\nI'll forward the release introduction in the next message.\n\nSatoshi\n\nhttp://www.bitcoin.org"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001370.html","s":1,"n":38,"su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/38/","od":"Fri Feb 13 19:29:45 CET 2009"}]},{"id":"e18","k":"e","s":"p2p-research","t":"[p2p-research] Bitcoin P2P e-currency v0.1 released","u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001371.html","su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/threads/18/","m":[{"f":"Satoshi Nakamoto","d":1234551161,"b":[["t","Announcing the release of Bitcoin, a new open source peer-to-peer\nelectronic cash system that's completely decentralized, with no central\nserver or trusted parties.  Users hold the crypto keys to their own\nmoney and transact directly with each other, with the help of the P2P\nnetwork to check for double-spending.\n\nWindows NT/2000/XP/Vista.  Open source C++ code is included.\n\nDownload: http://www.bitcoin.org\n\n- Unpack the files into a directory\n- Run BITCOIN.EXE\n- It automatically connects to other nodes\n\nIf you can keep a node running that accepts incoming connections, you'll\nreally be helping the network a lot.  Port 8333 on your firewall needs\nto be open to receive incoming connections.\n\nYou can get coins by getting someone to send you some, or turn on\nOptions->Generate Coins to run a node and generate blocks.  I made the\nproof-of-work difficulty ridiculously easy to start with, so for a\nlittle while in the beginning a typical PC will be able to generate\ncoins in just a few hours.  It'll get a lot harder when competition\nmakes the automatic adjustment drive up the difficulty.  Generated coins\nmust wait 120 blocks to mature before they can be spent.\n\nThere are two ways to send money.  If the recipient is online, you can\nenter their IP address and it will connect, get a new public key and\nsend the transaction with comments.  If the recipient is not online, it\nis possible to send to their Bitcoin address, which is a hash of their\npublic key that they give you.  They'll receive the transaction the next\ntime they connect and get the block it's in.  This method has the\ndisadvantage that no comment information is sent, and a bit of privacy\nmay be lost if the address is used multiple times, but it is a useful\nalternative if both users can't be online at the same time or the\nrecipient can't receive incoming connections.\n\nTotal circulation will be 21,000,000 coins.  It'll be distributed to\nnetwork nodes when they make blocks, with the amount cut in half every 4\nyears.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed.\nIt's based on open market competition, and there will probably always be\nnodes willing to process transactions for free.\n\nSatoshi Nakamoto\n\nhttp://www.bitcoin.org"]],"u":"https://diyhpl.us/~bryan/irc/bitcoin-satoshi/p2presearch-again/p2pfoundation.net/backups/p2p_research-archives/2009-February/001371.html","s":1,"n":39,"su":"https://satoshi.nakamotoinstitute.org/emails/p2p-research/39/","od":"Fri Feb 13 19:45:41 CET 2009"}]},{"id":"p1","k":"p","s":"p2pfoundation","t":"Bitcoin open source implementation of P2P currency","u":"http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source","su":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/threads/1/","m":[{"f":"Satoshi Nakamoto","d":1234391220,"b":[["t","I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe 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, but the history of fiat currencies is full of breaches of that trust. 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. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a similar problem. 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 weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money. With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital signatures. A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership. It works well to secure ownership, but leaves one big problem unsolved: double-spending. Any owner could try to re-spend an already spent coin by signing it again to another owner. 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, and the fees needed to support the company make micropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, 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\n\nThe 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.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org "]],"u":"http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source","s":1,"n":1,"su":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","qt":["I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper: \n\nDownload Bitcoin v0.1 at http://www.bitcoin.org","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, but the history of fiat currencies is full of breaches of that trust.","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. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.","A generation ago, multi-user time-sharing computer systems had a similar problem. 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 weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.","With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.","A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership.","Any owner could try to re-spend an already spent coin by signing it again to another owner. 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, and the fees needed to support the company make micropayments impractical. \nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, 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.","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."],"qc":["banks","bitcoin-design","cryptocurrency","double-spending","economics","encryption","micropayments","privacy","releases","transactions"]},{"f":"Sepp Hasslberger","d":1234449840,"b":[["t","Great stuff.\n\nThis is the first real innovation in money since the Bank of England started to issue its promissory notes for gold in the vaults, which then became known as banknotes.\n\nI believe an open source currency has great potential. A bit like Google becoming the default search engine for many of us."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9416"},{"f":"Sepp Hasslberger","d":1234625400,"b":[["t","Dante <http://p2pfoundation.ning.com/profile/DanteGabryellMonson>, in an email, has mentioned a UK project called Open Coin. It seems to go in a similar direction.\n\nCould there be synergies with bitcoin?\n\nhttp://opencoin.org/"]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9478"},{"f":"Satoshi Nakamoto","d":1234716120,"b":[["t","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.\n\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."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9493","s":1,"n":2,"su":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/2/","qt":["A 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."],"qc":["cryptocurrency"]},{"f":"Joerg Baach","d":1234867320,"b":[["t","Hi Satoshi,\n\nwe are actually really talking about the old Chaumian central stuff. That was because a) it was there b) it was patent free (we have to think a bit about the US). I had a read of your paper on the weekend - thanks a lot for doing that work. Interesting read.\n\nWhat I did not understand about your system - how would you use it for a currency of any sort? Everybody can create a coin as they like, as far as I understood, so therefore there is no trusted supply of tokens / coins.\nOr the other way around: if you don't trust the double spending database, because its a central instance, you surely couldn't trust a central issuer to issue and redeem. How would a currency work otherwise? Would you use it for a mutual credit system in which the transactions are shown online?\n\nCheers,\n\nJoerg"]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9543"},{"f":"Sepp Hasslberger","d":1234968060,"b":[["t","I have two questions, Satoshi.\n\nthe first one ties in with Joerg's doubts about the trusted supply of tokens/coins.\n\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?\n\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.\n\nIs there a formula to decide on what should be the total amount of tokens, and if so, what is the formula?\n\nIf there is no formula, who gets to make that decision and based on what criteria will it be made?\n\nI will keep my second question for later. One thing at a time..."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9559"},{"f":"Satoshi Nakamoto","d":1234990200,"b":[["t","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\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\n\nYou could say coins are issued by the majority. They are issued in a limited, predetermined amount.\n\nAs an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything.\n\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.\n\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."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9562","s":1,"n":3,"su":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/3/","qt":["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\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","You could say coins are issued by the majority. They are issued in a limited, predetermined amount.","To 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.","In 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."],"qc":["bitcoin-design","bitcoin-economics"]},{"f":"Sepp Hasslberger","d":1235119980,"b":[["t","So in other words, \"the early adopter finds the worm\" in this system.\n\nThis would mean that - the earlier someone gets in on the bitcoin system establishing a node, the more chance they have of becoming lucky and being able to generate coins. Nothing against that, it would work to promote adoption of the system.\n\nHowever there should also be a method of adjusting the total number of coins extant. I would propose to link the total number of coins to the number of active nods.\n\nThis way, you have two parameters that keep a balance. One is the halving of coins given per block, the other is a continual (or periodic?) adjustment of the target total of coins to the number of active users. That should self-balance the system.\n\nThe reason balance of the system is important: if it's going to be used for payments, you don't want to have large changes in the value of the coins. It would lead to distortions, I believe, by continually increasing the \"purchasing power\" of a single coin.\n\nStability of the coins' value is desirable for long term use."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:9578"},{"f":"Russ Nelson","d":1268674020,"b":[["t","The London Mint was unable to make enough small coins in Isaac Newton's day. Private minters stepped in. If bitcoin can't make enough coins and small enough coins so that people can trade at the value they want, then it will be replaced by something that can."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17271"},{"f":"Robert Searle","d":1269083280,"b":[["t","As far as I can understand it we are dealing here with another glorified form of LETS, or CCs in electronic form ofcourse. The question is this. How will this help to change the big issues of our world such as global warming, food security, population, et al? This is what really matters at the end of the day. Moreover, whether we like it, or not ,we still have to deal with the \"big boys\" (ie. governments, corporations, banks,et al) at some point.\n\nOfcourse, if most people were to accept a new decentralised \"made up\" currency (sans banks,and bankers)then we would\nhave something serious to discuss about!!! As far as I am concerned energies would be better spent in improving my project known as Transfinancial Economics."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17278"},{"f":"Russ Nelson","d":1269292080,"b":[["t","No, nothing like LETS at all. LETS is book entry for one, and for another the total amount of currency is always zero. When you issue a credit to someone else because they've done something for you, you receive a debit. The trouble with a LETS is that you can walk away from an account which is in debit. That functions to inflate the currency -- more people have credits who want something than there are people to do or sel something for the credits.\n\nLETS was invented by somebody who doesn't understand money, and promulgated by more people who don't understand money."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17280"},{"f":"Michel Bauwens","d":1269414840,"b":[["t","Dear Satoshi,\n\nCould you propose a text for our regular p2p blog, with eventual responses to the main questions here? Our regular blog has a lot more readers (about 10x) than our Ning community blog,\n\nMichel"]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:17285"},{"f":"Jost Reinert","d":1294395780,"b":[["t","Quite interesting project. I am curator of a micro-currency in Germany called Rheingold.\n\nIt is based on cash. Therefore the problem of \"trust\" is not solved. However, we do not have a central bank giving money as credit, but here, every single issuer of his own money gets it printed himself. So Rheingold is rather a group of many de-central-banks. Therefore the seignorage everybody gains himself.\n\nAnd our money is debt-free.\n\n \n\nI would like to promote your project on our blog http://rheingoldblog.wordpress.com. Maybe you could even become Rheingolder yourself with your own cashbill. Since we pretend to be an art-project, the whole project will be shown in a museum in future. We already have more than 1.000 members, mostly in Germany. Our website http://www.rheingoldregio.de\n\nAny idea about a cooperation?\n\n "]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:18222"},{"f":"Satoshi Nakamoto","d":1394155020,"b":[["t","I am not Dorian Nakamoto."]],"u":"http://p2pfoundation.ning.com/xn/detail/2003008:Comment:52186","s":1,"n":4,"su":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/4/","qt":["I am not Dorian Nakamoto."],"qc":["identity"],"w":"Because this post was made years after Satoshi’s acknowledged disappearance, its authenticity demands scrutiny. In one instance, Satoshi’s P2P Foundation account was compromised due to an email hack in September 2014, although there is currently no clear indication that the account was compromised at the prior time of this post. Read more about the hack here.","wu":"https://blog.bitmex.com/satoshis-2014-email-hack/"}]},{"id":"p2","k":"p","s":"bitcointalk","t":"Welcome to the new Bitcoin forum!","u":"https://bitcointalk.org/index.php?topic=5","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/2/","m":[{"f":"satoshi","d":1258913068,"b":[["t","Welcome to the new Bitcoin forum!\n\nThe old forum can still be reached here:\nhttp://bitcoin.sourceforge.net/boards/index.php\n\nI'll repost some selected threads here and add updated answers to questions where I can.\n\nFAQ\nhttp://bitcoin.sourceforge.net/wiki/index.php?page=FAQ\n\nDownload\nhttp://sourceforge.net/projects/bitcoin/files/"]],"u":"https://bitcointalk.org/index.php?topic=5.msg28#msg28","s":1,"n":5,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/5/"}]},{"id":"p3","k":"p","s":"bitcointalk","t":"Repost: Bitcoin Maturation","u":"https://bitcointalk.org/index.php?topic=6","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/3/","m":[{"f":"satoshi","d":1258914704,"b":[["t","--------------------\nbitcoinbitcoin:\nBitcoin Maturation\nPosted:Thu 01 of Oct, 2009 (14:12 UTC)\n\nFrom the user's perspective the bitcoin maturation process can be broken down into 8 stages.\n\n1. The initial network transaction that occurs when you first click Generate Coins.\n2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.\n3. The change of the bitcoin entry from outside the All Transaction field to inside it.\n4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).\n5. The change of the Description to Generated (50.00 matures in x more blocks).\n6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.\n7 The change of the Description to Generated.\n8. The time after the Description has changed to Generated.\n\nWhich stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?\n\n--------------------\nsirius-m:\nRe: Bitcoin Maturation\nPosted:Thu 22 of Oct, 2009 (02:36 UTC)\n\nAs far as I know, there's no network transaction when you click Generate Coins - your computer just starts calculating the next proof-of-work.  The CPU usage is 100% when you're generating coins.\n\nIn this example, 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."]],"u":"https://bitcointalk.org/index.php?topic=6.msg29#msg29","s":1,"n":6,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/6/"},{"f":"satoshi","d":1258914861,"b":[["t","It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.\n\n1) 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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=6.msg31#msg31","s":1,"n":8,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/8/","qt":["Think 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."],"qc":["mining"]}]},{"id":"p4","k":"p","s":"bitcointalk","t":"Repost: Request: Make this anonymous?","u":"https://bitcointalk.org/index.php?topic=7","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/4/","m":[{"f":"satoshi","d":1258914720,"b":[["t","--------------------\nanonguy54:\nRequest: Make this anonymous?\nPosted:Thu 15 of Oct, 2009 (19:58 UTC)\n\nAre there any plans to make this service anonymous?\n\ne.g; Being able to route BitCoin through Tor."]],"u":"https://bitcointalk.org/index.php?topic=7.msg30#msg30","s":1,"n":7,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/7/"},{"f":"satoshi","d":1258914915,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=7.msg32#msg32","s":1,"n":9,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/9/"},{"f":"Suggester","d":1265482209,"b":[["q","--------------------\nanonguy54:\nRequest: Make this anonymous?\nPosted:Thu 15 of Oct, 2009 (19:58 UTC)\n\nAre there any plans to make this service anonymous?\n\ne.g; Being able to route BitCoin through Tor.","Quote from: satoshi on November 22, 2009, 06:32:00 PM"],["t","Someone correct me people, but I thought it IS already anonymous! Can the person I'm transferring money to know my IP or something?"]],"u":"https://bitcointalk.org/index.php?topic=7.msg262#msg262"},{"f":"satoshi","d":1265490392,"b":[["t","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.\n\nIf you send by IP, the recipient sees you because you connect to their IP.  You could use TOR to mask that.\n\nYou could use TOR if you don't want anyone to know you're even using Bitcoin.\n\nBitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution."]],"u":"https://bitcointalk.org/index.php?topic=7.msg264#msg264","s":1,"n":45,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/45/","qt":["Bitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution.","You could use TOR if you don't want anyone to know you're even using Bitcoin."],"qc":["privacy"]},{"f":"giik","d":1265570390,"b":[["q","You could use TOR if you don't want anyone to know you're even using Bitcoin.\n\nBitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution.","Quote from: satoshi on February 06, 2010, 09:06:32 PM"],["t","Tor is a extra layer of privacy and anonimity, but it isn't the ultimate answer. Check out http://www.torproject.org/download.html.en#Warning, to understand what Tor does and doesn't do for you."]],"u":"https://bitcointalk.org/index.php?topic=7.msg277#msg277"},{"f":"Xunie","d":1265948591,"b":[["t","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:\n\n• So what exactly does Bitcoin send when it connects to an IP?\n\n• Is everything encrypted that we send over the line?\n\n• Can someone 'steal' bitcoins by listening at the end of a proxy (or in Tor's case an \"exit node\")?\n\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\"."]],"u":"https://bitcointalk.org/index.php?topic=7.msg317#msg317"},{"f":"satoshi","d":1265995712,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=7.msg324#msg324","s":1,"n":54,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/54/"}]},{"id":"p5","k":"p","s":"bitcointalk","t":"Repost: How anonymous are bitcoins?","u":"https://bitcointalk.org/index.php?topic=8","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/5/","m":[{"f":"satoshi","d":1259172957,"b":[["t","--------------------\nbitcoinbitcoin:\nHow anonymous are bitcoins?\n\nCan 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? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?"]],"u":"https://bitcointalk.org/index.php?topic=8.msg33#msg33","s":1,"n":10,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/10/"},{"f":"satoshi","d":1259173043,"b":[["t","> Can nodes on the network tell from which and or to which bitcoin\n> address coins are being sent? Do blocks contain a history of where\n> bitcoins have been transfered to and from?\n\nBitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.\n\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.\n\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.\n\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.\n\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.\n\n> Can nodes tell which bitcoin addresses belong to which IP addresses?\n\nNo.\n\n> Is there a command line option to enable the sock proxy the first\n> time that bitcoin starts?\n\nIn 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\n\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>\n\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.\n\n> What happens if you send bitcoins to an IP address that has multiple\n> clients connected through network address translation (NAT)?\n\nWhichever 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\"\n\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."]],"u":"https://bitcointalk.org/index.php?topic=8.msg34#msg34","s":1,"n":11,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/11/","qt":["For greater privacy, it's best to use bitcoin addresses only once."],"qc":["privacy","transactions"]}]},{"id":"p6","k":"p","s":"bitcointalk","t":"Repost: Linux/UNIX compile","u":"https://bitcointalk.org/index.php?topic=9","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/6/","m":[{"f":"satoshi","d":1259342242,"b":[["t","--------------------\nscott:\nLinux/UNIX compile\nPosted:Thu 08 of Oct, 2009 (05:49 UTC)\n\nCan we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great."]],"u":"https://bitcointalk.org/index.php?topic=9.msg36#msg36","s":1,"n":12,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/12/"},{"f":"satoshi","d":1259342829,"b":[["t","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.\n\nCommand line is on the to-do list after 0.2."]],"u":"https://bitcointalk.org/index.php?topic=9.msg37#msg37","s":1,"n":13,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/13/"}]},{"id":"p7","k":"p","s":"bitcointalk","t":"[OLD THREAD] Bitcoin version 0.2 development status","u":"https://bitcointalk.org/index.php?topic=10","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/7/","m":[{"f":"satoshi","d":1259362119,"b":[["t","We've been working hard on improvements for the next version release.  Martti (sirius-m) added some nice features to make it more user friendly and easier to run in the background:\n - Minimize to system tray option\n - Autostart on boot option so you can keep it running in the background automatically\n - New options dialog layout\n - Setup EXE for Windows, in addition to the archive download\n\nI've been working on a number of refinements to the networking code and laying the groundwork for future functionality.  Also coming in version 0.2:\n - Multi-processor support for coin generation\n - Proxy support"]],"u":"https://bitcointalk.org/index.php?topic=10.msg38#msg38","s":1,"n":14,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/14/"}]},{"id":"p8","k":"p","s":"bitcointalk","t":"A few suggestions","u":"https://bitcointalk.org/index.php?topic=12","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/8/","m":[{"f":"madhatter","d":1260336886,"b":[["t","Hey,\n\nFirst off I must say that this is an amazing concept. I have been dreaming of a P2P money system for a LONG time.\n\nYou have my complete kudos and respect.\n\nI have a few suggestions:\n\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\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\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\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\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\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).\n\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg40#msg40"},{"f":"satoshi","d":1260384310,"b":[["t","Helpful suggestions, thanks."],["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.","Quote from: madhatter on December 09, 2009, 05:34:46 AM"],["t","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."],["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.","Quote"],["t","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.  "],["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.","Quote"],["t","That's one of the main things on the agenda after 0.2."],["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).","Quote"],["t","Yeah, the other stealth stuff would be kinda pointless if it's always the same port number."],["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.","Quote"],["t","I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default?"],["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).","Quote"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=12.msg41#msg41","s":1,"n":15,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/15/"},{"f":"nanaimogold","d":1260386731,"b":[["t","Thank you for this effort. A P2P payment system has been needed for a long time.\n\nShane"]],"u":"https://bitcointalk.org/index.php?topic=12.msg42#msg42"},{"f":"The Madhatter","d":1260453617,"b":[["t","Most modern P2P software tries UPnP by default. You can (of course) disable it (usually) in the options.\n\nHmm. I had thought about that as well. Your first idea is probably best. That way you can run the server daemon \"headless\" and have your choice of a front end. (One of the front ends could be a PHP [or C++ CGI] program that runs on your favorite webserver).\n\nThis would also enable you to run the front end and back end on different machines. (Ex. headless on a linux server that has a static IP to make receiving payments easier [pay by ip mode] and a front end client for management that can be ran on windows/mac/or something else). Front ends can also be ran on clients with very low cpu power such as mobile phones. *nudge nudge* Wink\n\nOne other thing I have thought of is the seeding. The app could be pre-seeded before downloading. You could prepare a new archive daily that is pre-seeded. That would do away with the IRC connection. (Or it could be used as a fallback, I suppose. I still haven't audited the IRC connection code. I am thinking of a few exploits but I don't want to mention them until I am sure they exist.) Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR. Tongue\n\nAlso 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).\n\nCan you give me CVS access or something? (If not, can I send you patches?) I'd like to help out. I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.\n\nCheers! Smiley"],["q","I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default?\n\nI'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?","Quote from: satoshi on December 09, 2009, 06:45:10 PM"]],"u":"https://bitcointalk.org/index.php?topic=12.msg44#msg44"},{"f":"satoshi","d":1260473509,"b":[["q","Front ends can also be ran on clients with very low cpu power such as mobile phones.","Quote from: madhatter2 on December 10, 2009, 02:00:17 PM"],["t","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."],["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.","Quote"],["t","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."],["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).","Quote"],["t","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.\n\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."],["q","Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.","Quote"],["t","It's SVN on sourceforge.  PM or e-mail me your sourceforge account and I'll give you access."],["q","I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.","Quote"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=12.msg45#msg45","s":1,"n":16,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/16/"},{"f":"The Madhatter","d":1260507559,"b":[["t","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)\n\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...\n\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.\n\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).\n\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. Smiley\n\nIn any event, I would like to help. I have a lot of time and a project like this one is very exciting.\n\nThanks for letting me be a part of it. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg47#msg47"},{"f":"satoshi","d":1260559675,"b":[["t","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."],["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.","Quote from: madhatter2 on December 11, 2009, 04:59:19 AM"],["t","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.\n\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)\n\nTo only run a seed:\nbitcoin -min -gen=0\n\nYou could sort of monitor it by looking at debug.log.  To stop it, kill the process, the database won't mind.\n\nTo generate:\nbitcoin -min -gen\n\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."],["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).","Quote"],["t","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.  "],["q","In any event, I would like to help. I have a lot of time and a project like this one is very exciting.","Quote"],["t","That's great, any help is really appreciated!"]],"u":"https://bitcointalk.org/index.php?topic=12.msg50#msg50","s":1,"n":19,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/19/"},{"f":"The Madhatter","d":1260599661,"b":[["t","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! Wink 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.\n\nI already run a great deal of TOR and I2P nodes so for me to add this app to those same servers is a snap. Smiley\n\nI 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.\n\nI'll keep toying around with the source code and see what I can come up with.\n\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg51#msg51"},{"f":"SmokeTooMuch","d":1260623297,"b":[["t","Suggestion :\n\nSince the coins are generated faster on fast machines, many people will want to use their GPU power to do this, too.\n\nSo, my suggestion is to implement a GPU-computing support using ATI Stream and Nvidia CUDA."]],"u":"https://bitcointalk.org/index.php?topic=12.msg52#msg52"},{"f":"satoshi","d":1260640364,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=12.msg54#msg54","s":1,"n":20,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/20/","qt":["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.","We 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."],"qc":["mining"]},{"f":"satoshi","d":1260641830,"b":[["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! Wink 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.","Quote from: madhatter2 on December 12, 2009, 06:34:21 AM"],["t","Mac support would be nice.  wxWidgets really pays off for cross platform.\n\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.\n\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."],["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.","Quote"],["t","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.\n\nI'd rather have command line control, that would get us remote admin and batch automation."]],"u":"https://bitcointalk.org/index.php?topic=12.msg55#msg55","s":1,"n":21,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/21/"},{"f":"sirius","d":1260643665,"b":[["q","given any thought to using autoconf?","Quote from: madhatter2 on December 12, 2009, 06:34:21 AM"],["t","I'd choose cmake instead of autoconf if we want build automation at some point."]],"u":"https://bitcointalk.org/index.php?topic=12.msg57#msg57"},{"f":"SmokeTooMuch","d":1260650774,"b":[["t","Suggestion:\n\nAdd IPv6-Support for payments."]],"u":"https://bitcointalk.org/index.php?topic=12.msg58#msg58"},{"f":"The Madhatter","d":1260686644,"b":[["t","Okay, Mac PPC is EOL now anyway. Console mode would be awesome."]],"u":"https://bitcointalk.org/index.php?topic=12.msg59#msg59"},{"f":"The Madhatter","d":1260686790,"b":[["t","Um, so command line only mode could be selected at compile-time? Perhaps with a define? And that would shut off the graphical UI stuff?\n\nJust want to be on the same page here. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg60#msg60"},{"f":"The Madhatter","d":1260687005,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=12.msg61#msg61"},{"f":"satoshi","d":1260723085,"b":[["t","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.\n\nThen a separate command line utility to communicate with it to do things.  Not sure what it should be named.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=12.msg62#msg62","s":1,"n":22,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/22/"},{"f":"The Madhatter","d":1260782984,"b":[["t","Okay, thanks for the tips. I am going to try running bitcoin 0.2/svn on FreeBSD tonight in console-only mode. I'll create some notes / patches / etc."]],"u":"https://bitcointalk.org/index.php?topic=12.msg63#msg63"},{"f":"The Madhatter","d":1260796188,"b":[["t","Got it working on FreeBSD! I'll submit my work here soon.\n\n$gmake -f makefile.fbsd     \ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o headers.h.gch headers.h\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/util.o util.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/script.o script.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/db.o db.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/net.o net.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/main.o main.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/market.o market.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/ui.o ui.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/uibase.o uibase.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -O3 -o obj/sha.o sha.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o obj/irc.o irc.cpp\ng++ -O0 -Wno-invalid-offsetof -Wformat  -D__WXGTK__ -DNOPCH -DBUILD_FREEBSD -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/db47\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\" -o bitcoin -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/usr/local/lib/db47\" obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o obj/ui.o obj/uibase.o obj/sha.o obj/irc.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l db_cxx -Wl,-Bdynamic -l wx_base-2.8 -l wx_gtk2_core-2.8 -l wx_gtk2_html-2.8 -l wx_gtk2_richtext-2.8 -l crypto -l gtk-x11-2.0 -l gthread-2.0 -l SM\n$ file ./bitcoin\n./bitcoin: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 7.2, dynamically linked (uses shared libs), FreeBSD-style, not stripped"]],"u":"https://bitcointalk.org/index.php?topic=12.msg64#msg64"},{"f":"The Madhatter","d":1260802899,"b":[["t","Can anyone shed some light here?\n\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\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:421: error: no matching function for call to 'CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*&, <anonymous enum>, const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'\nuibase.h:673: note: candidates are: CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(wxWindow*, wxWindowID, const wxString&, const wxPoint&, const wxSize&, long int)\nuibase.h:651: note:                 CGetTextFromUserDialogBase::CGetTextFromUserDialogBase(const CGetTextFromUserDialogBase&)\nui.h:423: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'\n/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)\nui.h:424: 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&)\nui.h:428: error: no matching function for call to 'wxStaticText::SetLabel(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'\n/usr/local/include/wx-2.8/wx/mac/carbon/stattext.h:38: note: candidates are: virtual void wxStaticText::SetLabel(const wxString&)\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&)\nmake: *** [headers.h.gch] Error 1"]],"u":"https://bitcointalk.org/index.php?topic=12.msg66#msg66"},{"f":"satoshi","d":1260810956,"b":[["q","Can anyone shed some light here?\n\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&)","Quote from: madhatter2 on December 14, 2009, 03:01:39 PM"],["t","It looks like the implicit conversion from std::string to wxString isn't working.  That's used everywhere, the conversion needs to work.\n\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.\n\nIt's probably some wxWidgets compile defines or build configuration.  What \"configure\" options did you use?\n\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)\n\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\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__\""]],"u":"https://bitcointalk.org/index.php?topic=12.msg67#msg67","s":1,"n":23,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/23/"},{"f":"The Madhatter","d":1260854469,"b":[["t","Okay, I will look into the std::string issue. It is also throwing the same std::string issue on the latest version of Ubuntu Linux. So this isn't just OSX related. I have to say that my main background is C, not C++ so I am still learning some of the C++ data types/headers/and other specifics \"as I go\". Smiley\n\nThere are only defines for __WXCOCOA__ and __WXMAC__ in wx/defs.h (I must be missing something here..maybe my wxwidgets needs to be rebuilt -- I'll try that). I have tried combinations of those existing defines without success. The other option is to use gtk on OSX but the windowing will be slower and (my opinion) \"ugly\". Carbon would be the best selection for OSX.  I'll keep hacking at it until I get it working. Smiley\n\nI also now have a working startup script for FreeBSD that will launch xorg's virtual framebuffer onto the localhost, fire up bitcoin and have the X11 screen output get stuffed into memory (instead of the monitor). This is a real big hack, but it does enable someone to run bitcoin as a pseudo unix daemon. I have had the code running for over 12h now and I don't detect any memory leaks or other weirdness.\n\nAlso I have a simple network monitor that will detect if bitcoin has crashed/stopped responding on port 8333, send me a page, and start the daemon back up again. This setup is ideal. I have started deploying seeds on servers I control that are all over the world. Smiley\n\nOne 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?\n\nI will include these tools once I get SF setup.\n\nCheers!"]],"u":"https://bitcointalk.org/index.php?topic=12.msg68#msg68"},{"f":"The Madhatter","d":1260855053,"b":[["t","Okay, I am on SF now. Username \"madhatter2\".\n\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg69#msg69"},{"f":"satoshi","d":1260909452,"b":[["q","It is also throwing the same std::string issue on the latest version of Ubuntu Linux.","Quote from: madhatter2 on December 15, 2009, 05:21:09 AM"],["t","Then it must be something you're doing differently with building or configuring wxWidgets.\n\nWhat options did you use on the wxWidgets \"configure\" script?  The options I used are in build-unix.txt."],["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?","Quote"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=12.msg70#msg70","s":1,"n":24,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/24/"},{"f":"The Madhatter","d":1260911653,"b":[["t","I used the default build options. I will try the options from your txt file. On FreeBSD it just worked right from the normal ports system. Which is excellent. It means that installing bitcoin via the same ports system (my goal) will be a snap.\n\nYes, the debug.log has the proper permissions. I'll re-read the source. There must be something I am missing."]],"u":"https://bitcointalk.org/index.php?topic=12.msg71#msg71"},{"f":"sirius","d":1260978563,"b":[["t","I worked around the string problem by using wxWidgets 2.9. It worked with the default configuration."]],"u":"https://bitcointalk.org/index.php?topic=12.msg72#msg72"},{"f":"The Madhatter","d":1261056109,"b":[["t","[madhatter@10 /home/madhatter/src/bitcoin]# diff -u headers.h.orig headers.h     \n--- headers.h.orig      2009-12-14 12:29:39.000000000 +0000\n+++ headers.h   2009-12-14 12:41:08.000000000 +0000\n@@ -35,7 +35,12 @@\n #include <limits.h>\n #include <float.h>\n #include <assert.h>\n+#ifndef BUILD_FREEBSD //malloc.h is part of stdlib.h on FreeBSD\n #include <malloc.h>\n+#endif\n+#ifdef BUILD_FREEBSD\n+#include <netinet/in.h>\n+#endif\n #include <memory>\n #define BOUNDSCHECK 1\n #include <sstream>\n\n[madhatter@10 /home/madhatter/src/bitcoin]# cat makefile.fbsd\n# Copyright (c) 2009 Satoshi Nakamoto\n# Distributed under the MIT/X11 software license, see the accompanying\n# file license.txt or http://www.opensource.org/licenses/mit-license.php.\n\nifneq \"$(BUILD)\" \"debug\"\nifneq \"$(BUILD)\" \"release\"\nBUILD=debug\nendif\nendif\nifeq \"$(BUILD)\" \"debug\"\nD=d\nDEBUGFLAGS=-g\nendif\n\nINCLUDEPATHS= \\\n -I\"/usr/include\" \\\n -I\"/usr/local/include\" \\\n -I\"/usr/local/include/db47\" \\\n -I\"/usr/local/include/wx-2.8\" \\\n -I\"/usr/local/lib/wx/include/gtk2-ansi-release-2.8\"\n\nLIBPATHS= \\\n -L\"/usr/lib\" \\\n -L\"/usr/local/lib\" \\\n -L\"/usr/local/lib/db47\"\n\nLIBS= \\\n -Wl,-Bstatic \\\n   -l boost_system -l boost_filesystem \\\n   -l db_cxx \\\n -Wl,-Bdynamic \\\n   -l wx_base-2.8 \\\n   -l wx_gtk2_core-2.8 \\\n   -l wx_gtk2_html-2.8 \\\n   -l wx_gtk2_richtext-2.8 \\\n   -l crypto \\\n   -l gtk-x11-2.0 -l gthread-2.0 -l SM\n\nWXDEFS=-D__WXGTK__ -DNOPCH -DBUILD_FREEBSD\nCFLAGS=-O0 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(WXDEFS) $(INCLUDEPATHS)\nHEADERS=headers.h util.h main.h serialize.h uint256.h key.h bignum.h script.h db.h base58.h\n\nall: bitcoin\n\nheaders.h.gch: headers.h $(HEADERS) net.h irc.h market.h uibase.h ui.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/util.o: util.cpp                $(HEADERS)\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/script.o: script.cpp            $(HEADERS)\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/db.o: db.cpp                    $(HEADERS) market.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/net.o: net.cpp                  $(HEADERS) net.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/main.o: main.cpp                $(HEADERS) net.h market.h sha.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/market.o: market.cpp            $(HEADERS) market.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/ui.o: ui.cpp                    $(HEADERS) net.h uibase.h ui.h market.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/uibase.o: uibase.cpp            uibase.h\n        g++ -c $(CFLAGS) -o $@ $<\n\nobj/sha.o: sha.cpp                  sha.h\n        g++ -c $(CFLAGS) -O3 -o $@ $<\n\nobj/irc.o: irc.cpp                  $(HEADERS)\n        g++ -c $(CFLAGS) -o $@ $<\n\nOBJS=obj/util.o obj/script.o obj/db.o obj/net.o obj/main.o obj/market.o \\\n        obj/ui.o obj/uibase.o obj/sha.o obj/irc.o\n\nbitcoin: headers.h.gch $(OBJS)\n        g++ $(CFLAGS) -o $@ $(LIBPATHS) $(OBJS) $(LIBS)\n\nclean:\n        -rm obj/*\n        -rm headers.h.gch"]],"u":"https://bitcointalk.org/index.php?topic=12.msg75#msg75","sj":"FreeBSD build patch"},{"f":"The Madhatter","d":1261056223,"b":[["t","To build on FreeBSD:\n\nInstall all of the required software from /usr/ports and then compile using the makefile.fbsd\n\n\"It just works\". Smiley"]],"u":"https://bitcointalk.org/index.php?topic=12.msg76#msg76"},{"f":"satoshi","d":1261075086,"b":[["t","That's good, is it running fine on FreeBSD?\n\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\n\nmalloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble."]],"u":"https://bitcointalk.org/index.php?topic=12.msg77#msg77","s":1,"n":26,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/26/"},{"f":"The Doctor","d":1261149113,"b":[["t","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.\n\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 Settings\\username\\Application Data\\Bitcoin directory.  In effect, using a portable version of Bitcoin to eventually grow a portable wallet."]],"u":"https://bitcointalk.org/index.php?topic=12.msg78#msg78"},{"f":"satoshi","d":1261157868,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=12.msg79#msg79","s":1,"n":27,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/27/"}]},{"id":"p9","k":"p","s":"bitcointalk","t":"Questions about Bitcoin","u":"https://bitcointalk.org/index.php?topic=13","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/9/","m":[{"f":"SmokeTooMuch","d":1260450831,"b":[["t","Hi, yesterday I stumbled upon this great payment option.\n\nI read my way through many sites but now I have some questions that couldn't get answered.\n\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?\n\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?\n\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?\n\n4. What files need to be backed up for not losing my \"money\"? Only the wallet.dat or the whole Bitcoin AppData directory ?\n\n5. 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?\n\n6. 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?)\n\n7. 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 ?\n\n8. I`m afraid I didn`t understand everything about the bitcoin creation. How many coins are created by a machine in 24h in average?\n\n9. 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?\n\n10. 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.\n\n11. I`ve seen a formular to clalculate 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?\n\n12. Are there any other exchanging systems or potential payment partners except for new liberty standard?\n\n13. 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?)\n\n14. Is there a way to see how many bitcoins have been generated this far? And how old is Bitcoin already?\n\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.\n\n(Sorry for my bad English...)\n\nEDIT 2014-10-31: grammar and typos"]],"u":"https://bitcointalk.org/index.php?topic=13.msg43#msg43"},{"f":"satoshi","d":1260478142,"b":[["t","1-3:\nFor 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\n4:\nVersion 0.1.5: backup the whole %appdata%\\Bitcoin directory.\nVersion 0.2: you can backup just wallet.dat.\n\n5:\nNope.  The whole design is all about preventing that from working.\n\n6:\nThose 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.\n\n7:\nIt's currently 29,296 blocks.  The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.  \n\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.\n\n8:\nTypically a few hundred right now.  It's easy now but it'll get harder as the network grows.\n\n9:\nGood question, it's TCP.  The website needs to be updated to say TCP port 8333.\n\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.\n\n10:\nNo, the other nodes won't accept that.\n\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.\n\n11:\nSlower machines produce fewer coins.  It's proportional to CPU speed.\n\n12:\nThere are more coming.\n\n13:\nIt 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.\n\n14:\nFor 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."]],"u":"https://bitcointalk.org/index.php?topic=13.msg46#msg46","s":1,"n":17,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/17/","qt":["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.","Being 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."],"qc":["bitcoin-economics","trusted-third-parties"]},{"f":"SmokeTooMuch","d":1260552029,"b":[["t","Wow, thanks alot for these detailed answers.\n\nBut today another question came to my mind.\n\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).\n\nAlso, we know that he uses WLAN and his network is unsecured or weak protected. Same goes for router configuration.\n\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.\n\nIs this actually going to work ?\n\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.)\n\nBTW: same should work when you are on a LAN party with unprotected router config.\n\nEdit: Or 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 ?"]],"u":"https://bitcointalk.org/index.php?topic=13.msg48#msg48"},{"f":"satoshi","d":1260554337,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=13.msg49#msg49","s":1,"n":18,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/18/"}]},{"id":"p10","k":"p","s":"bitcointalk","t":"Bitcoin 0.2 released!","u":"https://bitcointalk.org/index.php?topic=16","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/10/","m":[{"f":"satoshi","d":1261003536,"b":[["t","Bitcoin version 0.2 is here!\n\nDownload links:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download\n\nNew Features\n\nMartti Malmi\n - Minimize to system tray option\n - Autostart on boot option so you can keep it running in the background automatically\n - New options dialog layout for future expansion\n - Setup program for Windows\n - Linux version (tested on Ubuntu)\nSatoshi Nakamoto\n - Multi-processor support for coin generation\n - Proxy support for use with TOR\n - Fixed some slowdowns in the initial block download\n\nMajor thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version."]],"u":"https://bitcointalk.org/index.php?topic=16.msg73#msg73","s":1,"n":25,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/25/"}]},{"id":"p11","k":"p","s":"bitcointalk","t":"Is my second Transaction working correctly? +Transfer Question","u":"https://bitcointalk.org/index.php?topic=17","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/11/","m":[{"f":"AgoraMutual","d":1262369398,"b":[["t","So, I finally got my client to start generating and after I got my laptop optimized for the task and waited over night. My first transaction completed resulting in +50 Coins. Yay!!\n\nHowever, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?\n\nI have a Screen Shot if needed. Sorry if this is a basic question but I'm sure someone will ask if I don't.\n\nThanks for taking the initiative on this project Mr. Satoshi.  Grin Maybe one day I can fire my bank once and for all.\n\nEDIT: I decided to stop playing around and I set BitCoin up on my high powered gaming rig, forwarded 8333 to it, and started generating on it instead of my laptop. So then I transferred my previous 50 coins to that client but it's been an hour and nothing has shown up for me to accept the transfer. Both computers are on the same wireless LAN. I sent it to just the BitCoin address because I wasn't sure if I was supposed to send to my internal or external IP. I assume external because the transaction needs to be verified by other nodes. Right? I also assumed sending to the BC address only would make sure it goes through the proper channels. Did I just throw my coins away or should I wait longer? I'm new at this. Sorry."]],"u":"https://bitcointalk.org/index.php?topic=17.msg83#msg83"},{"f":"sirius","d":1262654406,"b":[["q","So, I finally got my client to start generating and after I got my laptop optimized for the task and waited over night. My first transaction completed resulting in +50 Coins. Yay!!","Quote from: Agora on January 01, 2010, 06:09:58 PM"],["t","Congratulations and welcome to the forum  Cool"],["q","However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?","Quote"],["t","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."],["q","EDIT: I decided to stop playing around and I set BitCoin up on my high powered gaming rig, forwarded 8333 to it, and started generating on it instead of my laptop. So then I transferred my previous 50 coins to that client but it's been an hour and nothing has shown up for me to accept the transfer.","Quote"],["t","There's no confirmation of incoming transactions when someone sends to your Bitcoin address, all transactions are automatically completed. Did the transaction show up in the transaction list?"],["q","Both computers are on the same wireless LAN. I sent it to just the BitCoin address because I wasn't sure if I was supposed to send to my internal or external IP. I assume external because the transaction needs to be verified by other nodes. Right?","Quote"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=17.msg84#msg84"},{"f":"satoshi","d":1262721646,"b":[["t","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.  \n\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\"."],["q","> Quote\n> However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under \"Status\". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?\n\nThe 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.","Quote from: sirius-m on January 05, 2010, 01:20:06 AM"],["t","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\n\nEach block essentially means another node has confirmed that it agrees with all transactions up to that point."]],"u":"https://bitcointalk.org/index.php?topic=17.msg85#msg85","s":1,"n":28,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/28/"}]},{"id":"p12","k":"p","s":"bitcointalk","t":"64bit support","u":"https://bitcointalk.org/index.php?topic=18","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/12/","m":[{"f":"The Madhatter","d":1263226400,"b":[["t","Can bitcoin be compiled to run on 64 bit systems yet? -m64 seems to break the compile.\n\n(Not trying to nag or anything).\n\nOn a side node: I have noticed that the network is about 3x larger than normal now. I see more nodes! Smiley"]],"u":"https://bitcointalk.org/index.php?topic=18.msg87#msg87"},{"f":"satoshi","d":1263500240,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=18.msg97#msg97","s":1,"n":29,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/29/"},{"f":"The Madhatter","d":1263683816,"b":[["t","All modern computers are amd64/EM64T. It should be able to be compiled on either platform. It is a hassle to compile all of the dependancies in 32-bit mode just to run one program. I know the 32-bit/64-bit stuff is seamless on windows platforms but on *NIX platforms it is a major pain since they are usually either one or the other by default. Wink\n\nAs a workaround I am in the process of compiling FreeBSD 32-bit jails (aka virtual server images) just for running bitcoin on our network. It should make it easier for me to deploy more nodes as they can simply be zipped up / scp'd / extracted / launched. After I have a working system image based on FreeBSD-8.0 I may post a link for download.\n\nThanks and keep up the good work. I can't wait to see how many exchangers are willing to trade BT. The stability of the exchangers and their longevity is everything. If the exchangers stick around big businesses may use this system to get around service fees / chargebacks / and the general faults caused by the credit card industry.\n\nKeep up the great work! Smiley"]],"u":"https://bitcointalk.org/index.php?topic=18.msg103#msg103"},{"f":"Sabunir","d":1264396403,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=18.msg127#msg127"},{"f":"satoshi","d":1264725769,"b":[["t","I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0.\n\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.\n\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.\n\nI compiled and ran on 64-bit Ubuntu 9.10 Karmic.\n\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.\n\nbuild-unix.txt is updated and two makefiles on SVN:\nmakefile.unix.wx2.8\nmakefile.unix.wx2.9\n\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."]],"u":"https://bitcointalk.org/index.php?topic=18.msg174#msg174","s":1,"n":38,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/38/"}]},{"id":"p13","k":"p","s":"bitcointalk","t":"Number of connections?","u":"https://bitcointalk.org/index.php?topic=21","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/13/","m":[{"f":"RogerRabbit","d":1263652035,"b":[["t","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?\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=21.msg102#msg102"},{"f":"satoshi","d":1264018035,"b":[["t","Coins generate at the same speed with any number of connections >= 1.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=21.msg112#msg112","s":1,"n":30,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/30/"}]},{"id":"p14","k":"p","s":"bitcointalk","t":"TOR and I2P","u":"https://bitcointalk.org/index.php?topic=22","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/14/","m":[{"f":"The Madhatter","d":1263684175,"b":[["t","Hello,\n\nI have had another idea. Tongue\n\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).\n\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.\n\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. Cheesy\n\nCheers!"]],"u":"https://bitcointalk.org/index.php?topic=22.msg104#msg104"},{"f":"satoshi","d":1264025128,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=22.msg113#msg113","s":1,"n":31,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/31/"},{"f":"The Madhatter","d":1264366379,"b":[["t","Yeah, I2P is much easier to automate in that regard. I could setup some .onions manually and post them to the list to be used as seeds. I have always-on nodes that can just be tied to Tor with minimal effort.\n\nI used to be a big advocate of Tor, but after I started using I2P I found it to be much, much better in a lot of ways. Biggest improvement is speed. Wink  Too bad they wrote it in Java."],["q","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.\n\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.","Quote from: satoshi on January 20, 2010, 10:05:28 PM"]],"u":"https://bitcointalk.org/index.php?topic=22.msg120#msg120"},{"f":"BitcoinFX","d":1265060207,"b":[["t","I also run a Tor relay and exit node and had similar ideas for Tor integration with Bitcoin.\n\nTor can be very fast if you edit your config correctly. You just need to limit the connectivity with slow servers and only use the fastest nodes where possible. I also like to block any nodes in 'problem' internet countries, which also tend to have slower connectivity, this also increases overall privacy somewhat. I also block Unnamed, ididnteditheconfig, any servers that I don't like the name of and unstable servers.\n\nThis config. example is only good for non-relay / non-exit personal use. Although its great for P2P Smiley\n\nAvoidDiskWrites 1\n\nExcludeNodes SlowServer,{sd},{pk},{tn},{ae},{by},{in},{bh},{th},{ye},{mm},{eg},{sg},{ma},{cu},{qa},{sa},{by},{md},{tm},{tr},{et},{jo},{sy},{om},{ir},{az},{uz},{kz},{kg},{af},{cn},{bd},{vn},{ng},{gh},{ro},{lb},{ru},{iq},{ly},{ve},{zw},{my},{mo},{kr},unnamed,ididnteditheconfig ...etc.\n\nStrictEntryNodes 1\n\nEntryNodes (Select Fast Entry and Authority Servers from http://trunk.torstatus.kgprog.com/index.php?Fast=0 )\n\nStrictExitNodes 1\n\nExitNodes (Select Fast Exit Only from http://trunk.torstatus.kgprog.com/index.php?Fast=0 )\n\nIt's also a good idea to alter the time which Tor takes to automatically switch circuits and some other custom settings https://www.torproject.org/tor-manual.html\n\nHope this helps Wink"]],"u":"https://bitcointalk.org/index.php?topic=22.msg191#msg191"},{"f":"BitcoinFX","d":1265062134,"b":[["t","OK So, I tried to set-up a sudo-anonymous crypto 'Bitcoin Bank' experiment using Tor. Grin\n\nWhilst it was mostly successful using the standard 9050 socks port 'default setup' i.e. I got connectivity to other Bitcoin nodes through Tor; I did encounter various issues and multiple Warning messages.\n\n\"Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider\nusing Socks4A (e.g. via polipo or socat) instead.\"\n\nhttps://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#IkeepseeingthesewarningsaboutSOCKSandDNSandinformationleaks.ShouldIworry.3F\n\nI eventually fixed this using Privoxy and Stunnel (because i'm more familiar with those) However, you could use polipo and Stunnel.\n\nHowever, I still get occasional warnings for these ports 8333 (expected Bitcoin 'default') and 6667 (which if i'm not mistaken is an IRC port !?)\n\nConnecting Bitcoin through Tor also makes Tor repeatedly change exit nodes looking to establish 'missing' connections to a [scrubbed] address. At first I assumed that this was because Tor exits might be blocking port 8333 or 6667, but that is mostly not the case !\n\nOther P2P applications through Tor can 'ignore' IP addresses that they cannot connect to and the application can still get the job done without 'warning'. However, Bitcoin must try to connect with all nodes to check its not missing any blocks ! So, if an IP range where only 1 Bitcoin node is running is blocking Tor exit nodes, then presumably this will always be the case ?\n\nThis is problematic for many reasons. Huh"]],"u":"https://bitcointalk.org/index.php?topic=22.msg192#msg192"},{"f":"riX","d":1265150216,"b":[["q","\"Your application (using socks5 on port xxxx) is giving Tor only an IP address. Applications that do DNS resolves themselves may leak information. Consider\nusing Socks4A (e.g. via polipo or socat) instead.\"","Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM"],["t","Bitcoin is using ip-adresses, not hostnames, so there's no need for dns. Tor thinks that since bitcoin is trying to connect to an ip without looking it up through tors internal dns, it's using a regular dns."],["q","However, I still get occasional warnings for these ports 8333 (expected Bitcoin 'default') and 6667 (which if i'm not mistaken is an IRC port !?)","Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM"],["t","Bitcoin is using port 8333, even though it's relaying it through tor on port 9050..  Tongue\n6667 is irc, bitcoin uses an irc-server to distribute the nodelist. (If you know the ip of another computer running bitcoin, you can specify the -connect option to avoid using the nodelist)."],["q","However, Bitcoin must try to connect with all nodes to check its not missing any blocks !","Quote from: BitcoinFX on February 01, 2010, 10:08:54 PM"],["t","No, it's enough if you're just connected to one single node, as long as it's got a copy of the longest block-chain."]],"u":"https://bitcointalk.org/index.php?topic=22.msg205#msg205"},{"f":"BitcoinFX","d":1265211093,"b":[["t","OK thanks riX.\n\nSo, once Bitcoin has connected to at least one node then the -connect option will eliminate the 6667 warnings.\n\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 Wink ) 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.\n\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\n\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. Grin"]],"u":"https://bitcointalk.org/index.php?topic=22.msg207#msg207"},{"f":"satoshi","d":1265243450,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=22.msg223#msg223","s":1,"n":42,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/42/"}]},{"id":"p15","k":"p","s":"bitcointalk","t":"A newb's test - anyone want to buy a picture for $1?","u":"https://bitcointalk.org/index.php?topic=25","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/15/","m":[{"f":"Sabunir","d":1264326768,"b":[["t","Hello all. I've decided to give Bitcoin a try. As a test, I want to see if I can make $1 USD from selling a picture. According to this <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>, 500 Bitcoins should roughly be a dollar (after PayPal fees), right? If I understand this correctly, I should be told the Bitcoin Address of anyone who Sends me Bitcoins, right? And you have the ability to attach messages to the Send? If so, then I guess I could Send 0 Bitcoins in return, with a message containing a download link for the full image. Is this how things are supposed to work, or am I mistaken? To get the picture, please send the coins to me and then send a Private Message stating the time you sent them. I will reply to your Private Message with a link to the picture.\n\nThe image I'm selling is my own creation, with a resolution of 1280x960 - great for a desktop background. Here's a low-quality preview:\n\nAnyway, it's been a pleasure to meet you all. My Address is 1BHtsCnpmTvpgJEP7eMKEVhpJFunxSM8vq. If this generates any interest, I could offer some more of my pictures... "]],"u":"https://bitcointalk.org/index.php?topic=25.msg118#msg118"},{"f":"The Madhatter","d":1264366416,"b":[["t","Hmm.. I am not sure if you can send a 0-coin payment. Can anyone confirm this?"]],"u":"https://bitcointalk.org/index.php?topic=25.msg121#msg121"},{"f":"RogerRabbit","d":1264387333,"b":[["t","Simple solution to that. If it's for sale for 500 coins, just have them send 501 and send 1 back Smiley"]],"u":"https://bitcointalk.org/index.php?topic=25.msg124#msg124"},{"f":"Sabunir","d":1264389061,"b":[["t","I assume you tested it, then, and it didn't work? Very well. Hm, what about decimals? I notice that my balance is 0.00. Could I send 0.01 coins?"]],"u":"https://bitcointalk.org/index.php?topic=25.msg125#msg125"},{"f":"RogerRabbit","d":1264392363,"b":[["t","I, have not tested it. Just giving ideas. Besides, 1 coin, according to Liberty Standard's exchange, is less than a penny. I wouldn't get hung up on decimals."]],"u":"https://bitcointalk.org/index.php?topic=25.msg126#msg126"},{"f":"sirius","d":1264405202,"b":[["q","Hello all. I've decided to give Bitcoin a try. As a test, I want to see if I can make $1 USD from selling a picture. According to this <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>, 500 Bitcoins should roughly be a dollar (after PayPal fees), right? If I understand this correctly, I should be told the Bitcoin Address of anyone who Sends me Bitcoins, right? And you have the ability to attach messages to the Send? If so, then I guess I could Send 0 Bitcoins in return, with a message containing a download link for the full image. Is this how things are supposed to work, or am I mistaken?","Quote from: Sabunir on January 24, 2010, 09:52:48 AM"],["t","Unfortunately you can't attach a message when you send to a Bitcoin address. It's possible only when sending to an IP. Sending 0 coins is also not possible.\n\nIf you want to track payments, you can give a new Bitcoin address to each customer. How to make a new address: Options -> Change your address. We could perhaps make this easier by adding next to \"Send Coins\" a button \"Receive Coins\", which would create you the new address and ask for its label."]],"u":"https://bitcointalk.org/index.php?topic=25.msg129#msg129"},{"f":"RogerRabbit","d":1264437050,"b":[["t","You can't send messages to Bitcoin users unless it's the IP? That seems unnecessary. Any reasoning behind this? I think people will use Bitcoin addresses a lot more often than the IP address when sending or receiving coins. "]],"u":"https://bitcointalk.org/index.php?topic=25.msg130#msg130"},{"f":"Sabunir","d":1264440970,"b":[["t","No messages that way? That seems less than ideal. Very well, what would be a more correct way to do this?\n\nFor now, if anyone sends 500 coins and tells me in Private Message the time they sent it, I shall respond with a link to the picture."]],"u":"https://bitcointalk.org/index.php?topic=25.msg131#msg131"},{"f":"sirius","d":1264447529,"b":[["q","You can't send messages to Bitcoin users unless it's the IP? That seems unnecessary. Any reasoning behind this? I think people will use Bitcoin addresses a lot more often than the IP address when sending or receiving coins.","Quote from: RogerRabbit on January 25, 2010, 04:30:50 PM"],["t","I think it was some technical limitation. Satoshi could tell more about this?"]],"u":"https://bitcointalk.org/index.php?topic=25.msg132#msg132"},{"f":"satoshi","d":1264640508,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=25.msg159#msg159","s":1,"n":33,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/33/","qt":["I 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."],"qc":["bitcoin-design"]},{"f":"Sabunir","d":1264655584,"b":[["t","Yes, encryption of messages would be a very good thing... So the problem is not that you can't store the message on the network, but rather, that you do not yet have a good way of encrypting it?"]],"u":"https://bitcointalk.org/index.php?topic=25.msg162#msg162"},{"f":"NewLibertyStandard","d":1264672697,"b":[["t","I certainly wouldn't mind a larger Bitcoin application if it meant we could send an encrypted message along with each transaction. Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins. About how many MB do you think it would add? Of course these messages will add to the size of the confirmation blocks being stored, so there should probably be a maximum size. Perhaps 256 characters would be a good maximum since the maximum size of an email address is 254 characters <http://www.dominicsayers.com/isemail/>.\n\nIt would also be nice if transactions included a return address so that if a product or service being purchased can't be delivered the seller could more easily and reliably refund the bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=25.msg164#msg164","sj":"Encrypted Message is Worth the Extra Size"},{"f":"The Madhatter","d":1264674261,"b":[["t","A balance between extended transaction data while NOT becoming an instant messenger client would be nice. Tongue"]],"u":"https://bitcointalk.org/index.php?topic=25.msg166#msg166"},{"f":"riX","d":1264684057,"b":[["q","Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins.","Quote from: NewLibertyStandard on January 28, 2010, 09:58:17 AM"],["t","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.\n\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).  Tongue\n\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."]],"u":"https://bitcointalk.org/index.php?topic=25.msg168#msg168","sj":"Re: Encrypted Message is Worth the Extra Size"},{"f":"satoshi","d":1264724533,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=25.msg173#msg173","s":1,"n":37,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/37/"}]},{"id":"p16","k":"p","s":"bitcointalk","t":"Bitcoin crash when sending coins","u":"https://bitcointalk.org/index.php?topic=27","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/16/","m":[{"f":"riX","d":1264460836,"b":[["t","Lately when I've been trying to send coins, the following popups twice, then the application terminates."],["c","EXCEPTION: St13runtime_error\nSendMoney() : wtxNew.AcceptTransaction() failed\n\nc:\\Documents and Settings\\username\\bitcoin-0.2.0\\bitcoin.exe in\nCMyApp::OnExceptionInMainLoop()"],["t","When i restart bitcoin.exe, the transaction is showing as 0/unconfirmed. The status do not change even when the total block count increases.\n\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).\n\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.\n\nI've been moving wallets and index-files back and forth, could this have something to do with this?"]],"u":"https://bitcointalk.org/index.php?topic=27.msg135#msg135"},{"f":"satoshi","d":1264629147,"b":[["t","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.\n\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.\"\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=27.msg156#msg156","s":1,"n":32,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/32/"},{"f":"riX","d":1264630460,"b":[["t","Yes, I thought it had something to do with that.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=27.msg157#msg157"},{"f":"satoshi","d":1264720082,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=27.msg170#msg170","s":1,"n":35,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/35/"},{"f":"satoshi","d":1265239797,"b":[["t","I uploaded this fix to the SVN.  It watches for spent coins and updates your wallet on load and also continuously as blocks come in.  I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.\n\nIf you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit)."]],"u":"https://bitcointalk.org/index.php?topic=27.msg219#msg219","s":1,"n":39,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/39/"}]},{"id":"p17","k":"p","s":"bitcointalk","t":"Blocks never stop generating?","u":"https://bitcointalk.org/index.php?topic=28","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/17/","m":[{"f":"Sabunir","d":1264474121,"b":[["t","Hello. My understanding of Bitcoin is not perfect, so I would like to ask questions about its operation. When Generating, the user will gain 50 coins after creating 120 blocks. Why does the program continue generating blocks after that point? And why does one not gain another 50 coins after generating 240 blocks?\n\nAlso, I sent a few coins to someone to test the transaction system. Even though it was just a few coins, that transaction's status currently reads \"166 blocks\". It seems that it will continue incrementing indefinitely. Why is this?\n\nI thank responders for increasing my knowledge."]],"u":"https://bitcointalk.org/index.php?topic=28.msg137#msg137"},{"f":"sirius","d":1264481024,"b":[["t","The user gets 50 coins when he has created 1 block. The coins can be used (they \"mature\") when 120 blocks have been generated by the whole network after he created the block. The number of blocks of a transaction means the number of new blocks in the whole block chain after the transaction. The whole block chain grows ad infinitum."]],"u":"https://bitcointalk.org/index.php?topic=28.msg139#msg139"},{"f":"Sabunir","d":1264529783,"b":[["t","So that transaction will eventually read \"1000 blocks\" or more? Is this information important?"]],"u":"https://bitcointalk.org/index.php?topic=28.msg141#msg141"},{"f":"riX","d":1264546307,"b":[["t","Yes it will.\n\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)."]],"u":"https://bitcointalk.org/index.php?topic=28.msg142#msg142"},{"f":"satoshi","d":1264640913,"b":[["t","Where it says \"# blocks\" in the status column I'm changing it to say \"# confirmations\".  That might be clearer.\n\nIf you doubleclick on the transaction you get a little more information."]],"u":"https://bitcointalk.org/index.php?topic=28.msg160#msg160","s":1,"n":34,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/34/"}]},{"id":"p18","k":"p","s":"bitcointalk","t":"Payment server","u":"https://bitcointalk.org/index.php?topic=29","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/18/","m":[{"f":"giik","d":1264578662,"b":[["t","As I have read in some topics (https://www.bitcoin.org/smf/index.php?topic=12.0, https://www.bitcoin.org/smf/index.php?topic=19.0), a payment server is needed for a broader acceptance of Bitcoins.\n\nI want to create a php webapplication which can process Bitcoins transactions. I have a LAMP system up and running, but until now I used bitcoins on Windows only. Can anyone help me to create a linux installation of Bitcoins with a command line interface?\n\nServer runs Ubuntu 9.10 32-bit. Or should I use a different distribution?\n\nMy idea is simple:\n\n- visitor wants to buy something;\n- payment page shows him the amount of Bitcoins he has to pay, including an orderid and a ip-address of the server (because messages can only be sent through ipaddress-transactions);\n- visitor makes a payment with his Bitcoin application and places the orderid in the message of the payment;\n- server receives payment and checks orderid and amount;\n- payment is received, visitor is sent a downloadlink/confirmation of purchase/etc.\n\nThink this is possible with Bitcoin 0.2?"]],"u":"https://bitcointalk.org/index.php?topic=29.msg143#msg143"},{"f":"riX","d":1264586686,"b":[["t","Instead of an ip-address, an unique bitcoin address should be created, and is also way less vulnerable. This is all that is needed for the server to keep track of incoming bitcoins.\n\nYou will have to do some programming to get command-line access to the needed functions.\n\nI bet you could get someone to do it for you for some bitcoins  Grin"]],"u":"https://bitcointalk.org/index.php?topic=29.msg147#msg147"},{"f":"giik","d":1264589084,"b":[["q","Instead of an ip-address, an unique bitcoin address should be created, and is also way less vulnerable. This is all that is needed for the server to keep track of incoming bitcoins.","Quote from: riX on January 27, 2010, 10:04:46 AM"],["t","Sirius-m said (https://www.bitcoin.org/smf/index.php?topic=25.msg129#msg129):"],["q","Unfortunately you can't attach a message when you send to a Bitcoin address. It's possible only when sending to an IP.","Quote"],["t","And:"],["q","I think it was some technical limitation. Satoshi could tell more about this?","Quote"],["t","Is it possible in Bitcoin 0.2 to attach messages when using a bitcoin address?"]],"u":"https://bitcointalk.org/index.php?topic=29.msg148#msg148"},{"f":"riX","d":1264592031,"b":[["t","No, you can't send a message when sending to an ip, but that's what the _unique_ bitcoin address is for.\n\nWhen the customer places an order, the server creates a new bitcoin address to be used for that order only. (This can be seen as the orderId if you want).\nWhen the customer makes a payment to that bitcoin address/orderId, the server will know who it's from.\nThere's no need for a message."]],"u":"https://bitcointalk.org/index.php?topic=29.msg149#msg149"},{"f":"giik","d":1264593377,"b":[["t","This means that a server can process one payment at a time. Unless a server is capable of having more than one bitcoin address."]],"u":"https://bitcointalk.org/index.php?topic=29.msg150#msg150"},{"f":"riX","d":1264596547,"b":[["t","Wallets already support multiple bitcoin addresses.\n\nYou should check out \"Options/Change your address\" in your bitcoin app Grin"]],"u":"https://bitcointalk.org/index.php?topic=29.msg151#msg151"},{"f":"giik","d":1264598597,"b":[["q","Wallets already support multiple bitcoin addresses.\n\nYou should check out \"Options/Change your address\" in your bitcoin app Grin","Quote from: riX on January 27, 2010, 12:49:07 PM"],["t","riX, you are absolutely right! Embarrassed\n\nNow all I need is a command line version of Bitcoin."],["q","Command line is on the to-do list after 0.2.","Quote from: satoshi on November 27, 2009, 05:27:09 PM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=29.msg152#msg152"},{"f":"satoshi","d":1264721169,"b":[["t","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.\n\nAdding command line support is a high priority.  It's just a matter of getting the time to code it."]],"u":"https://bitcointalk.org/index.php?topic=29.msg172#msg172","s":1,"n":36,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/36/"}]},{"id":"p19","k":"p","s":"bitcointalk","t":"We accept Bitcoins [moved to bitcoin.it/wiki/Trade]","u":"https://bitcointalk.org/index.php?topic=30","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/19/","m":[{"f":"giik","d":1264583416,"b":[["t","To promote the use of Bitcoins in commerce, I've started this topic. Now anyone can post sites where Bitcoins are accepted Cheesy\n\nedit by sirius-m: Traders' list has been moved to the wiki <https://bitcoin.it/wiki/Trade>."]],"u":"https://bitcointalk.org/index.php?topic=30.msg144#msg144"},{"f":"giik","d":1264583519,"b":[["t","http://www.teslamap.com/"],["q","I also accept BitCoins as payment. Please contact me if you would like to pay in BitCoins.\nLink: http://www.teslamap.com/download.html","Quote"],["t","This site removed the possibility to pay with Bitcoins. Too bad.  Cry"]],"u":"https://bitcointalk.org/index.php?topic=30.msg145#msg145","sj":"Re: We accept Bitcoins"},{"f":"giik","d":1264583682,"b":[["t","http://newlibertystandard.wetpaint.com/\n\nThe mother of all Bitcoin-accepting websites Wink"]],"u":"https://bitcointalk.org/index.php?topic=30.msg146#msg146","sj":"Re: We accept Bitcoins"},{"f":"sirius","d":1264641386,"b":[["t","Good idea, made sticky  Cool"]],"u":"https://bitcointalk.org/index.php?topic=30.msg161#msg161","sj":"Re: We accept Bitcoins"},{"f":"sirius","d":1265020506,"b":[["t","http://www.livingsoulnation.org/ \"LivingSoulNation.org is now using Bitcoin as its currency. Use it to trade with us or use it to donate Bitcoin(s).\"\n\nNot sure what they trade, though Tongue"]],"u":"https://bitcointalk.org/index.php?topic=30.msg186#msg186","sj":"Re: We accept Bitcoins"},{"f":"BitcoinFX","d":1265063171,"b":[["t","I'm starting to offer Bitcoin eCurrency exchange services through my new website http://www.bitcoinfx.cz.cc/\n\nI'm also looking into offering Bitcoin users a web based Forex API to day trade the BTCUSD currency pair in the future. However, I first need to generate enough Bitcoins to act as the broker Cool"]],"u":"https://bitcointalk.org/index.php?topic=30.msg194#msg194","sj":"Re: We accept Bitcoins"},{"f":"sirius","d":1265079504,"b":[["t","http://btc2psc.bt.funpic.org/ Sell your Bitcoins for 10€ Paysafecard codes."]],"u":"https://bitcointalk.org/index.php?topic=30.msg201#msg201","sj":"Re: We accept Bitcoins"},{"f":"livingsoulnation","d":1265350994,"b":[["q","http://www.livingsoulnation.org/ \"LivingSoulNation.org is now using Bitcoin as its currency. Use it to trade with us or use it to donate Bitcoin(s).\"\n\nNot sure what they trade, though Tongue","Quote from: sirius-m on February 01, 2010, 10:35:06 AM"],["t","We are selling 'indulgences' just like the Roman Catholic Church used to. Just kidding.\n\nUtilizing someone's exchange service would be nice. We are accepting donations to start, and if someone wanted us to link back to their site (links or banners), or promote their exchange we would certainly do that for some BitCoins. We are associated with PNNAC.ORG, a private freedom-based society that may also be interested in the same things. Their contact info is on the site.\n\nLet's start some dialogue and see where it takes us. I'll check out the existing exchanges and if they look reasonable I'll contact them."]],"u":"https://bitcointalk.org/index.php?topic=30.msg241#msg241","sj":"Re: We accept Bitcoins"},{"f":"BlueSky","d":1265450189,"b":[["t","This will be what makes bitcoin successful, being able to exchange it for goods & services(not just an exchange service).\n\nVirtual currency (nothing like bitcoin) can become successfull in being accepted for real goods & services, it just takes a little time. Qcoin was popular here in China but is being put down by the Chinese central bank.\n\nSee here http://en.wikipedia.org/wiki/Tencent_QQ#Q_coin and here\nhttp://online.wsj.com/public/article/SB117519670114653518-FR_svDHxRtxkvNmGwwpouq_hl2g_20080329.html\n\nWell I'm in China, for things like getting documents translated to Chinese and maybe some goods (starting with cheaper items) I can post. I also have access to plenty of poor students who I might be able to convince to contribute their time (for programming, website design, logo design etc.) for bitcoins.\n\nI myself am an English teacher so I haven't much to offer as a remote service."]],"u":"https://bitcointalk.org/index.php?topic=30.msg253#msg253","sj":"Re: We accept Bitcoins"},{"f":"NewLibertyStandard","d":1265757964,"b":[["t","Welcome to the Liberty Swap Specialty Shop! <http://newlibertystandard.wetpaint.com/page/Specialty+Shop>\nWe Ship Internationally!"]],"u":"https://bitcointalk.org/index.php?topic=30.msg305#msg305","sj":"Re: We accept Bitcoins"},{"f":"SmokeTooMuch","d":1265760901,"b":[["t","Hi, one thing just came to my mind and I want to share the idea with you guys.\n\nIs there any free/cheap software or CMS for building an online auction house like ebay ?\n\nI really like the idea of eBay with BTC Smiley\n\nEDIT: ok, found some stuff here http://www.hotscripts.com/category/php/scripts-programs/auctions/, maybe i will set something up, hmm ..."]],"u":"https://bitcointalk.org/index.php?topic=30.msg307#msg307","sj":"Re: We accept Bitcoins"},{"f":"ec","d":1266270618,"b":[["t","I have started an experimental service for anonymous storage using encfs, sshfs and TOR:\n\nhttp://isj6esrpkl5kgi5r.onion/\n\nPlease let me know what you think  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=30.msg357#msg357","sj":"Re: We accept Bitcoins"},{"f":"SmokeTooMuch","d":1266277335,"b":[["t","you should state some info about your service on the page.\ncouldn't find anything about up/download speeds or traffic limits."]],"u":"https://bitcointalk.org/index.php?topic=30.msg358#msg358","sj":"Re: We accept Bitcoins"},{"f":"ec","d":1266313131,"b":[["q","you should state some info about your service on the page.\ncouldn't find anything about up/download speeds or traffic limits.","Quote from: SmokeTooMuch on February 15, 2010, 11:42:15 PM"],["t","Thank you for your interest! My server sits on a 100MBit network, but I guess the bandwidth is somewhat limited by TOR, so it's \"unlimited\". Actually, the 1GB \"limit\" isn't enforced for this reason either Smiley\n\nWhile I will do my best to keep my server on line, I of course don't expect anyone to trust me, and I therefore suggest that other people set up similar services and let people have multiple backups at different places (maybe combined with unionfs-fuse or similar).\n\nI of course can't compete with dropbox etc, but this should be an excellent place to back up sensitive (your encrypted bitcoin wallet?) data limited in size."]],"u":"https://bitcointalk.org/index.php?topic=30.msg373#msg373","sj":"Re: We accept Bitcoins"},{"f":"ihrhase","d":1266941091,"b":[["q","To promote the use of Bitcoins in commerce, I've started this topic. Now anyone can post sites where Bitcoins are accepted Cheesy","Quote from: giik on January 27, 2010, 09:10:16 AM"],["t","I am interested in real goods exchange for BITCOIN\n\nI am looking for Corn, Malt (Hopped or not), Malted wheat, barley and rye\n\nI am going to \"mix my labor\" with these resources to generate a product that I will accept bitcoins in exchange for...\n\nI know the e-trade aspect is the easy link to increase the usage and therefore value of this exchange product, but without a real product exchange, you will be hard pressed to gain the widespread usage for stable value and common usage..."]],"u":"https://bitcointalk.org/index.php?topic=30.msg441#msg441","sj":"Re: We accept Bitcoins"},{"f":"DannyM","d":1267303689,"b":[["t","I will send you physical comic books for your bitcoins. I'll try to work out a more formal system in the future, but for now you can pm me your interests or contact details and I'll let you know what I have that might fit and we can make a deal."]],"u":"https://bitcointalk.org/index.php?topic=30.msg570#msg570","sj":"Re: We accept Bitcoins"},{"f":"seq2010","d":1267325560,"b":[["t","I would like to offer my services in exchange for Bitcoins. I am a master certified mechanic, and can offer a help desk style phone in service for anyone stuck trying to fix their car and needs some help.\n\nPM me if your interested.\n\nsteve-"]],"u":"https://bitcointalk.org/index.php?topic=30.msg573#msg573","sj":"Re: We accept Bitcoins"},{"f":"riX","d":1267551740,"b":[["t","I have 244 Travian Gold that I am willing to trade for bitcoins. They are transferable to *.se servers only.\n\nI will edit this post if I trade them."]],"u":"https://bitcointalk.org/index.php?topic=30.msg605#msg605","sj":"Re: We accept Bitcoins"},{"f":"SheriffWoody","d":1267756747,"b":[["t","I am planning on getting a dedicated website for this, maybe a tor hidden service, but anyway.\n\nI am a university student and I highly believe in free education, so I will be gradually uploading the notes from all of my classes so that the general public can become more educated. This is just the beginning of my notes, and as I am a psychology major, the next upload sprees will be specializing more in psychology with the higher level courses.\n\nI am not going to charge anything, however, bitcoin donations would be appreciated.\n\nIf you wanted to donate to me, here is my address: 1JfyQHPFQoMnyWUmUeLzm6zbi1Rc3hGrKY\n\nPsychology101: http://rapidshare.com/files/359091364/Psyc_101.zip.html\n\nFamily: http://rapidshare.com/files/359091228/Family.zip\n\nChinese Culture: http://rapidshare.com/files/359094826/Chinese_Culture.zip"]],"u":"https://bitcointalk.org/index.php?topic=30.msg636#msg636","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1268778334,"b":[["t","Link2VoIP (www.link2voip.com <http://www.link2voip.com>) accepts Bitcoin as payment.\n\nNow you can get phone service for Bitcoins.\n\nHow's that for useful? Tongue"]],"u":"https://bitcointalk.org/index.php?topic=30.msg733#msg733","sj":"Re: We accept Bitcoins"},{"f":"ihrhase","d":1268827620,"b":[["q","Link2VoIP (www.link2voip.com <http://www.link2voip.com>) accepts Bitcoin as payment.\n\nNow you can get phone service for Bitcoins.\n\nHow's that for useful? Tongue","Quote from: madhatter2 on March 16, 2010, 10:25:34 PM"],["t","It would be infinitely more so If I could find the BTC Rate...."]],"u":"https://bitcointalk.org/index.php?topic=30.msg736#msg736","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1268831574,"b":[["t","I emailed support and asked them. (I've been a customer for 4 years. I was also the one who suggested that they accept BCs.)\n\nThey told me that they are matching New Liberty Standard's BC/USD rate for the time being.\n\nI sent them a payment today and I received a credit. Looks like it works. Wink"]],"u":"https://bitcointalk.org/index.php?topic=30.msg740#msg740","sj":"Re: We accept Bitcoins"},{"f":"ihrhase","d":1268837475,"b":[["t","So their unlimited service is $9.99 a mo (correct?)\n\nThat would equate to:\n\n$9.99 * 146.22 BTC/$\n\n1458.54 BTC/mo.\n\nUnless there are people local to me that wish to purchase my consumer goods for BTC the marginal use of BTC does not exceed $ for me yet...."]],"u":"https://bitcointalk.org/index.php?topic=30.msg741#msg741","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1268839984,"b":[["t","I pay $9.99 for a local phone number. Been a customer for 4 years. It works great.\n\nI also use them to connect my mobile calls. (Mobile calls here are seriously an arm+leg with our local provider.)\n\nOh, and I also resell some of their stuff to friends to make a few extra bucks."]],"u":"https://bitcointalk.org/index.php?topic=30.msg744#msg744","sj":"Re: We accept Bitcoins"},{"f":"DannyM","d":1268841667,"b":[["q","Unless there are people local to me that wish to purchase my consumer goods for BTC the marginal use of BTC does not exceed $ for me yet....","Quote from: ihrhase on March 17, 2010, 02:51:15 PM"],["t","I know I'm probably not local, but what are the consumer goods you are selling?"]],"u":"https://bitcointalk.org/index.php?topic=30.msg746#msg746","sj":"Re: We accept Bitcoins"},{"f":"SmokeTooMuch","d":1269828877,"b":[["t","Hehe, that was my idea you thief Tongue\nBut there was a lack of customers, so I closed my service.\n\nGood luck with that Smiley"]],"u":"https://bitcointalk.org/index.php?topic=30.msg823#msg823","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1269834238,"b":[["t","You'll get customers eventually. Stay patient! Smiley"]],"u":"https://bitcointalk.org/index.php?topic=30.msg824#msg824","sj":"Re: We accept Bitcoins"},{"f":"Link2VoIP","d":1270753826,"b":[["t","Actually, we just polished up our Bitcoin integration. Payments into our system are fully automated now."],["q","Link2VoIP (www.link2voip.com <http://www.link2voip.com>) accepts Bitcoin as payment.\n\nNow you can get phone service for Bitcoins.\n\nHow's that for useful? Tongue","Quote from: madhatter2 on March 16, 2010, 10:25:34 PM"]],"u":"https://bitcointalk.org/index.php?topic=30.msg874#msg874","sj":"Re: We accept Bitcoins"},{"f":"bitcoinuser","d":1270782272,"b":[["q","Link2VoIP (www.link2voip.com <http://www.link2voip.com>) accepts Bitcoin as payment.\n\nNow you can get phone service for Bitcoins.\n\nHow's that for useful? Tongue","Quote from: madhatter2 on March 16, 2010, 10:25:34 PM"],["t","that rocks madhatter. i love link2voip. progressive!"]],"u":"https://bitcointalk.org/index.php?topic=30.msg883#msg883","sj":"Re: We accept Bitcoins"},{"f":"pnnac","d":1271194682,"b":[["t","Our Society (The Canadian Free Man On The Land Society - www.pnnac.org <http://www.pnnac.org>) accepts Bitcoins as a donation. We use the funds to pay for our monthly VPS hosting bill with Link2VoIP.com."]],"u":"https://bitcointalk.org/index.php?topic=30.msg903#msg903","sj":"Re: We accept Bitcoins"},{"f":"Link2VoIP","d":1271203024,"b":[["t","What a small world. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=30.msg904#msg904","sj":"Re: We accept Bitcoins"},{"f":"BitcoinFX","d":1271320365,"b":[["t","I have recently revised my Liberty Reserve Exchange Service website - BitcoinFX - http://www.bitcoinfx.cz.cc/ I will soon be funding and maintaining the availability of both BTC and LR at a 100% ratio against the exchange rate.\n\nI have chosen to use a http://www.nic.cz.cc/ domain because it is purposefully obscure ! It is a paid domain for 2 years and is automatically renewable. Its an extremely inexpensive method for hosting a domain with SSL support and Privacy Protect. ( Less than $5 for 2 years ) I have full control over my A Record etc. and the web host is very stable. In the future I will be adding SSL and the LR and Bitcoin API's to make the exchange service 100% automated, as long as their are available funds.\n\nI'm also advertising in Bitcoin in Money Share Forums / e-currency Investment Forums\n\nhttp://www.moneyshareforum.com/index.php?showtopic=3513 - Bitcoin P2p Cryptocurrency, Bitcoin P2P Cryptocurrency - Free - Open Source Software Project !\n\nWhilst I would not recommend 'investing' in most of the 'sites' on this forum. Searching through the posts and links will give some of you an incite into just how popular e-currencies are with this type of community. This type of activity makes up a massive percentage of e-currency transactions and I consider it very relevant in the successful future of Bitcoin.\n\nThank you. Cool"]],"u":"https://bitcointalk.org/index.php?topic=30.msg935#msg935","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1271348593,"b":[["t","For those of you that don't already know; most of these 'investments' are ponzi schemes."]],"u":"https://bitcointalk.org/index.php?topic=30.msg941#msg941","sj":"Re: We accept Bitcoins"},{"f":"BitcoinFX","d":1271397454,"b":[["q","For those of you that don't already know; most of these 'investments' are ponzi schemes.","Quote from: madhatter2 on April 15, 2010, 04:23:13 PM"],["t","Indeed they are and you should exercise extreme caution before even considering 'investing' and also view most HYIP's as a game of chance.\n\nI can be considered a trusted admin and my Private Investment Club opportunity is intentionally 'low level' and 'low risk'.\n\nSabunir had expressed interest in the original BitcoinFX Private Investment Club opportunity, so I have offered a 100% free share, for my usage of the banner designs. I will offer more free shares to Bitcoin Forum members in the future.\n\nPlease understand that what I'm effectively doing is 'backing' Bitcoins with my profitable Forex Trading abilities, as well as, creating an interest and demand for Bitcoins with existing e-currency users at the same time. I have 'backed' both projects with $1000 LR to avoid any issues.\n\nThis is a much more logical approach than just offering an 'exchange' service where you are effectively just 'giving away' USD or EUR for 'digital tokens' ...\n\nHowever, I fully understand your concerns."]],"u":"https://bitcointalk.org/index.php?topic=30.msg953#msg953","sj":"Re: We accept Bitcoins"},{"f":"thufir","d":1271999632,"b":[["t","Vekja.net Presents a Bitcoin Exclusive:\n\nTrue Anonymous Web & Email Hosting\n\nOur goal: Contribute to the Bitcoin economy and thus destroy the bankers ability to control our destiny through their printing press.\n\nOur strategy: Provide Highly Secure Anonymous Web & Email Hosting at Cost, and provide it only through Bitcoin!\n\n(A Vekja Account is free, and so is a Vekja Bitcoin Account once you have a general account. The Vekja Hosting Account is our first billable offering. You can choose to activate that or not, independent of your general and Bitcoin accounts.)\n\nSign up now and experience a 30 minute free trial of a Hosting Account.\n\nVisit https://vekja.net and sign up for more details!"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1008#msg1008","sj":"NEW SERVICE: Anonymous email & web hosting!"},{"f":"sirius","d":1272018165,"b":[["q","Vekja.net Presents a Bitcoin Exclusive:","Quote from: thufir on April 23, 2010, 05:13:52 AM"],["t","Awesome! I'll add a \"Trade\" page on the bitcoin.org main site, where we can list btc-accepting services."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1010#msg1010","sj":"Re: NEW SERVICE: Anonymous email & web hosting!"},{"f":"komoto","d":1272593712,"b":[["t","hello\n\ni found these urls while surfing on i2p:\n\nmybitcoin.i2p (resolves to nwpqc65o333ifqq7wqovo2ito5y3ca6rfygz3p6pusau26t6tpca.b32.i2p)\nxqzfakpeuvrobvpj.onion (on tor. they advertise this url in the login area)\nmybitcoin.com (loads the same site from the public internet. they use cacert for ssl.)\n\n(some sort of web-based wallet for bitcoin)\n\nprivacyshark.com\n\n(sells domain names for bitcoins)"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1035#msg1035","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1272826839,"b":[["t","That mybc thing is nice for non-geeks. I signed up last night to try it out. This is something I can setup for my 'ol pappy and he'd be able to actually use it. Tongue"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1047#msg1047","sj":"Re: We accept Bitcoins"},{"f":"thufir","d":1273009202,"b":[["t","I would like to point out then that http://vekja.net has always provided a Free web based Bitcoin account even better than the mybitcoin service mentioned above (in addition to the non-free Email and Web service that I announced earlier).\n\nI should have announced this separately before, as there is such great value in a Bitcoin Web App. The value is not just for Grandpa, but is also for anyone who wants to use Bitcoin on a mobile device (or any platform where there is no client yet available).\n\nIf you haven't done so already, please come check out the https://Vekja.net Bitcoin web app. Registration is free and does not require an email like the mybitcoin service currently does.\n\nIf you have any questions or suggestions, just use the built in messaging system to send a message to admin. I will be glad to help.\n\nFor the record: I hereby promise that the Vekna.net Bitcoin account will always remain free (that includes spam free). This was always my intent from the beginning."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1066#msg1066","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1273013754,"b":[["t","I signed up for a vekja free Bitcoin account. Very nice. It is very simple. Almost too simple for my tastes tho. :/ I mean, I'm sure it works as expected but the interface is really lacking features.\n\nMyBitcoin has some nice stuff like payment history, the ability to change your Bitcoin address (which I totally need btw), some basic statistics, and an addressbook (very handy; try typing in a long ugly Bitcoin address from a Blackberry or iPhone -- no thanks).\n\nThe need for an email address mystifies me also. I wonder why they require that. Service announcements?\n\nEdit: I see a transaction history page. I must have scrolled right past it. The interface is all on one page??\n\nEdit 2: Looks like MyBitcoin can do payment notes too (I wonder if/how this works to/from Bitcoin and MyBitcoin)."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1067#msg1067","sj":"Re: We accept Bitcoins"},{"f":"thufir","d":1273014774,"b":[["t","Yes, there is a transaction history.\n\nI was always planning an address book. I just wanted to break up the interface into multiple pages first.\n\nI will also add the ability you request for creating new (and multiple) addresses.\n\nThank you for the feedback and suggestions madhatter2!"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1068#msg1068","sj":"Re: We accept Bitcoins"},{"f":"NewLibertyStandard","d":1273049736,"b":[["t","I just added a second line to my graphs <http://newlibertystandard.wetpaint.com/page/Exchange+Rate> showing the closing price of bitcoins at the Bitcoin Market <https://www.bitcoinmarket.com/>."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1070#msg1070","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1273139199,"b":[["t","Hmm.. looks like MBC has PGP-signed email payment notifications. Also looks like they don't require the email address to signup. Maybe they read this forum?\n\nHey! *waves @ MBC's owners* Sign up and tell us your plans! Tongue"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1071#msg1071","sj":"Re: We accept Bitcoins"},{"f":"The Madhatter","d":1273183647,"b":[["t","Haha! I actually have some of my elderly family members using MBC now. Tongue\n\nMaybe mum should get 9,000 coins for Mother's day! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1076#msg1076","sj":"Re: We accept Bitcoins"},{"f":"teppy","d":1274289513,"b":[["t","I run the MMO A Tale in the Desert. We charge $13.95/month for the game, and pay about $0.74 in merchant and gateway fees.\n\nWe'll now accept Bitcoins as an alternate payment method. The price per month is 2000 BTC, which according to the exchange is a discount right now.\n\nInstructions:\nVisit http://www.atitd.com and download the game client. Native Windows, Linux and OSX versions are available.\nInstall + Run the client, and create a trial character.\nIf you like the game, send 2000 BTC to: 17CJvRrNdqSPN3Zs2dWfNY6GoCiMRfNG2T to activate your account.\nIn the message field, include your character name and shard; I'll then credit you for a month of gameplay.\nRight now this is done manually, so the lag could be anywhere from minutes to the next morning.\n\nTeppy"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1159#msg1159","sj":"A Tale in the Desert now accepts Bitcoins"},{"f":"laszlo","d":1274293310,"b":[["t","Teppy, just so you know, you can't include a message if you send to a bitcoin address, only if you send to an IP address.  The way we usually do it is we issue a new address to each person we ask to send us money so that we know it was that person who sent it."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1160#msg1160","sj":"Re: We accept Bitcoins"},{"f":"D҉ataWraith","d":1274298762,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1161#msg1161","sj":"Re: We accept Bitcoins"},{"f":"teppy","d":1274308413,"b":[["t","Hmm - is there any text field associated with an address based transaction? It does make accepting Bitcoins a bit more cumbersome. Would including such a text field as part of the protocol compromise anonymity somehow?\n\nHypothetically, a short text message could be encoded into transactions by charging, say, 2000-2000.999999 Bitcoins and encoding the text portion in the fractional part of the amount.\n\nOr does that solve a problem that doesn't exist?\n\nIs there already a protocol in place to say \"make me a new address to send BTC to\" ?"]],"u":"https://bitcointalk.org/index.php?topic=30.msg1163#msg1163","sj":"Re: We accept Bitcoins"},{"f":"laszlo","d":1274323311,"b":[["t","You can create new addresses all you want.. the way most people are doing this is they generate a new address for the user and display it to them.  When payment is received to that address it credits the user.  You can just generate a new address for each transaction, like a transaction ID essentially.  Link2VOIP automated it all and some others have as well, simply by using the built in JSON-RPC functionality.\n\nSatoshi would have to address the other questions about including messages.."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1164#msg1164","sj":"Re: We accept Bitcoins"},{"f":"satoshi","d":1274391822,"b":[["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.","Quote from: DataWraith on May 19, 2010, 07:52:42 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=30.msg1169#msg1169","s":1,"n":106,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/106/","sj":"Re: We accept Bitcoins"}]},{"id":"p20","k":"p","s":"bitcointalk","t":"Questions about Addresses","u":"https://bitcointalk.org/index.php?topic=34","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/20/","m":[{"f":"Sabunir","d":1264990622,"b":[["t","1) What would happen if one attempts to send an amount of coins to an IP address that isn't running the program?\n2) What would happen if one attempts to send an amount of coins to a invalid Bitcoin Address?\n3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?\n4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?\n\nI thank answerers for expanding my knowledge."]],"u":"https://bitcointalk.org/index.php?topic=34.msg185#msg185"},{"f":"sirius","d":1265021083,"b":[["q","1) What would happen if one attempts to send an amount of coins to an IP address that isn't running the program?\n2) What would happen if one attempts to send an amount of coins to a invalid Bitcoin Address?","Quote from: Sabunir on February 01, 2010, 02:17:02 AM"],["t","Not possible, the software doesn't allow that."],["q","3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?\n4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?","Quote"],["t","I guess the money will just be lost in that case."]],"u":"https://bitcointalk.org/index.php?topic=34.msg187#msg187"},{"f":"BitcoinFX","d":1265065807,"b":[["t","What happens to Bitcoins sent to an IP address where the sub-net computers are each running Bitcoin software ? Huh\n\nDo they all receive an equal share of Bitcoins ? lol Roll Eyes"]],"u":"https://bitcointalk.org/index.php?topic=34.msg196#msg196"},{"f":"NewLibertyStandard","d":1265067684,"b":[["t","If I remember correctly I think I was told that they would be sent to the first bitcoin application with whom the sender connects."]],"u":"https://bitcointalk.org/index.php?topic=34.msg197#msg197"},{"f":"Sabunir","d":1265074573,"b":[["t","Relatedly, what protections are in place for preventing someone from forging a Bitcoin Address?"]],"u":"https://bitcointalk.org/index.php?topic=34.msg198#msg198"},{"f":"sirius","d":1265078066,"b":[["q","What happens to Bitcoins sent to an IP address where the sub-net computers are each running Bitcoin software ? Huh","Quote from: BitcoinFX on February 01, 2010, 11:10:07 PM"],["t","The coins go to the machine that the sender connects to. You need to do port forwarding to direct the incoming connections at port 8333 to the correct subnet address. Instructions: www.portforwarding.com <http://www.portforwarding.com>."]],"u":"https://bitcointalk.org/index.php?topic=34.msg199#msg199"},{"f":"BitcoinFX","d":1265101220,"b":[["t","Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine. Grin\n\nHowever, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !\n\nBitcoin node (1) 192.168.0.2\n\nBitcoin node (2) 192.168.0.3\n\nSo, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?"]],"u":"https://bitcointalk.org/index.php?topic=34.msg202#msg202"},{"f":"sirius","d":1265114048,"b":[["q","Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine. Grin\n\nHowever, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !\n\nBitcoin node (1) 192.168.0.2\n\nBitcoin node (2) 192.168.0.3\n\nSo, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?","Quote from: BitcoinFX on February 02, 2010, 09:00:20 AM"],["t","The connection won't get through at all if the port is not forwarded."]],"u":"https://bitcointalk.org/index.php?topic=34.msg203#msg203"},{"f":"BitcoinFX","d":1265209035,"b":[["q","> Quote from: BitcoinFX on February 02, 2010, 09:00:20 AM\n> Thanks, I understand that and my port 8333 is correctly forwarded to my 24/7 Bitcoin machine. Grin\n>\n> However, lets say that I have 2 machines on the same IP running Bitcoin without port 8333 forwarded on either !\n>\n> Bitcoin node (1) 192.168.0.2\n>\n> Bitcoin node (2) 192.168.0.3\n>\n> So, I would guess that 192.168.0.2 machine would receive the bitcoins because it is the first IP on the sub-net ?\n\nThe connection won't get through at all if the port is not forwarded.","Quote from: sirius-m on February 02, 2010, 12:34:08 PM"],["t","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 ?\n\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.\"\n\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 ! Smiley\n\nI have enough internet connections, routers and PC equipment - So, I'm off to make an 'official' test for myself whilst I RTM  Grin"]],"u":"https://bitcointalk.org/index.php?topic=34.msg206#msg206"},{"f":"satoshi","d":1265242027,"b":[["t","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.\n\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.\n\nSomeone should post their static IP so people can try out sending by IP and also give that user free money.\n\nThere's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.\n\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\"."]],"u":"https://bitcointalk.org/index.php?topic=34.msg222#msg222","s":1,"n":41,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/41/"},{"f":"BitcoinFX","d":1265276914,"b":[["q","Someone should post their static IP so people can try out sending by IP and also give that user free money.","Quote from: satoshi on February 04, 2010, 12:07:07 AM"],["t","Thanks for clarifying that satoshi.\n\nI'm more than happy to share my static IP for testing - I run a Tor Relay from this IP so the address is already publicly available at http://trunk.torstatus.kgprog.com/ for example.\n\nPlease note that this is not the IP address from where I will be running my 'Bitcoin Bank' / exchange service. It's a personal IP address and is effectively my project contribution and testing 'Lab' for other open source projects. I'm a big contributor of Grid Republic etc.\n\n*** N.B. Post has been edited after the successful testing ***\n\nAnyone is still welcome to make a test payment to my IP. Please send me a forum PM first and stipulate in the comments if you are making a test payment or a donation, so that I can return your Bitcoins to you, if you wish. Any donations will be much appreciated and will help to set up the separate 'exchange service' faster.\n\nPlease email: bitcoinfx @ gmail.com regarding any issues. (EDIT: no longer in use 2014)\n\nYou can also visit my website: BitcoinFX - http:// www .bitcoinfx .cz.cc EDIT: Domain no longer active - An early manual e-currency exchange by email only - the domain only provided contact info. etc.\n\nThank you."]],"u":"https://bitcointalk.org/index.php?topic=34.msg227#msg227"},{"f":"SmokeTooMuch","d":1265298546,"b":[["t","2x 0.01 BTC sent.\n\n0.01 BTC per Bitcoin adress and 0.01 BTC per IP-adress.\n\nI don't need it back Smiley\n\nBTW: http://trunk.torstatus.kgprog.com/ is telling me I'm using TOR, but I`m not. It shows my real IP."]],"u":"https://bitcointalk.org/index.php?topic=34.msg236#msg236"},{"f":"BitcoinFX","d":1265303471,"b":[["t","Thanks SmokeTM.\n\nBoth Micro donations were successfully received. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=34.msg237#msg237"},{"f":"Sabunir","d":1265391090,"b":[["q","> Quote from: Sabunir on February 01, 2010, 02:17:02 AM\n> 3) What would happen if one attempts to send an amount of coins to a Bitcoin Address that nobody owns?\n> 4) What would happen if one attempts to send an amount of coins to a Bitcoin Address that used to be owned, but has since been abandoned (recipient stopped running the program, or deleted their wallet)?\n\nI guess the money will just be lost in that case.","Quote from: sirius-m on February 01, 2010, 10:44:43 AM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=34.msg246#msg246"},{"f":"satoshi","d":1265399086,"b":[["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?","Quote from: Sabunir on February 05, 2010, 05:31:30 PM"],["t","That's not possible.  You've handed control of the money over to the recipient's keypair.  Only that key can control it.\n\nIt's similar to if you encrypt a file with AES and a strong password, and you lose the password.  The data is lost."]],"u":"https://bitcointalk.org/index.php?topic=34.msg250#msg250","s":1,"n":44,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/44/"}]},{"id":"p21","k":"p","s":"bitcointalk","t":"Win32 CPU Cycles vs 'Live Protection' Engines ?","u":"https://bitcointalk.org/index.php?topic=35","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/21/","m":[{"f":"BitcoinFX","d":1265050313,"b":[["t","I wanted to document an issue I encountered when first installing and using the Bitcoin software.\n\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.\n\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.\n\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.\n\nI have yet to do more testing, however I also encountered the same issue when using Comodo Internet Security (free version).\n\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 ?"]],"u":"https://bitcointalk.org/index.php?topic=35.msg189#msg189"},{"f":"satoshi","d":1265240214,"b":[["t","Thanks for that.  Which version of Windows?"]],"u":"https://bitcointalk.org/index.php?topic=35.msg220#msg220","s":1,"n":40,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/40/"}]},{"id":"p22","k":"p","s":"bitcointalk","t":"Proof-of-work difficulty increasing","u":"https://bitcointalk.org/index.php?topic=43","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/22/","m":[{"f":"satoshi","d":1265397552,"b":[["t","We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.  \n\nThe minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that.  For most of last year, we were hovering below the minimum.  On 30 Dec we broke above it and the algorithm adjusted to more difficulty.  It's been getting more difficult at each adjustment since then.\n\nThe adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year.  That means you generate only 55% as many coins for the same amount of work.\n\nThe difficulty adjusts proportionally to the total effort across the network.  If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.\n\nFor those technically inclined, the proof-of-work difficulty can be seen by searching on \"target:\" in debug.log.  It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block.  It gets adjusted every 2016 blocks, typically two weeks.  That's when it prints \"GetNextWorkRequired RETARGET\" in debug.log.\n\nminimum    00000000ffff0000000000000000000000000000000000000000000000000000\n30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000\n11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000\n25/01/2010 00000000be710000000000000000000000000000000000000000000000000000\n04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000\n14/02/2010 0000000065465700000000000000000000000000000000000000000000000000\n24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000\n08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000\n21/03/2010 0000000038137500000000000000000000000000000000000000000000000000\n01/04/2010 000000002a111500000000000000000000000000000000000000000000000000\n12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000\n21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000\n04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000\n19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000\n29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000\n11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000\n24/06/2010 000000000d314200000000000000000000000000000000000000000000000000\n06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000\n13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000\n16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000\n27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000\n05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000\n15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000\n26/08/2010 0000000000692000000000000000000000000000000000000000000000000000\n\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%\n05/08/2010   352.17   +44%\n15/08/2010   511.77   +45%\n26/08/2010   623.39   +22%"]],"u":"https://bitcointalk.org/index.php?topic=43.msg249#msg249","s":1,"n":43,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/43/"},{"f":"satoshi","d":1266215318,"b":[["t","14/02/2010 0000000065465700000000000000000000000000000000000000000000000000\n\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%\n\nAnother big jump in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days ago.  It was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time."]],"u":"https://bitcointalk.org/index.php?topic=43.msg346#msg346","s":1,"n":58,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/58/"},{"f":"Suggester","d":1266286549,"b":[["t","[Edit: I later found that I was generating quite a bit more than that, just didn't realize it because of the \"matures in xx more blocks\" concept. I still think it will be a major headache when the difficulty significantly increases though. I apologize for my silliness Smiley]\n\nSatoshi, 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?\n\nI don't know if that means reducing the block size or reducing the 120-block threshold to say 12-block only or what, but because the difficulty is increasing I can imagine that a year from now the situation will be even worse (3+ weeks until you see the first spendable coins!) and we better find a solution for this ASAP."]],"u":"https://bitcointalk.org/index.php?topic=43.msg361#msg361"},{"f":"Sabunir","d":1266297510,"b":[["t","I would like to comment that as of late, it seems almost as if I am generating nearly no Bitcoins. Indeed, my rate of acquisition seems to be greater than ten times slower. If I cannot stay online for about fourteen consecutive hours (very hard to do on a satellite connection!), I actually get nothing at all.\n\nHow this exactly relates to the difficulty adjustments is beyond my knowledge; I offer this feedback as a kind of \"field report\"."]],"u":"https://bitcointalk.org/index.php?topic=43.msg368#msg368"},{"f":"theymos","d":1266300111,"b":[["t","I generated 5 blocks today on my Pentium processor. Two of them were within 3 minutes of each other.\n\nI have noticed some slowdown since the adjustment, but I still generate a lot of coins. My computer is off while I'm sleeping, and BitCoin bootstraps quickly when I turn it back on. Do you guys-who-are-having-trouble have the BitCoin port open?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg371#msg371"},{"f":"Sabunir","d":1266310311,"b":[["t","My port is open, both in my software and hardware firewall. My router is handling it appropriately. Perhaps it has to do with my connection's very high latency (2000ms or more on average) and/or my high packet loss (sometimes up to 10% loss)?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg372#msg372"},{"f":"satoshi","d":1266341800,"b":[["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?","Quote from: Suggester on February 16, 2010, 02:15:49 AM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=43.msg376#msg376","s":1,"n":60,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/60/"},{"f":"Suggester","d":1266370107,"b":[["q","If I cannot stay online for about fourteen consecutive hours (very hard to do on a satellite connection!), I actually get nothing at all.","Quote from: Sabunir on February 16, 2010, 05:18:30 AM"],["t","Can Satoshi confirm whether the computations your machine had made carries on if the session was interrupted, or do you need to start all over if you disconnected before generating at least one block? If it carries on, maybe a little meter indicating the % left until your block completes can be a nice addition so people would have some hope (actually, it will be a nice addition anyway whether the computations get carried on after disconnection or not!)"],["q","I generated 5 blocks today on my Pentium processor. Two of them were within 3 minutes of each other.","Quote from: theymos on February 16, 2010, 06:01:51 AM"],["t","Ok, I just realized that I didn't understand how Bitcoin worked to begin with. The blocks get generated anyway whether you're generating coins or not. The average amount of creation conformed what I observed before (120/20 hrs, or 6/hr). This has got absolutely nothing to do with your CPU power, it's  constant for all practical purposes. The CPU power determines the \"transactions\" that get created and \"matures in xx blocks\". My head just got a bit bigger now Smiley\n\nThis also means theymos that there was probably a coincidence or error for your 3-minute interval observation!"]],"u":"https://bitcointalk.org/index.php?topic=43.msg381#msg381"},{"f":"satoshi","d":1266429483,"b":[["q",". Perhaps it has to do with my connection's very high latency (2000ms or more on average)","Quote from: Sabunir on February 16, 2010, 08:51:51 AM"],["t","2 seconds of latency in both directions should reduce your generation success by less than 1%."],["q","and/or my high packet loss (sometimes up to 10% loss)?","Quote from: Sabunir on February 16, 2010, 08:51:51 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=43.msg388#msg388","s":1,"n":61,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/61/"},{"f":"Sabunir","d":1266771524,"b":[["t","How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg424#msg424"},{"f":"NewLibertyStandard","d":1266778363,"b":[["q","How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?","Quote from: Sabunir on February 21, 2010, 04:58:44 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=43.msg425#msg425"},{"f":"satoshi","d":1267051344,"b":[["t","The automatic adjustment happened earlier today.\n\n24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000\n\n24/02/2010  3.78  +49%\n\nI updated the first post."]],"u":"https://bitcointalk.org/index.php?topic=43.msg510#msg510","s":1,"n":78,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/78/"},{"f":"Suggester","d":1267072499,"b":[["q","> Quote from: Sabunir on February 21, 2010, 04:58:44 PM\n> How do you adjust this difficulty, anyway? (Administrating a decentralized system?) And what would prevent an attacker from setting the difficulty very low or very high to interfere with the system?\nMy understanding is that every Bitcoin client has the same algorithm (formula) built into it to automatically adjust the difficulty every so many blocks.","Quote from: NewLibertyStandard on February 21, 2010, 06:52:43 PM"],["t","Then how is it dependent on how many CPU's are connected to the whole network?"],["q","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.","Quote from: NewLibertyStandard on February 21, 2010, 06:52:43 PM"],["t","We need Satoshi to confirm that because clients accept blocks generated at easier difficulties all the time whenever the PoW's difficulty increases."]],"u":"https://bitcointalk.org/index.php?topic=43.msg533#msg533"},{"f":"satoshi","d":1267139189,"b":[["t","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.\n\nI don't know what you're talking about accepting easier difficulties."]],"u":"https://bitcointalk.org/index.php?topic=43.msg540#msg540","s":1,"n":81,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/81/"},{"f":"Suggester","d":1267148108,"b":[["q","I don't know what you're talking about accepting easier difficulties.","Quote from: satoshi on February 25, 2010, 11:06:29 PM"],["t","We were essentially discussing Sabunir's question about what prevents someone from messing with the program's source code to adjust block-generating difficulty to be very easy, then make a network on his own and create a, say, 50,000-block proof-of-work within seconds then finally propagate it across the real network to steal \"votes\" towards his new fake blocks as technically, his proof would be \"the longest\". So is there a way to verify how much work was actually put into a given PoW (for eg. how many zero's are at the beginning of each hash or something)?"],["q","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.","Quote from: satoshi on February 16, 2010, 05:36:40 PM"],["t","Since we're at it, what's the approximate time for proof-of-work propagation across a network of about 100,000 machines? Is there a way to optimize connections so that broadcasting is done via a pyramid-form to minimize the needed time? For example, the block creator sends it to 10 nodes, then those 10 send it to a 100 provided that none of those 100 were among the original 11, then those 100 tell a 1000 provided that none of those 1000 were among the original 111, etc to save time."]],"u":"https://bitcointalk.org/index.php?topic=43.msg541#msg541"},{"f":"Legion","d":1267166680,"b":[["t","This overclocked i7 still hasn't generated any keys after 8 hours..."]],"u":"https://bitcointalk.org/index.php?topic=43.msg549#msg549"},{"f":"NewLibertyStandard","d":1267167789,"b":[["q","This overclocked i7 still hasn't generated any keys after 8 hours...","Quote from: Legion on February 26, 2010, 06:44:40 AM"],["t","It may take longer than 8 hours to generate a block.\n\nHave you previously generated bitcoins? Are the number of blocks listed at the bottom of Bitcoin greater than 42650? Those need to download before it can start generating coins. How many connections are listed at the bottom of Bitcoin? Did you click Options > Generate Coins? How much CPU does your process viewer show that Bitcoin is using? Is your Internet connection steady? I had problems when I tried sharing Internet from my smartphone to my computer."]],"u":"https://bitcointalk.org/index.php?topic=43.msg550#msg550"},{"f":"Legion","d":1267174661,"b":[["q","> Quote from: Legion on February 26, 2010, 06:44:40 AM\n> This overclocked i7 still hasn't generated any keys after 8 hours...\nIt may take longer than 8 hours to generate a block.\n\nHave you previously generated bitcoins? Are the number of blocks listed at the bottom of Bitcoin greater than 42650? Those need to download before it can start generating coins. How many connections are listed at the bottom of Bitcoin? Did you click Options > Generate Coins? How much CPU does your process viewer show that Bitcoin is using? Is your Internet connection steady? I had problems when I tried sharing Internet from my smartphone to my computer.","Quote from: NewLibertyStandard on February 26, 2010, 07:03:09 AM"],["t","No, but..42663 blocks..8 connections..and yes, generating.  Bitcoin uses 50-80 CPU..but it only has access to two cores until I bump the VM it is in to 4 cores..Operating over tor by the way."]],"u":"https://bitcointalk.org/index.php?topic=43.msg552#msg552"},{"f":"NewLibertyStandard","d":1267175964,"b":[["t","I think that no bitcoins generated in 8 hours from within a VM utilizing two modern cores is probably not unusual. Keep it running for a few days and I expect that you'll generate more than a few packs of bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=43.msg554#msg554"},{"f":"Legion","d":1267222159,"b":[["t","I wonder what I could generate with all eight threads..."]],"u":"https://bitcointalk.org/index.php?topic=43.msg560#msg560"},{"f":"dmp1ce","d":1272822373,"b":[["q","> Quote from: satoshi on February 25, 2010, 11:06:29 PM\n> I don't know what you're talking about accepting easier difficulties.\n\nWe were essentially discussing Sabunir's question about what prevents someone from messing with the program's source code to adjust block-generating difficulty to be very easy, then make a network on his own and create a, say, 50,000-block proof-of-work within seconds then finally propagate it across the real network to steal \"votes\" towards his new fake blocks as technically, his proof would be \"the longest\". So is there a way to verify how much work was actually put into a given PoW (for eg. how many zero's are at the beginning of each hash or something)?","Quote from: Suggester on February 26, 2010, 01:35:08 AM"],["t","I am also wondering about Suggester's question.  It seems like modifying the code to give a node an advantage in generating coins might be possible.\n\nI am confused as to why each node on the network is actually doing when set to generate coins.  What problem are they solving that takes 100% CPU?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1046#msg1046"},{"f":"theymos","d":1272834231,"b":[["t","Your CPU is creating SHA-256 hashes. It's not possible to cheat: if the hashes you create are invalid, no one else in the network will accept them. If you inject a 50,000-block chain of \"easy blocks\" into the network, everyone will immediately see that the hash for the first block in the chain is above the current target and ignore it and every block derived from it."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1048#msg1048"},{"f":"fergalish","d":1273579928,"b":[["t","Interestingly, using laszlo's mac os version of bitcoin, one can see how many hashes per second the computer is performing.  I'm currently getting about 1 million hashes per second.  Given the current difficulty 0000000013ec53, I'll have to perform about 2^35~3x10^10 hashes before I have a decent chance of getting one below the target, and at 10^6/s, that should take about 30000 sec, or about two per day.  The actual interval varies a lot - it's a random process, but that seems to be more-or-less the correct amount.\n\nSatoshi, could you update the first post in this thread, with the complete history of difficulty-of-work increases please?  I'd try, but for some reason, I've lost my logfiles.  Fortunately the wallet is safe."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1111#msg1111"},{"f":"laszlo","d":1273583587,"b":[["t","Maybe someone with a little background in this statistics/math stuff can shed some light on this..\n\nThe way this thing works is it takes a (basically random) block of data and alters a 32 bit field inside it by starting at 1 and incrementing.  The block of data also contains a timestamp and that's incremented occasionally just to keep mixing it up (but the incrementing field isn't restarted when the timestamp is update).  If you get a new block from the network you sort of end up having to start over with the incrementing field at 1 again.. however all the other data changed too so it's not the same thing you're hashing anyway.\n\nThe way I understand it, since the data that's being hashed is pretty much random and because the hashing algorithm exhibits the 'avalanche effect' it probably doesn't matter if you keep starting with 1 and incrementing it or if you use pseudo random values instead, but I was wondering if anyone could support this or disprove it.\n\nCan you increase your likelihood of finding a low numerical value hash by doing something other than just sequentially incrementing that piece of data in the input?  Or is this equivalent to trying to increase your chances of rolling a 6 (with dice) by using your other hand?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1112#msg1112"},{"f":"D҉ataWraith","d":1273614651,"b":[["q","The way I understand it, since the data that's being hashed is pretty much random and because the hashing algorithm exhibits the 'avalanche effect' it probably doesn't matter if you keep starting with 1 and incrementing it or if you use pseudo random values instead, but I was wondering if anyone could support this or disprove it.","Quote from: laszlo on May 11, 2010, 01:13:07 PM"],["t","Yep, your understanding here is correct. It does not matter what exactly gets hashed, and no, you can't cheat without first breaking SHA-256, which is considered difficult.\n\nThe salient property of cryptographic hash functions is that they are as random as is possible while still being deterministic. That's what their strength depends on -- after all if they weren't random, if there were obvious patterns, they could be broken that way. So the ideal hash function behaves just like a random number generator. It does not matter what you feed in, timestamp or not, whatever's put in there, the hash should still behave randomly (i.e. every possible outcome has the same a-priori probability of occuring). Incrementing by one works just as well as completely changing everything every step (this follows from the avalanche property). However, the initial value, before you start incrementing, must be (pseudo-)randomly chosen, or every computer will start at the same point, and the fastest one always wins, which is not what is wanted here."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1113#msg1113"},{"f":"teppy","d":1275488865,"b":[["t","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.\"\n\nThis might partially solve the frustration of new users not getting any Bitcoins right away."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1321#msg1321"},{"f":"satoshi","d":1275504338,"b":[["t","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.\n\nEvery node and each processor has a different public key in its block, so they're guaranteed to be scanning different territory.\n\nWhenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1323#msg1323","s":1,"n":115,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/"},{"f":"laszlo","d":1275520874,"b":[["t","I created a little performance counter for myself to use locally, you guys are welcome to try it.\n\nSatoshi, maybe you could integrate this or something similar and put an option in there to turn it on/off?  It spams up your debug.log and shows the performance of each thread.. it also shows on the UI in the status bar where it used to say 'Generating'.\n\nPatch: http://heliacal.net/~solar/bitcoin/bitcoin-svn-79-perfcounter-2010-06-02.patch\n\nScreenshot:"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1327#msg1327"},{"f":"lachesis","d":1275623912,"b":[["t","Can someone share the math required to compute the estimated amount of time to generate a pack of bitcoins?\n\nBasically, a formula that integrates the difficulty (either as a hex number (currently 000000000f675c00000000000000000000000000000000000000000000000000) or as the difficulty factor (currently 16.62)) and number of hashes checked per second (currently like 1M for me) which would return the average time between blocks found?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1346#msg1346"},{"f":"theymos","d":1275629491,"b":[["t","chancePerHash=target/max\nnumberOfHashesToWin=0.5/chancePerHash\nnumberOfSecondsToWin=numberOfHashesToWin/hahesPerSecond\n\n(0.5/(target/max))/hashesPerSecond"],["c","(0.5/(0x000000000f675c00000000000000000000000000000000000000000000000000/0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff))/1000000 "],["t","=\n\n35689 seconds\n\nAbout one block per 9.9 hours. Does this match your observations? I'm not totally sure about the math."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1347#msg1347"},{"f":"lachesis","d":1275630700,"b":[["t","Sounds completely reasonable. I just started generating today, so I'll let you know once I get more blocks. Thanks!"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1349#msg1349"},{"f":"lachesis","d":1275705494,"b":[["t","Laszio, I've remade your patch to spam the debug log less (1/10th as often). I also the extended JSON-RPC library to add \"gethps\" (which returns the same string displayed in the UI). It also adds listgenerated, which returns a list of the strings from the UI representing generated blocks. In the third and final patch, I modified net.h to compile with -O2 on my machine (which it wouldn't before).\n\nHere are the patches:\nhttp://www.alloscomp.com/bitcoin/bitcoin-svn-80-perfcounter-less-debug-spam-2010-06-05.patch <- Apply Laszio's patch first, then this one.\nSorry, that patch ^^ is completely broken. The changes are trivial (the same line in 3 places), but I failed at diffing. I'll upload a better patch when I have time.\nhttp://www.alloscomp.com/bitcoin/bitcoin-svn-80-rpcextended-2010-06-05.patch\nhttp://www.alloscomp.com/bitcoin/bitcoin-svn-80-netpatch-2010-06-05.patch\n\nThanks to Laszio for the original performance patch."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1359#msg1359"},{"f":"laszlo","d":1275707932,"b":[["t","Cool, I was just playing around with trying to make it adjust the rate without taking much of a performance hit.. that's why it tries to adjust that variable, to keep it to a few per second or so.. maybe you can figure out a better formula, I just kind of did that by experimenting around with it."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1362#msg1362"},{"f":"lachesis","d":1275718552,"b":[["q","About one block per 9.9 hours. Does this match your observations? I'm not totally sure about the math.","Quote from: theymos on June 04, 2010, 05:31:31 AM"],["t","My system has jumped up to about 1200 khps. Also, I got Bitcoin running on a VPS which is giving about 2350 khps. The formula which you posted (and I arrived at myself later) predicts a block every 8.2 hours for my laptop and one every 4.2 hours for the VPS. Since I started yesterday afternoon, I've only generated the one block.\n\nSound strange? Or am I just having bad luck?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1363#msg1363"},{"f":"theymos","d":1275750177,"b":[["t","The main part of the formula that I'm uneasy about is the \"target probability\" of 0.5. 0.5 is used for calculations involving brute-forcing passwords, but maybe this is different. If your blocks consistently take double the amount of time that the formula predicts, use 1 instead."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1370#msg1370"},{"f":"lachesis","d":1275751709,"b":[["q","The main part of the formula that I'm uneasy about is the \"target probability\" of 0.5. 0.5 is used for calculations involving brute-forcing passwords, but maybe this is different. If your blocks consistently take double the amount of time that the formula predicts, use 1 instead.","Quote from: theymos on June 05, 2010, 03:02:57 PM"],["t","I thought about that. I don't know if 0.5 is valid or not. I'll continue to take observations. I wonder if it writes to the debug log when it has success.\n\nActually, that formula assumes that you're working on one block until you figure it out. In Bitcoin, aren't multiple nodes working on the same block? When one finishes, the others abandon work on it and choose another block? That was the impression that I had, but it might be wrong."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1371#msg1371"},{"f":"theymos","d":1275754878,"b":[["q","I wonder if it writes to the debug log when it has success.","Quote"],["t","BitCoin does say when it has solved a block. Search for \"proof-of-work found\"."],["q","In Bitcoin, aren't multiple nodes working on the same block?","Quote"],["t","No. Each node's block is unique because it contains their unique public key. Functionally, every hash gives you a totally random number between 0 and the maximum value of a 256-bit number. If the random number is equal to or below the target, you win. So the probability of winning with one hash is target in max.\n\nStarting on another block because somebody else won requires almost no work.\n\nSee the BitCoin Wiki \"block\" article <http://www.bitcoin.org/wiki/doku.php?id=block> and the BitCoin paper <http://www.bitcoin.org/sites/default/files/bitcoin.pdf> for more info."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1372#msg1372"},{"f":"fergalish","d":1276075324,"b":[["q","I thought about that. I don't know if 0.5 is valid or not. I'll continue to take observations. I wonder if it writes to the debug log when it has success.","Quote from: lachesis on June 05, 2010, 03:28:29 PM"],["t","Use a value of 1, not 0.5.  Suppose max=100 and target=10, then 10 out of every 100 hashes will be at or below the target, so your success rate will be 10% NOT 5%.\n\nAt the moment target/max ~= 1.5x10^-11 (target~=0x000000000f, which is 36 zeros, so you basically need to throw a dice with 2^36=69 billion sides, and wait until you get a 1), and you're doing 1 million x 86400 = 86.4 billion hashes per day, so you can expect slightly more than one success per day.\n\nIt's VERY important to realise that this is the AVERAGE bitcoin creation time, and will only be valid over periods longer than about a week or so.  Because a success event is completely random (I hope, otherwise the hash function is probably not secure and someone will eventually crack it, and therefore bitcoin!), the interval between one success and the next will follow a Poisson distribution with n=0, i.e. an exponential (see wikipedia).  Therefore, with an average rate of, say, 1 success per day, you can expect that roughly 10% of the time, you'll have to wait 2¼ days or more, 1% of the time 4½ days, 0.1% 7 days and so on."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1426#msg1426"},{"f":"theymos","d":1276105303,"b":[["t","Thanks for clearing that up, fergalish!"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1434#msg1434"},{"f":"satoshi","d":1277143757,"b":[["t","I integrated the hashmeter idea into the SVN version.  It displays khash/s in the left section of the status bar.\n\nTwo new log messages:\n21/06/2010 01:23 hashmeter   2 CPUs    799 khash/s\n21/06/2010 01:23 generated 50.00\n\ngrep your debug.log for \"generated\" to see what you've generated, and grep for \"hashmeter\" to see the performance.  On windows, use:\n findstr \"hashmeter generated\" \"%appdata%\\bitcoin\\debug.log\"\n\nI have the hashmeter messages once an hour.  How often do you think it should be?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg1648#msg1648","s":1,"n":132,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/132/"},{"f":"Gavin Andresen","d":1277222686,"b":[["q","How about in the options menu you can turn it off or on, and specify an interval in minutes for how often it should display?","Quote from: davidonpda on June 22, 2010, 02:55:37 PM"],["t","I say keep it simple; more choices isn't always better, it just makes it overwhelming and confusing for most users."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1667#msg1667"},{"f":"satoshi","d":1277225474,"b":[["t","Agree.  Certainly too trivial to clutter the user's attention with.\n\nI changed it to every 30 minutes.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=43.msg1669#msg1669","s":1,"n":137,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/137/"},{"f":"laszlo","d":1279025542,"b":[["t","\"difficulty\" : 45.38582234101263\n\nIt jumped from 23 in a couple days.  I think this pretty much puts an end to generating a block a day with a personal computer.. but you can still get lucky.  Now you'll need to build a cluster or hijack a college computer lab for it to be worth doing Smiley  I expect the trading value will increase significantly over the next few weeks as the supply slows down; should be interesting."]],"u":"https://bitcointalk.org/index.php?topic=43.msg2543#msg2543"},{"f":"theymos","d":1279032119,"b":[["t","The probability of winning per hash went from 9.90701E-12 to 5.12995E-12. So about double the difficulty."]],"u":"https://bitcointalk.org/index.php?topic=43.msg2559#msg2559"},{"f":"gould","d":1279056659,"b":[["t","I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware."]],"u":"https://bitcointalk.org/index.php?topic=43.msg2654#msg2654"},{"f":"Insti","d":1279057773,"b":[["q","I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.","Quote from: gould on July 13, 2010, 09:30:59 PM"],["t","You can use the calculator at: http://www.alloscomp.com/bitcoin/calculator.php\n\nIf this is a feature request post in the Development & Technical Discussion Forum: http://bitcointalk.org/index.php?board=6.0"]],"u":"https://bitcointalk.org/index.php?topic=43.msg2660#msg2660"},{"f":"Insti","d":1279065688,"b":[["t","13/07/2010 0000000005a3f437d4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a7f529fd4a"]],"u":"https://bitcointalk.org/index.php?topic=43.msg2685#msg2685"},{"f":"satoshi","d":1279291572,"b":[["t","The proof-of-work difficulty is currently 45.38.  (see http://www.alloscomp.com/bitcoin/calculator.php) \n\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.\n\nThe target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3488#msg3488","s":1,"n":210,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/210/"},{"f":"Bitcoiner","d":1279291734,"b":[["q","The proof-of-work difficulty is currently 45.38.  (see http://www.alloscomp.com/bitcoin/calculator.php) \n\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.\n\nThe target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.","Quote from: satoshi on July 16, 2010, 02:46:12 PM"],["t","Holy....\n\nSatoshi, what happens if the rush dries up for a bit; some of the slashdotters or whoever get tired? Does the difficulty ever go back down?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg3490#msg3490"},{"f":"knightmb","d":1279292018,"b":[["q","> Quote from: satoshi on July 16, 2010, 02:46:12 PM\n> The proof-of-work difficulty is currently 45.38.  (see http://www.alloscomp.com/bitcoin/calculator.php) \n>\n> It'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.\n>\n> The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.\n\nHoly....\n\nSatoshi, what happens if the rush dries up for a bit; some of the slashdotters or whoever get tired? Does the difficulty ever go back down?","Quote from: Bitcoiner on July 16, 2010, 02:48:54 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3493#msg3493"},{"f":"satoshi","d":1279299414,"b":[["t","It adjusted to 181.54 a few minutes ago.  Typical time to get a block is about a week now.\n\nThe difficulty can adjust down as well as up.\n\nThe network should be generating close to 6 blocks per hour now."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3526#msg3526","s":1,"n":218,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/218/"},{"f":"RudeDude","d":1279299544,"b":[["q","I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware.","Quote from: gould on July 13, 2010, 09:30:59 PM"],["t","I think the web c alc does a good job by showing likelyhoods based on khash speed:\nhttp://www.alloscomp.com/bitcoin/calculator.php\n\nThat way you can see there is no guaranteed time horizon."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3527#msg3527"},{"f":"knightmb","d":1279299552,"b":[["q","It adjusted to 181.54 a few minutes ago.  Typical time to get a block is about a week now.\n\nThe difficulty can adjust down as well as up.\n\nThe network should be generating close to 6 blocks per hour now.","Quote from: satoshi on July 16, 2010, 04:56:54 PM"],["t","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  Wink\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=43.msg3528#msg3528"},{"f":"satoshi","d":1279301368,"b":[["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=43.msg3537#msg3537","s":1,"n":221,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/221/"},{"f":"knightmb","d":1279301637,"b":[["q","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'll know long before that that you won one.","Quote from: satoshi on July 16, 2010, 05:29:28 PM"],["t","So if the difficulty was increased so high that it took a day to find a winning block, that means the lucky winner would have to wait 120 day before they could spend it or about 4 months if everyone else was averaging about the same speed? Seems like at the high end of the difficulty, there is an issue with coin generation vs. being able to put it into circulation by spending. Wouldn't the long delay cause a lot of generated coin to be lost because anything could happen to the PC that won in a long amount of time if the winner had to really wait that long? They might un-install the program or the computer get eaten by a virus or power surge well before then."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3538#msg3538"},{"f":"Bitcoiner","d":1279303744,"b":[["q","> Quote from: satoshi on July 16, 2010, 05:29:28 PM\n> 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'll know long before that that you won one.\nSo if the difficulty was increased so high that it took a day to find a winning block, that means the lucky winner would have to wait 120 day before they could spend it or about 4 months if everyone else was averaging about the same speed? Seems like at the high end of the difficulty, there is an issue with coin generation vs. being able to put it into circulation by spending. Wouldn't the long delay cause a lot of generated coin to be lost because anything could happen to the PC that won in a long amount of time if the winner had to really wait that long? They might un-install the program or the computer get eaten by a virus or power surge well before then.","Quote from: knightmb on July 16, 2010, 05:33:57 PM"],["t","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.\n\nSatoshi or anyone else can correct me if I'm wrong Smiley"]],"u":"https://bitcointalk.org/index.php?topic=43.msg3551#msg3551"},{"f":"satoshi","d":1279305831,"b":[["t","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.\n\nThe recent adjustment put us back to close to 6 blocks per hour again.\n\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"]],"u":"https://bitcointalk.org/index.php?topic=43.msg3565#msg3565","s":1,"n":225,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/225/","qt":["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."],"qc":["difficulty"]},{"f":"knightmb","d":1279307110,"b":[["t","Ah ok, cool. I continue to be astounded by how much thought was put into this system to keep it balanced, nice job!"]],"u":"https://bitcointalk.org/index.php?topic=43.msg3570#msg3570"},{"f":"RHorning","d":1279330292,"b":[["q","Now, 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?","Quote from: knightmb on July 16, 2010, 04:59:12 PM"],["t","No, this isn't correct.  Finding the hash requires a whole bunch of effort, but the process of verification that the \"winner\" has found a matching block is by comparison a trivial exercise and doesn't take all that long.  Once they have found the block, they can spend those coins right away.\n\nWhat this does mean is that the coin allocation system has now become a lottery, where new winners are receiving a block of coins worth a whole lot more (due to exchange rates and scarcity) than earlier blocks which were in comparison relatively trivial in value.  My question is, how valuable will this \"lottery\" become in the long run (in terms of Euros or Dollars per block generated)?\n\nEssentially what is happening is that the computer is picking a random sequence of numbers (like a lottery) and if that computer happens to pick the correct sequence of bits, you \"win\".  The change in difficulty is something akin to playing a lottery that has you only picking six numbers vs. one with fourteen or a hundred numbers to win.  The odds are actually worse for a bitcoin block than even the worst of any normal lottery that has ever been conceived at the moment."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3631#msg3631"},{"f":"ByteCoin","d":1279337732,"b":[["t","In the Economy subforum, I have just written a post titled \"Get rid of 'difficulty' and maintain a constant rate\" which outlines a scheme which a new version of the BitCoin software could use to keep the rate of block generation absolutely constant at the cost of a slight increase in network traffic.\n\nI would be very grateful for your comments.\n\nByteCoin "]],"u":"https://bitcointalk.org/index.php?topic=43.msg3659#msg3659"},{"f":"ichi","d":1279374086,"b":[["t","I value Bitcoin as an anonymous digital currency.  Although I'm not expecting to get rich, I'd like the ability to continuously generate enough Bitcoin to purchase desired services.\n\nIs there any expectation that economic value per khash/sec (or client) per day will be at least somewhat stable?  Difficulty just increased 300%, and USD/Bitcoin just increased about 500% (although that may turn out to be a spike).  I do get that there's no necessary relationship.  However, perhaps there's an economic basis for one (however approximate it might be)."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3740#msg3740"},{"f":"Insti","d":1279374319,"b":[["q","I value Bitcoin as an anonymous digital currency.  Although I'm not expecting to get rich, I'd like the ability to continuously generate enough Bitcoin to purchase desired services.\n\nIs there any expectation that economic value per khash/sec (or client) per day will be at least somewhat stable?  Difficulty just increased 300%, and USD/Bitcoin just increased about 500% (although that may turn out to be a spike).  I do get that there's no necessary relationship.  However, perhaps there's an economic basis for one (however approximate it might be).","Quote from: ichi on July 17, 2010, 01:41:26 PM"],["t","Try the Bitcoin Economics Forum <http://bitcointalk.org/index.php?board=7.0>\nYou should be able to find many discussions about this topic there.\n\nThis thread is about the proof of work difficulty number."]],"u":"https://bitcointalk.org/index.php?topic=43.msg3743#msg3743"},{"f":"satoshi","d":1280199898,"b":[["t","New difficulty factor 244.213223092\n+35%\n\nI updated the first post.\n\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%"]],"u":"https://bitcointalk.org/index.php?topic=43.msg5990#msg5990","s":1,"n":281,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/281/"}]},{"id":"p23","k":"p","s":"bitcointalk","t":"How divisible are bitcoins and other market/economic questions","u":"https://bitcointalk.org/index.php?topic=44","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/23/","m":[{"f":"BlueSky","d":1265449005,"b":[["t","How divisible are bitcoins? Can I divide a bitcoin? as in could I spend 0.5 or 0.01 of a bitcoin?\n\nI ask this question as practically the production of new bitcoins is finite & will become too expensive in terms of time & power in the future and if the system becomes more popular there will be more goods than BC's.\n\nWhat about dwindling supply?\nThe current supply will eventually begin to dwindle as people lose their wallet's(removing coins from the system) & governments attempt to drain coins out (either by scamming or creating coins themselves and simply hoarding them)of the system. This is inevitable (government action against BC) as no government worldwide will allow the existence of such an anonymous currency system out of their control or supervision.\n\nWhat about the need for banks?\nActually I don't think there would be a need for banks to get interest on savings, simply holding onto BC's they will increase in value as more users come into the system. So technically you'll get interest just for keeping them under your bed.\n\nHow are BC's valued(this is more of a question for NewLibertyStandard)?\n\nAs I see it(thusfar) the value of bitcoins(as in their exchange rate or the goods they can buy) is not in how much energy/time it takes to create them (this simply ensures a limited supply) but that they are accepted for goods & services.\n\nThe more goods & services that can be bought with BC the less coins it will require per good.\n\nFor example there are 2 Million BC in existence, and only one person accepts BC, & is willing to sell a single t-shirt. Then the BC value of that shirt is 2Million BC, if it we're 2 t-shirts then each shirt would cost 1Million and so forth.\n\nOf coarse this may never happen exactly like this, a person would look at the electricity cost of making 2Million BC's(in lets say US$) and the cost of buying the t-shirt(again in US$). If it costs $100 of electricity to make 2Million BC's then of coarse the customer will just use US$ and pay $10 for the t-shirt.\n\n "]],"u":"https://bitcointalk.org/index.php?topic=44.msg252#msg252"},{"f":"NewLibertyStandard","d":1265458867,"b":[["t","Bitcoins are divisible by 100. So when you generate ฿50.00, you are getting 5000 bitcoin cents.\n\nThe New Liberty Standard Exchange Rate <http://newlibertystandard.wetpaint.com/page/Exchange+Rate> includes an explanation of how it is calculated. BlueSky, how much are you willing to sell your bitcoins for and how much are you willing to pay for someone else's bitcoins?\n\nBitcoins can be lost, but for the foreseeable future there will continue to be more than enough bitcoins available to keep playing the game.\n\nEach person is their own bank. Although I suppose that if a friend of mine wanted to buy some bitcoins and didn't have a computer or Internet, I wouldn't mind keeping track of their balance."]],"u":"https://bitcointalk.org/index.php?topic=44.msg254#msg254"},{"f":"BlueSky","d":1265462799,"b":[["t","That is pretty divisible(enough for the moment), which means that ฿ serves all the functions of money- \"Money is a matter of functions four, a medium, a measure, a standard, a store.\" That is, money functions as a medium of exchange, a unit of account, a standard of deferred payment, and a store of value.\"-wikipedia\n\nI must thank Satoshi for his work (although the groundwork was done during the 80's, algorythms etc. this is the first useful implementation and it's effects are profound).\n\nI live in PRChina, combining Freenet, Tor, I2P there is the framework for free,anonymous discussion and transfer of information(something that is prevented here, sometimes with serious penalties). Add to this BitCoin and we now have an underground market free from the tyrany and scrutinising eye of the state. This will allow an alternative, free China to develope under the nose of the state machinery.\n\nMy understanding is that Bitcoin cannot be suppressed without suppressing the internet as a whole, is this correct?\n\nI would like to give Satoshi a donation, but sadly R&B(ReminBi, literally \"The Peoples Money\") is not a world traded currency and sending a payment in a foreign currency is expensive & complicated. If I could give a gift, to a value of R&B500(about $70US)? Or if wished open a currency exchange for ฿/R&B?\n\nOne thing I will do is have some computer science students translate the application to Chinese, after Spring Festival.\n\nNewLiberty-\nThe lazy way would be for me to peg my exchange rate to yours and let you do the calculations. Otherwise I would need to know the total amount of ฿ in circulation and the amount of goods that can be purchased with it(this is a Austrian economist view of measuring the value I think?), just what is the amount in circulation?\n\nWhat do you mean \"keep playing the game\"?\n\nAlso, what do you sell more, ฿ or $US?"]],"u":"https://bitcointalk.org/index.php?topic=44.msg255#msg255"},{"f":"BitcoinFX","d":1265469135,"b":[["q","...Otherwise I would need to know the total amount of ฿ in circulation and the amount of goods that can be purchased with it(this is a Austrian economist view of measuring the value I think?), just what is the amount in circulation? ...","Quote from: BlueSky on February 06, 2010, 01:26:39 PM"],["t","From the FAQ:\n\nHow are new Bitcoins created?\n\nNew coins are generated by a network node each time it finds the solution to a certain calculational problem (i.e. creates a new block), for which an average solution time can be calculated. The difficulty of the problem is adjusted so that in the first 4 years of the Bitcoin network, 10,500,000 coins will be created. The amount is halved each 4 years, so it will be 5,250,000 in years 4-8, 2,625,000 in years 8-12 and so on. Thus the total number of coins will approach 21,000,000 over time.\n\nWhat's the current total amount of Bitcoins in existence?\n\nThe number of blocks times the coin value of a block. The coin value is 50 bc per block for the first 210,000 blocks, 25 bc for the next 210,000 blocks, then 12.5 bc, 7.25 bc and so on.\n\nAs of October 30th 2009, there are about 26,000 blocks in the block chain, which means 26,000 * 50 bc = 1,300,000 bitcoins in existence. You can see the up-to-date number of blocks in the status bar of the Bitcoin main window.\n\nCurrent Block count as of 06th Feb. 2010 - 3.15 PM - GMT is 38,660 blocks. You can do the math Cool"]],"u":"https://bitcointalk.org/index.php?topic=44.msg257#msg257"},{"f":"Suggester","d":1265480715,"b":[["q","What about dwindling supply?\nThe current supply will eventually begin to dwindle as people lose their wallet's(removing coins from the system) & governments attempt to drain coins out (either by scamming or creating coins themselves and simply hoarding them)of the system. This is inevitable (government action against BC) as no government worldwide will allow the existence of such an anonymous currency system out of their control or supervision.","Quote from: BlueSky on February 06, 2010, 09:36:45 AM"],["t","That's an excellent point. If this occurs, it might be a good idea to remove or extend the 21M million limit in later versions and freeze the difficulty of generating new coins (by not making it exceedingly difficult to make new ones). Granted, BTC will not be an excellent investment as it is now (because currently we expect its price to multiply in the future), but then again if it turned out to be that popular, the \"investment\" incentive will not be the main reason people are rushing to use it."]],"u":"https://bitcointalk.org/index.php?topic=44.msg260#msg260"},{"f":"BlueSky","d":1265483311,"b":[["t","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.\n\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.\n\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)\n\nI am wondering Satoshi, what would be the technical difficulty of implementing  ฿ as 0.000(or more zeroes) instead of 0.00?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=44.msg263#msg263"},{"f":"satoshi","d":1265498753,"b":[["t","Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=44.msg267#msg267","s":1,"n":46,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/46/","qt":["Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\n\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.","If 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."],"qc":["bitcoin-design","bitcoin-economics"]}]},{"id":"p24","k":"p","s":"bitcointalk","t":"Make your \"we accept Bitcoin\" logo","u":"https://bitcointalk.org/index.php?topic=45","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/24/","m":[{"f":"sirius","d":1265534876,"b":[["t","Everyone open your graphics editor and make a \"we accept Bitcoin\" logo. A good looking logo (preferably better than mine Tongue) would be really useful.\n\nMy first version attached."]],"u":"https://bitcointalk.org/index.php?topic=45.msg272#msg272"},{"f":"giik","d":1265569956,"b":[["t","I took a shot. Small, clean \"btc accepted\" sign. See attached file."]],"u":"https://bitcointalk.org/index.php?topic=45.msg275#msg275"},{"f":"giik","d":1265570059,"b":[["q","Everyone open your graphics editor and make a \"we accept Bitcoin\" logo. A good looking logo (preferably better than mine Tongue) would be really useful.","Quote from: sirius-m on February 07, 2010, 09:27:56 AM"],["t","Is there a high-res bitcoin logo? Or a vector-image?"]],"u":"https://bitcointalk.org/index.php?topic=45.msg276#msg276"},{"f":"satoshi","d":1265592149,"b":[["t","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.\n\nThe best 16x16 with full alpha channel is in src/rc/bitcoin.ico.  I don't like the 32x32 version.\n\nI'm attaching bitcoin20x20.png, the 20x20 version with full transparency."]],"u":"https://bitcointalk.org/index.php?topic=45.msg278#msg278","s":1,"n":47,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/47/"},{"f":"giik","d":1265660579,"b":[["t","This one is inspired on the PayPal, secure payments logo."]],"u":"https://bitcointalk.org/index.php?topic=45.msg286#msg286"},{"f":"giik","d":1265660683,"b":[["t","A simple \"we accept Bitcoin\" image."]],"u":"https://bitcointalk.org/index.php?topic=45.msg287#msg287"},{"f":"BitcoinFX","d":1265727866,"b":[["t","Thank you for these sirius-m, giik and all future contributors. I might have ago at producing a logo myself.\n\nIs this a logo contest ? How many Bitcoins for the Winner ? Grin\n\nPerhaps anyone who adopts a contributors logo for their website might consider a Bitcoin donation to it's creator(s) ! Cool"]],"u":"https://bitcointalk.org/index.php?topic=45.msg293#msg293"},{"f":"giik","d":1266949063,"b":[["t","A bitcoin image in the shape of a credit card. Inspired by the Me.com account payment page."]],"u":"https://bitcointalk.org/index.php?topic=45.msg447#msg447"},{"f":"Sabunir","d":1266984905,"b":[["t","I attempt a contribution:\n\nEDIT) This is old version. Design has been updated <http://bitcointalk.org/index.php?topic=45.msg479#msg479>.\n\nImage original is saved as proprietary vector format, can be resized without loss of quality. Bitcoin graphic had to be remade by myself as vector. I will accept and may implement suggestions."]],"u":"https://bitcointalk.org/index.php?topic=45.msg473#msg473"},{"f":"BitcoinFX","d":1266985796,"b":[["t","Quality and fantastic Sabunir ! I really like them.\n\nSuggestions:\n\n(1) The background 'fade' effect somewhat detracts from the text in the smaller versions of the logo. Almost making it unreadable (tricky one as I realize it's taken from the website header)\n\n(2) Maybe a mention of 'P2P'. Maybe not...\n\n(3) Embossed blue / dark blue outline ?\n\nI'd be happy to pay to use the logo's (I have already sent giik a token 100BTC donation) Grin"]],"u":"https://bitcointalk.org/index.php?topic=45.msg475#msg475"},{"f":"Sabunir","d":1266988234,"b":[["t","Good ideas. Updated:\n\nThese may be used freely by all, but I will graciously accept donations: 1BHtsCnpmTvpgJEP7eMKEVhpJFunxSM8vq\n\nEDIT) Added smaller versions, inspired by Ensayia's submission."]],"u":"https://bitcointalk.org/index.php?topic=45.msg479#msg479"},{"f":"Ensayia","d":1266991023,"b":[["t","http://dl.dropbox.com/u/3713850/Untitled-1.png\n\nTook a crack at a very basic low-profile icon.\n\nEDIT\n\nLet me try that again...\n\nhttp://dl.dropbox.com/u/3713850/bclarge.png\n\nhttp://dl.dropbox.com/u/3713850/bcsmall.png\n\nI like these a lot better!"]],"u":"https://bitcointalk.org/index.php?topic=45.msg480#msg480"},{"f":"The Madhatter","d":1266993625,"b":[["t","Am I to understand that these graphics are public domain?"]],"u":"https://bitcointalk.org/index.php?topic=45.msg486#msg486"},{"f":"Ensayia","d":1266993719,"b":[["t","In what way, madhatter2?\n\nAs in you can take them and use them wherever? For mine I don't care, use it how you like, just try to give credit if possible."]],"u":"https://bitcointalk.org/index.php?topic=45.msg487#msg487"},{"f":"Sabunir","d":1266994925,"b":[["t","Public domain? No. My images are Copyleft <http://www.gnu.org/copyleft/>, to myself (satoshi or any other Bitcoin developers can have the rights to these images, upon request). In practice, Copyleft works almost the same as public domain. You are completely free to use, share, or modify my images. If you do, please consider listing me in your credits or donating an amount of coins to me, but this isn't required."]],"u":"https://bitcointalk.org/index.php?topic=45.msg489#msg489"},{"f":"sirius","d":1267017889,"b":[["t","Thanks, these are getting to look good."]],"u":"https://bitcointalk.org/index.php?topic=45.msg497#msg497"},{"f":"BitcoinFX","d":1267027640,"b":[["t","wow ! Yeah looking really good Cool\n\nAs well as GNU GPL why not attach a Creative Commons License http://creativecommons.org/ to them. You can reference the project address and request a Bitcoin donation for their reproduction. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=45.msg499#msg499"},{"f":"Sabunir","d":1267034434,"b":[["t","I am not that picky. Growth of the Bitcoin network and promoting more widespread usage is sufficient reward to me."]],"u":"https://bitcointalk.org/index.php?topic=45.msg501#msg501"},{"f":"satoshi","d":1267048432,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=45.msg507#msg507","s":1,"n":76,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/76/"}]},{"id":"p25","k":"p","s":"bitcointalk","t":"Simple to implement feature requests","u":"https://bitcointalk.org/index.php?topic=46","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/25/","m":[{"f":"BlueSky","d":1265619602,"b":[["t","First request:\nOptional connect to IP dialog.\n\nExplanation:\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).\n\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.\n\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.\n\nAdding this feature will allow Bitcoin to function despite regime efforts to prevent it."]],"u":"https://bitcointalk.org/index.php?topic=46.msg281#msg281"},{"f":"satoshi","d":1265647044,"b":[["t","There are command line options:\n\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)\n\nYou can use more than one of these, for instance\nbitcoin -connect=(first to try) -connect=(next to try) ...\n\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.\n\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:\n\nbitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216"]],"u":"https://bitcointalk.org/index.php?topic=46.msg284#msg284","s":1,"n":50,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/50/"}]},{"id":"p26","k":"p","s":"bitcointalk","t":"Bitcoin client and website translation","u":"https://bitcointalk.org/index.php?topic=47","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/26/","m":[{"f":"satoshi","d":1265592422,"b":[["t","Thank you for the offer to help translate.  That is probably the best way you could help.\n\nI will need to prepare the code for translation first.  wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard.  We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support.  I've done test builds with 2.9.0 and there is one bug left to fix.\n\nWhat operating system are you using?  Windows, Linux 32-bit or 64 bit?\n\nSplit from another thread <https://www.bitcoin.org/smf/index.php?topic=44>.\nsirius-m"]],"u":"https://bitcointalk.org/index.php?topic=47.msg279#msg279","s":1,"n":48,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/48/"},{"f":"BlueSky","d":1265618828,"b":[["t","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).\n\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?)."]],"u":"https://bitcointalk.org/index.php?topic=47.msg280#msg280"},{"f":"satoshi","d":1265645437,"b":[["t","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.\n\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.\n\nOn Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=47.msg283#msg283","s":1,"n":49,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/49/"},{"f":"giik","d":1265657308,"b":[["q","Thank you for the offer to help translate.  That is probably the best way you could help.","Quote from: satoshi on February 08, 2010, 01:27:02 AM"],["t","I'm willing to help you translate to Dutch. Just let us know, when it's possible!"]],"u":"https://bitcointalk.org/index.php?topic=47.msg285#msg285"},{"f":"SmokeTooMuch","d":1265664961,"b":[["t","I can translate it into German, if you wish."]],"u":"https://bitcointalk.org/index.php?topic=47.msg288#msg288"},{"f":"sirius","d":1265731719,"b":[["t","You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too."]],"u":"https://bitcointalk.org/index.php?topic=47.msg298#msg298"},{"f":"riX","d":1265748478,"b":[["q","[...]JSON-RPC and command line support[...]","Quote from: satoshi on February 08, 2010, 04:10:37 PM"],["t","Sweet! I've been looking for something to make some kind of semi-cloud setup, and JSON-RPC looks promising. Keep up the good work!"]],"u":"https://bitcointalk.org/index.php?topic=47.msg302#msg302"},{"f":"SmokeTooMuch","d":1265751213,"b":[["q","You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too.","Quote from: sirius-m on February 09, 2010, 04:08:39 PM"],["t","Do you want it as plain-text or a .html or .php file ?"]],"u":"https://bitcointalk.org/index.php?topic=47.msg303#msg303"},{"f":"sirius","d":1265814707,"b":[["q","> Quote from: sirius-m on February 09, 2010, 04:08:39 PM\n> You can send me translations of the bitcoin.org site as private messages (or if it's too long, I'll pm you my e-mail address). If you can translate only the front page, it's ok too.\nDo you want it as plain-text or a .html or .php file ?","Quote from: SmokeTooMuch on February 09, 2010, 09:33:33 PM"],["t","Plain text is good, but add the heading and list html tags if possible."]],"u":"https://bitcointalk.org/index.php?topic=47.msg308#msg308"},{"f":"NewLibertyStandard","d":1265825705,"b":[["t","It looks like the Bitcoin Wikipedia article <http://en.wikipedia.org/wiki/Bitcoin> is only available in English. How about some of you either translate or write a new article in your language."]],"u":"https://bitcointalk.org/index.php?topic=47.msg309#msg309"},{"f":"giik","d":1266315785,"b":[["t","My Dutch translation is almost finished. I will send it to sirius-m this week."]],"u":"https://bitcointalk.org/index.php?topic=47.msg374#msg374"},{"f":"satoshi","d":1266434383,"b":[["t","I updated the SVN with changes to support translation.  Translatable strings are all enclosed in _(\"\"), and we're using UTF-8 on all platforms.\n\nWhen the program runs, it looks in the directory of the EXE for the file: locale\\<langcode>\\LC_MESSAGES\\bitcoin.mo\n\n<langcode> is the two letter code of the language your OS is set to, like \"de\" or \"nl\".\n\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?)\n\nHere's a quick walkthrough using poedit to make a .po and .mo file:\n\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\n\nWhen you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program)."]],"u":"https://bitcointalk.org/index.php?topic=47.msg389#msg389","s":1,"n":62,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/62/"}]},{"id":"p27","k":"p","s":"bitcointalk","t":"What's with this odd generation?","u":"https://bitcointalk.org/index.php?topic=48","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/27/","m":[{"f":"theymos","d":1265826700,"b":[["t","I thought BitCoin only generated in 50 coin increments, but I got 50.44 here.\n\n <http://static/img695.imageshack.us/i/generate1.png/>"]],"u":"https://bitcointalk.org/index.php?topic=48.msg310#msg310"},{"f":"SmokeTooMuch","d":1265828777,"b":[["t","had the same a while ago with 50.26"]],"u":"https://bitcointalk.org/index.php?topic=48.msg311#msg311"},{"f":"BitcoinFX","d":1265907470,"b":[["t","That is odd !?! I've currently only had 50.00 generations myself.  Huh"]],"u":"https://bitcointalk.org/index.php?topic=48.msg313#msg313"},{"f":"satoshi","d":1265944088,"b":[["t","There's a small transaction fee for very large transactions.  The node that generates the block that contains the transaction gets the fee.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=48.msg316#msg316","s":1,"n":52,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/52/"},{"f":"theymos","d":1265963512,"b":[["q","There's a small transaction fee for very large transactions.  (usually over 10,000 bc)  The node that generates the block that contains the transaction gets the fee.\n\nThe fee is based on the KB size of the transaction and intended to compensate the network for the resources used to process it.\n\nIf the same money gets sent again, it won't incur the fee again because it'll be small.  The first time they're bundling hundreds of 50 bc coins together.  After that it's just one line to send the combined unit.","Quote from: satoshi on February 12, 2010, 03:08:08 AM"],["t","Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)? Why couldn't someone just send 1000 small transactions to bypass fees?"]],"u":"https://bitcointalk.org/index.php?topic=48.msg318#msg318"},{"f":"SmokeTooMuch","d":1265980269,"b":[["t","why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!"]],"u":"https://bitcointalk.org/index.php?topic=48.msg319#msg319"},{"f":"riX","d":1265985075,"b":[["q","Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)? Why couldn't someone just send 1000 small transactions to bypass fees?","Quote from: theymos on February 12, 2010, 08:31:52 AM"],["t","You could, but you'd have to wait for one block to be generated between each one of them."]],"u":"https://bitcointalk.org/index.php?topic=48.msg320#msg320"},{"f":"satoshi","d":1266128883,"b":[["q","Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)?","Quote from: theymos on February 12, 2010, 08:31:52 AM"],["t","Yes."],["q","why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!","Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM"],["t","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.\n\nThe average transaction, and anything up to 500 times bigger than average, is free.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=48.msg327#msg327","s":1,"n":56,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/56/","qt":["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."],"qc":["fees","mining","nodes"]},{"f":"theymos","d":1266137337,"b":[["t","Is the fee enough to always ensure the profitability of running a node, even when BitCoin generation stops being profitable?"]],"u":"https://bitcointalk.org/index.php?topic=48.msg328#msg328"},{"f":"satoshi","d":1266162743,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=48.msg329#msg329","s":1,"n":57,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/57/","qt":["I'm sure that in 20 years there will either be very large transaction volume or no volume.","In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes."],"qc":["bitcoin-economics","fees"]}]},{"id":"p28","k":"p","s":"bitcointalk","t":"DEB Package?","u":"https://bitcointalk.org/index.php?topic=49","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/28/","m":[{"f":"nphyx","d":1265934695,"b":[["t","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.\n\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 Smiley"]],"u":"https://bitcointalk.org/index.php?topic=49.msg314#msg314"},{"f":"satoshi","d":1265941982,"b":[["t","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\n\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.\n\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.\n\nI know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine."]],"u":"https://bitcointalk.org/index.php?topic=49.msg315#msg315","s":1,"n":51,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/51/"},{"f":"satoshi","d":1265990257,"b":[["q","If you want, I can provide you with a precompiled binary.","Quote from: soultcer on February 12, 2010, 02:31:50 PM"],["t","Am I missing something?  Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=49.msg322#msg322","s":1,"n":53,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/53/"},{"f":"nphyx","d":1266020704,"b":[["t","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 Smiley"]],"u":"https://bitcointalk.org/index.php?topic=49.msg325#msg325"},{"f":"satoshi","d":1266025117,"b":[["t","I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either.\n\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\nThere's one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason.  -- fixed\n\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.\n\nThe SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010.\n\nHopefully they'll have a wxWidgets 2.9.0 debian package someday."]],"u":"https://bitcointalk.org/index.php?topic=49.msg326#msg326","s":1,"n":55,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/55/"}]},{"id":"p29","k":"p","s":"bitcointalk","t":"Setting up multiple bitcoin machines behind NAT","u":"https://bitcointalk.org/index.php?topic=54","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/29/","m":[{"f":"foobar","d":1266280525,"b":[["t","Hello,\n\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.\n\nOr is there an other way one should go?\n\nGreetings,\nfoobar"]],"u":"https://bitcointalk.org/index.php?topic=54.msg359#msg359"},{"f":"satoshi","d":1266284096,"b":[["t","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)\n\nIf you want, as a small optimization, you could run the rest of your computers as:\nbitcoin -connect=<the IP of the first computer>\n\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.\n\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>"]],"u":"https://bitcointalk.org/index.php?topic=54.msg360#msg360","s":1,"n":59,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/59/"},{"f":"Xunie","d":1270757197,"b":[["q","Right now there isn't a port number setting to do that.  It's a feature yet to be implemented.","Quote from: satoshi on February 16, 2010, 01:34:56 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=54.msg877#msg877"},{"f":"satoshi","d":1274054163,"b":[["t","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.\n\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.\n\nIf you have many computers, then using the -connect switch on most of them to connect locally makes more sense."]],"u":"https://bitcointalk.org/index.php?topic=54.msg1135#msg1135","s":1,"n":103,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/103/"}]},{"id":"p30","k":"p","s":"bitcointalk","t":"URI-scheme for bitcoin","u":"https://bitcointalk.org/index.php?topic=55","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/30/","m":[{"f":"ec","d":1266353502,"b":[["t","Hi, intrigued by the bitcoin-system, I have an idea:\n\nThe bitcoin addresses could be improved by implementing an URI-scheme <http://en.wikipedia.org/wiki/URI_scheme> like e.g. torrent magnet links <http://en.wikipedia.org/wiki/Magnet_URI_scheme>.\n\nSo instead of 1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, we could more unambiguous say bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ, and even configure browsers to redirect clicks on such links to a bitcoin client. This would allow one to implement \"donate buttons\" on homepages, \"pay buttons\" on webshops etc.\n\nIf an IP should be included, URIs allow this as bitcoin://HOST_OR_IP:PORT?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ. If wanted an amount could be specified as bitcoin:?amount=42.00;addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ (of course for the user to verify in the secure bitcoin-client).\n\nJust my 0.02 ฿ (return them to bitcoin:?addr=1Nu6wZC7JSuh6h8nfKkSTZ4kp9U4f83hhZ if you don't like them Wink)"]],"u":"https://bitcointalk.org/index.php?topic=55.msg377#msg377"},{"f":"ec","d":1266354580,"b":[["t","An URI-scheme could also be of use for implementing a mobile wallet with QR-codes <http://en.wikipedia.org/wiki/QR_Code>, so that your buddy who wants to pay you X bitcoins don't have to enter your bitcoin-address manually, but only need to photograph the screen of your mobile phone."]],"u":"https://bitcointalk.org/index.php?topic=55.msg378#msg378"},{"f":"The Madhatter","d":1266979075,"b":[["t","Yeah, I had totally thought of that too. A magnet link scheme would be awesome. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=55.msg462#msg462"},{"f":"satoshi","d":1266991063,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=55.msg481#msg481","s":1,"n":73,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/73/","qt":["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."],"qc":["transactions"]},{"f":"The Madhatter","d":1266993556,"b":[["t","That would be so awesome... Smiley"]],"u":"https://bitcointalk.org/index.php?topic=55.msg484#msg484"},{"f":"Karmicads","d":1272694013,"b":[["t","I'm wondering if anybody is doing anything about this idea, as I have been researching the possibility of implementing some Internet browser functionality, as per this thread <http://'http://bitcointalk.org/index.php?topic=123.0> and the wonderful developments described here. <http://'http://bitcointalk.org/index.php?topic=63.0> It seems that it may be easier first steps, (I'm learning as I go) to try this out and include it with whatever other features the Firefox add-on evolves.\n\nBefore this can happen there needs to be a consensus about what form the URI would take. I have done some quick research on the URI schemes and most approaches are frowned upon without W3C approval, there is one category whereby the W3C approves a tentative URI scheme and holds it in reserve, with no guarantees (like a provisional patent), but by far the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address. Magnet was intended for use by applications on peer to peer networks and has reserved parameters for reference to application specific data. Basically, you simply preface the application specific parameter with an x as in xbitcoin1:?\n\nMaybe it is good, not to try implementing a new top level URI scheme, as it is regarded as an ad lib maneuverer, if it is not recognized universally. Adopting the magnet system would avoid this, but in itself magnet is an informal, unregistered scheme. The beauty of magnet is that it can be shared and is open in that sense.\n\nNow, that might all seem very good, because bitcoin is after all a P2P application and it's network does operate on similar principals, but what if the person clicking on the link is not a bitcoin user? What if you want to incorporate some information that is not carried in the existing network, such as the article being sold, shipping information and various other issues. My understanding is that bitcoin only handles the transaction itself, so the user is left to make all other arrangements, contracts and communications independent of bitcoin. Here's where the anonymity is compromised, because here, we are inclined to resort to conventional 'hierarchical  hardwired, or non-anonymous technologies. That's not a criticism of bitcoin by any stretch, because bitcoin is a fantastic way to transact, no question about it. But the transaction is only one side of the coin, if you'll pardon that cheesy pun. Grin\n\nIn the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. Given that freenet is a user/identity-space intended for information storage, couldn't it also be used as a repository of human readable data files, particular and unique to each user, and incorporating any format of data you wish to use, for embellishing your transaction? Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.\n\nThis should keep everything under the same kind of cryptographic P2P infrastructure, and allow infinite diversity of application specific context. I suppose a unique URI hash key, could be borne out of the combination of your freenet+bitcoin hashes and the file encrypted with your freenet key found by decrypting with your bitcoin key, while your bitcoin node can be addressed the other way around. Does that sound right? Of course, if you use your real identity on one, then I guess then, you real identity would be divulged on the other.\n\nAnyhow, I'm sure there's some way to do it. Again, freenet also uses an unregistered URI scheme, but if a variant of magnet is adopted, that will not be a problem. The question remains, if people have hopes of bitcoin becoming a formal recognized currency and a very legitimate deal, then the strict adherence to all other internet protocols might be advisable. I have noted so far nothing in particular that would prevent the registration of a magnet/freenet like URI scheme. I haven't searched them all but one may even exist. Otherwise why not register one?\n\nSo the URI scheme needs to be agreed upon as to the classification (i.e. what kind magnet etc, as well do we go legit/formal or not) and format, such as how it is to be laid out:\n\nComponents Of A URI\n\nThis speaks to the conventions that Mozilla will account for in parsing a URI.\n\nA typical magnet URI, looks like this\n\nmagnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C\n\nA freenet URI is like this:\n\nhttp://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf\n\nTo be recognized at all, the freenet program needs to be installed and this includes a Java powered web server that recognizes the resource as an item in identity space of the localhost. i.e. my browser sees the whole of freenet as being on my machine. I don't know if this identity space could be addressable without the user having to run a web-server, but I suspect the server is only for the ability to serve web pages as well as recognition of the localhost as the requisite top level domain. The 'http:' indicates that the freenet URI, is nothing special in itself, but the IP address (localhost) certainly is. I suspect a program can address the freenet user space, without incorporating a web server, and the universal links can be made as magnet URIs. As for those who don't have bitcoin installed, I don't know how the URI could be made to have a default fall back, to redirect visitors of that link. to the Sourceforge download for bitcoin. That may need to implemented in code and cookie or environ variable set to record the presence of bitcoin.\n\nOther relevant sites I have visited in the course of this research include:\n\n• http://infomesh.net/2001/09/urischemes\n\n• http://www.search.com/reference/Magnet:_URI_scheme\n\n• http://magnet-uri.sourceforge.net/\n\n• http://magnet-uri.sourceforge.net/magnet-draft-overview.txt\n\n• http://www.w3.org/Addressing/schemes\n\n• http://www.w3.org/Addressing/schemes#Registration\n\nAny ideas/comments/feedback is/are welcome.  Wink\nSteve"]],"u":"https://bitcointalk.org/index.php?topic=55.msg1038#msg1038"},{"f":"D҉ataWraith","d":1272721237,"b":[["q","Before this can happen there needs to be a consensus about what form the URI would take. [snip] ...the most suitable scheme, seems to be the magnet URI, which was designed to find a resource by the hash being a product of its content uniqueness, rather than by specific address.\n[snip]The beauty of magnet is that it can be shared and is open in that sense.","Quote from: Karmicads on May 01, 2010, 06:06:53 AM"],["t","I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages. Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.). Bitcoin would have to rely on application-specific xBitcoin-parameter(s), and since we probably don't want to mix files with bitcoin transactions in a single link, there's no really compelling reason not to use our own, seperate format, especially since magnet-links aren't officially recognized either."],["q","In the process of investigating URI's I was reminded of freenet and the magnet like system they use, and I ended up back there checking it out. [snip] Couldn't this be used for hooking the URI into a rich database of application specific data, that has been designed for the publishers own website functionality or business system? While your bitcoin node takes care of the actual transaction, the freenet node takes care of the individual data presented.","Quote"],["t","Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.\n\nHowever, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):\n\n• address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.\n\n• amount (optional): The amount to send.\n\n• message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)\n\n• details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1039#msg1039"},{"f":"Karmicads","d":1272766551,"b":[["t","This just in:...\n\nIt seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin\n\nSorry, I'm not assuming that we must agree on the freenet URI functionality I suggested, just that It is exciting that it can be so readily incorporated, even for experimental purposes. Simply addressing a preconfigured freenet server should do the trick, but perhaps even the existing code can be slightly modified to directly address freenet (without the implicit web server included in the proper freenet install), but by including this FCP code, in the browser add-on, just the addressing and communicating functionality may be incorporated without the overhead of a full blown freenet http server. I assume at this point, the freenet web server, is only needed by the client for browsing freenet, not to service a node. As Bitcoin already addresses a similar P2P network, how hard would it be to make the bitcoin server do freenet inquiries? Could such trickery be included in the JSON intreface?\n \nFrom: http://new-wiki.freenetproject.org/FCPv2"],["q","Purpose\n\nThe Freenet Client Protocol is a simple, text-based protocol designed to allow third-party applications to interact with Freenet. Supported functionality includes:\n\n    * Inserting of data into Freenet\n    * Retrieval of data from Freenet\n    * Querying the status of Freenet\n    * Managing the other Freenet nodes that are connected to your own node.","Quote"],["t","So, it seems you can pull data out of and post data into freenet at will.\nVeeeeery interesting indeed.\n\nAside from that, in the course of looking for proxies or workarounds for freenet URI integration, I believe I solved an unrelated problem to do with my ISP blocking VoIP/SIP (as it's the local telco as well - and yes, I am changing providers very soon). I want VoIP, but my bastard anti-competitive ISP has crippled my modems firmware (which has an inbuilt 2 port analogue telephone adapter), and I hope this work around (Tor) gets past it (I'm not holding my breath) but  Link2VoIP, if you are reading this, I'm looking in your direction.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=55.msg1041#msg1041"},{"f":"Karmicads","d":1272784074,"b":[["t","Hi DataWraith"],["q","I think that using magnet-links just because they are already somewhat popular does not outweigh the disadvantages.","Quote"],["t","I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity. I'm honestly not into superficial popularity if I can help it. The reason to consider a magnet URI IMHO is owing to the Actual stated purpose and draft specifications <http://magnet-uri.sourceforge.net/magnet-draft-overview.txt>"],["q","MAGNET is a work-in-progress URI specification, and collection\nof standard practices/implementing code to allow a website to\nseamlessly integrate with features made available by local\nutility programs. In one way, it could be thought of as a\nvendor- and project-neutral generalization of the \"freenet:\"\nand \"ed2k:\" URI-schemes used by the Freenet and EDonkey2000\npeer-to-peer networks, respectively.","Quote"],["t","It's stated purpose is specifically to allow websites to seamlessly integrate with features of local utility programs. It is intended to be vendor neutral and avoid having to reinvent the wheel and avoid further conflicts with other URI schemes. It also follows strong compliance with W3C standards and any scheme using the magnet convention would inherit that rigor."],["q","NOTES ABOUT THE URI FORMAT:\n\n  - Yes, it looks a little strange to have the \"?\" right after\n    the \":\", but by my reading of the relevant URL/URI RFCs,\n    that fits the recommended common URI syntax well. (It also\n    meshes nicely with the way the parameters are passed on to\n    individual local apps.)\n\n  - FYI, EDonkey URIs violate many provisos of RFCs 1738 and\n    2396, including the use of \"//\" at the front of a non-\n    hierarchical namespace and the use of illegal/disfavored\n    (when not escaped) characters\n\n  - Parameter names and values should officially be www-\n    formencoded, just like HTTP web form GET submissions in the\n    query-string, though in practice some characters that a\n    strict reading of HTML-specs/RFC1738 would suggest should be\n    encoded (like '.' and ':') seem not to be encoded.\n\n  - The prefix 'x.' is reserved for application-specific new\n    parameter experimentation. Any parameters not beginning 'x.'\n    are only to be defined by official MAGNET specifications.\n\n  - Other potential parameters might include a \"fallback-\n    location\" for content that can't be found via P2P, P2P-\n    system-specific identifiers (ed2k, sig2dat, freenet), other\n    topic qualifiers (\"length\"), etc. These remain to be\n    designed; comments wanted.","Quote"],["q","Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).","Quote"],["t","Sorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application."],["q","MAGNET URIS, ILLUSTRATED BY EXAMPLE:\n\n(1)\n\n  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C\n\nmeaning: show me options pertaining to the \"exact topic\" (xt)\ngiven by the supplied URI (specifically, an URN)\n\n(2)\n\n  magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&dn=Great+Speeches+-+Martin+Luther+King+Jr.+-+I+Have+A+Dream.mp3\n\nmeaning: show me options about this exact topic, but use\nthe included (unverified) \"display name\" for user convenience\n\n(3)\n\n  magnet:?kt=martin+luther+king+mp3\n\nmeaning: show me options about the \"keyword topic\" (kt)\ngiven by the string\n\n(4)\n\n  magnet:?xt.1=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C&xt.2=urn:sha1:TXGCZQTH26NL6OUQAJJPFALHG2LTGBC7\n\nmeaning: show me options about the two exact topics given\n\n(5)\n\n  magnet:?mt=http://weblog.foo/all-my-favorites.rss\n\nmeaning: show me the options for the \"manifest topic\" (mt)\nfetchable via the given URI. This could also be an URN.\nManifest topics include lists of other items.","Quote"],["q","Woah! Going from a lightweight URL-handler that brings up the Bitcoin client to requiring Freenet is a bit of a leap. This really should be optional.","Quote"],["t","Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it. I would be more concerned with robustness and not being painted into a corner myself. The effort to implement backward compatibility and forward extensibility, having been considered from the outset, is a small price IMHO. In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed. Also the URI should of course include this freenet functionality, as an optional parameter. So if not specified, the information to do the basic transaction would still be legitimate. It would not then be compulsory to use in publishing the URI, but the handler should still be able to take the parameter if it is used, otherwise the optional choice you are proposing is between two different incompatible URI schemes. Measure twice, cut once."],["q","However, it really would be very nice to add additional information to a transaction. Building on ec's initial post, and the need for further details, I think we should have the following url parameters (or shorter versions of them):\n\n    * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.\n    * amount (optional): The amount to send.\n    * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)\n    * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.","Quote"],["t","Not sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.\n\nThe amount: Yup goes without saying.\n\nMessage: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. The need to reference a supplementary document begins here. The payer can send their message in the software interface (either the standalone program or the Firefox add-on), The link, at a minimum, identifies the recipient and the amount, that must be passed to the software. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? What message needs to be passed by the payer, that is not possible in the interface, but is possible by clicking on the link? That would imply that the link invokes methods like post or get, that are exclusively http/s functionality, that is defeating the purpose of having a purpose made URI scheme. Post and Get functions need to be addressed within the hierarchical namespace of TCP/IP and/or physical file path names.\n\nDetails: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.\n\nAs far as this \"you could also link to freenet, i2p and tor to keep things anonymous.\" is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with. That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless. If I can make the URI handler address the freenet namespace, then I suggest it would much better to store the files there in the first place. Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.\n\nIf I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.\n\n―――\nEDIT:\n\nRe my comment \"The amount: Yup goes without saying.\" I take that back. I was thinking in terms of links only as instigators of payment events, but of course, if the amount and other parameters are left blank, it should then default to acting as an identifier link to instigate a payment at the behest of the payer. A simple donate button would only need one parameter and zero redirections/login/confirmation/calculate and change currency before you can finally send, to not see your transaction eating the dust of snailmail on horseback, in the event that you don't have a credit card. (Suck on that that PlayPal). That, along with the naming alias idea suggested by DataWraith AKA (having an address), if that;s what you meant DataWraith, is certainly worth implementing for my bitcoin.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=55.msg1043#msg1043"},{"f":"D҉ataWraith","d":1272798789,"b":[["t","Karmicaids, thanks for taking the time for such a detailed reply."],["q","It seems there is, as it just so happens, an existing protocol precisely for interacting with stored data files on freenet  Grin <YAY!> Grin","Quote from: Karmicads on May 02, 2010, 02:15:51 AM"],["t","Oh, I thought you meant that when you spoke of using freenet. The user runs freenet and Bitcoin would communicate with it using its control protocol. However, running Freenet requires considerable computer resources, especially bandwidth, and personally, I do not want to run a freenet node for that reason alone. That's why I wanted this to be optional."],["q","I hope I didn't give the impression that I either intend to use magnet links without more consideration of/ agreement with others, nor that my provisional support for them is based on their existing popularity.","Quote"],["t","I had the impression that you did not want to re-invent the wheel, and that's why popularity played a part -- that the existing acceptance of magnet links in other software was a plus."],["q","> Quote\n> Magnet links were designed to reference a file or set of files on peer-to-peer networks, and as such all well-known parameters refer to files (file name, size, etc.).\n\nSorry DataWraith, but with all due respect, I have to disagree. The first issue is that files on a hard drive are mapped to a hierarchical namespace of nested locations, i.e. domains and directories. The fundamental difference, in approach of the many P2P networks is that the namespace is not hierarchal and the data it supports is referenced not by address but by the uniqueness of it's content. Whether the target is a file or anything else it's not referenced by a specific fixed address, but by the identity of it's unique contents. Identical files, are essentially the same identity and the P2P application can use multiple instances as multiple feeds to the same item. The parameters of magnet are well suited to any P2P application. ","Quote"],["t","Okay, sorry, seems I haven't made entirely clear what I mean here. I'm aware of how magnet links refer to content, rather than a location in a hierachical namespace.\n\nPerhaps it's just a difference of mental models: For me, a bitcoin transaction is, for lack of better words, not a thing so much as a process. In my mind, magnet links refer to things (usually a file -- whether by content hash or by location), and trying to use them to refer to a process strikes me as a little awkward. Magnet links identify things you then have to go fetch, while a bitcoin transaction is completely described by the link itself (although you still have to say \"Yes, send the coins.\" once you click the link).\n\nTo me it seems that using magnet links would be to (ab)use them for something they were not meant to describe, as they orignated as a replacement for ed2k://, freenet://, et al., describing how to get a file.\n\nA bitcoin-link should be more like mailto: than magnet: IMHO."],["q","Well actually it's a URN handler and I didn't specify any limit to the 'weight' as you put it.","Quote"],["t","Yeah, my mistake, sorry."],["q","In any case I am only contemplating this, in the hope it can be done without installing freenet, at least the chunk of code needed to read and write to and from freenet should be much smaller if (as I suspect) the whole freenet web server is not needed.","Quote"],["t","IIRC the web server is pretty much integrated into Freenet itself. You can use the simpler FCP protocol to talk to a Freenet instance, but because of the type of content on Freenet, not many people are willing to host a publicly accessible instance, so you would have to run your own. I don't begrudge that you want to be able to do this, I'm just not willing to do it myself. I'd much rather host a TOR hidden service -- that's why I suggested to use a general, full-featured URL as the details parameter, instead of making it freenet specific."],["q","> Quote\n>     * address: An address to send bitcoins to. Since one can hand out different addresses to different people, this can also define the sender.\n>     * amount (optional): The amount to send.\n>     * message (optional): A short message that describes the transaction (same as the field in the Bitcoin client)\n>     * details (optional): An encoded URL with further details of the transaction. For a purchase in an online shop, this could link to the details of the purchase for example. Since this would be a full-featured URL in itself, you could also link to freenet, i2p and tor to keep things anonymous.\n\nNot sure what you mean by address, other than the 'address' that is provided by your bitcoin signature (which is more like a name than a place). I cant see how you can hand out different addresses to different people, unless you already have some aliases defined. So you are suggesting an added naming system to encode and translate aliases for a bitcoin node, is that what you mean? That could be done without too much hassle I suppose.","Quote"],["t","Well, yeah, I meant the bitcoin signature. I called it address, because that's what it says in the bitcoin client (i.e. \"Change your address\"). I indeed thought that one should use different aliases, just like the exchange sites currently do: You get an address (or signature, or whatever) to send coins to, and because that address was only given to you, the recipient knows the payment is from you.\n\nA system to translate aliases would of course be nice, but I think that's better handled with an address book or mybitcoin.com <http://mybitcoin.com> or something."],["q","Message: This is where URI data becomes unwieldy. A message is implicitly a useful amount of human communication, which was never intended to be delivered in the URI itself. If the receiving party wants to communicate some text, then they can do so in the document they are publishing (IE. where they are publishing the link). The text for the sending party, can use the normal route, as the link invokes the bitcoin interface and that provides the field to include a note. What message needs to be passed by the receiver (payee) that is not possible in the document in which they are publishing the link? ","Quote"],["t","Yes, exactly! The text for the sending party can use the normal route. But what if I want to pre-specify the text that should be sent?\n\nThis has an analogue in mailto:-links: If you want someone to send you an email, you can also specify a subject he/she should use: mailto:alice@example.org?subject=Test. So if I am selling something on, say, ebay, I can give the buyer a bitcoin link that includes the message \"Payment for Ebay auction #12345\", so he/she does not have to enter it themselves, possibly making a mistake if the code is more cryptic than #12345."],["q","Details: I advocated from the outset, the desirability of the URI scheme, being able to reference a document with a richer data structure, that can be used to embellish upon the basic essential information passed by the obligatory parameters. I also suggested a proposed repository for those documents which lead to some accessibility issues, but if solved would enhance the anonymity of the bitcoin node and circumvent the reliance on non-P2P or hierarchical namespace. The possibility of taking a beautiful network addressing protocol and remapping it with (or kludging it onto) a regressive, inferior, butt ugly one, which requires all entities to adopt the analogy of a fixed location, and loose all hard wired associations if they are shifted, seems to me as tactful as giving a beautiful stone building a coat of cheap plastic paint; bright green paint. A URL for a parameter, Is precisely the kind of butchery I would rather avoid, because a URL is not a URN and the namespace it addresses, is hierarchical and must ultimately reside at a fixed IP.","Quote"],["t","Sorry, I mistakenly tend to use the terms URI, URL, etc. interchangeably because you enter it into the address bar %). Again, sorry if this lead to confusion.\n\nWhat I wanted here was to make this additional information general. Some examples might clarify this:\n\n• https://www.myonlineshop.com/purchaseDetails/123456\n\n• http://pastie.org/942292\n\n• freenet://[a ressource on freenet]/\n\n• http://kpvz7ki2v5agwt35.onion/wiki/index.php/PurchaseDetailsHere\n\n• magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C\n\nThe creator of the link chooses where to put the additional details, and the recipient decides whether he needs the supplemental information badly enough to install Freenet/Tor/I2P. That's one of the reasons for including a short message in the link itself: the additional information should not be critical to the transaction."],["q","As far as this \"you could also link to freenet, i2p and tor to keep things anonymous.\" is concerned, you clearly haven't given it much thought. If I could just link to freenet, then I could just as easily incorporate freenet as the actual repository referenced in the URI to begin with.","Quote"],["t","But wouldn't that make the use of Freenet mandatory? I would like this to stay more flexible.\n\nAlso, if I were to run an online shop, I'd rather have people look the details up on my own website rather than them having to install freenet. That might also link my shop's reputation with Freenet, which given Freenet's reputation, might be undesirable."],["q","That's the problem. You can't just store files on freenet, and expect anybody to be able to retrieve them with a URL or a URN, on a regular website, unless the visitor has the client software to handle the link, the reference it gives will be useless.","Quote"],["t","Yup. That's another reason for wanting to also allow normal HTTP(S) URLs. If I have not misunderstood, you seem to want to make the use of Freenet for transactions mandatory, which is something I strongly disagree with."],["q","Because http/s operates on a hierarchical namespace and P2P clients operate on non-hierarchical namespace, the one parameter can't be used to interdependently address both. It's a bit late for you to decide to become anonymous after you have fixed your identity to a physical locus.","Quote"],["t","Not every single transaction needs bulletproof anonymity. Think Open Source projects receiving donations, or online shops. If you (a) need more details than the short message parameter provides, and (b) you want to be totally anonymous, you can just specify a freenet or Tor or I2P-URL (or URN? -- this is confusing :-/ ). If you don't need the added anonymity, you don't have to make the effort to run Freenet/Tor/I2P/whatever."],["q","If I have misunderstood you I apologize DataWraith, but you don't seem to appreciate the difference between the two namespace models, nor their relative advantages and liabilities. I am sill quite willing to consider any other system of schema. I am not rejecting your criticism out of hand, nor insisting my own preferences should be the default. I would prefer to simply make the best URI scheme possible regardless. Thanks for your consideration all the same.","Quote"],["t","Well, we're all together in this. I just hope to arrive at the best possible system. :-)\n\nThank you for your thorough explanation, and patience with my suggestions."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1045#msg1045"},{"f":"satoshi","d":1274049441,"b":[["q","A freenet URI is like this:\n\nhttp://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf","Quote from: Karmicads on May 01, 2010, 06:06:53 AM"],["t","There you go, we could easily do it the same way, like:\nhttp://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>\n\nBitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer."],["q","A bitcoin-link should be more like mailto: than magnet: IMHO.","Quote from: DataWraith on May 02, 2010, 11:13:09 AM"],["t","I think we can do that.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1132#msg1132","s":1,"n":100,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/100/"},{"f":"lachesis","d":1276267916,"b":[["q","There you go, we could easily do it the same way, like:\nhttp://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>","Quote from: satoshi on May 16, 2010, 10:37:21 PM"],["t","That's a very pragmatic answer. I like it.\n\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]\n\nI know it's been nearly a month, sorry."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1483#msg1483"},{"f":"satoshi","d":1276647347,"b":[["t","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\n\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.\n\nWhat would be nice about sending by domain is you could visually verify who it's going to.\n\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\n\nand if that's true, then what about that example freenet link that had 127.0.0.1 in it?"]],"u":"https://bitcointalk.org/index.php?topic=55.msg1596#msg1596","s":1,"n":123,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/123/"},{"f":"lachesis","d":1276668845,"b":[["q","But 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.\n\nWhat would be nice about sending by domain is you could visually verify who it's going to.","Quote from: satoshi on June 16, 2010, 12:15:47 AM"],["t","I think that hiding the complexity of Bitcoin addresses from the casual user is a good thing. Barring that, it should be possible to embed an observable but unalterable message with address transactions. Is there some reason this is technically infeasible?"],["q","A 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\n\nand if that's true, then what about that example freenet link that had 127.0.0.1 in it?","Quote from: satoshi on June 16, 2010, 12:15:47 AM"],["t","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).\n\nTry clicking this link:\nhttp://127.0.0.1/\nYou probably don't see anything (unless you're running a web server on your system), but the browser happily tries to take you there.\n\nXMLHTTPRequest <http://en.wikipedia.org/wiki/XMLHttpRequest> is what we were discussing in that other thread."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1597#msg1597"},{"f":"sirius","d":1276676774,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1598#msg1598"},{"f":"bencoder","d":1276693180,"b":[["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.","Quote from: sirius-m on June 16, 2010, 08:26:14 AM"],["t","You could do an iframe that pointed to something like http://127.0.0.1:8330?pay=domain.com&amount=x&return=<wheretoreturn.php> and then that iframe would contain a little bitcoin interface stating how much & who you're paying and a button to confirm or cancel the payment. If you confirm the payment then it sends the coins to the domain and then redirects to the return value in the query string. bitcoin could add a ?paid=true or ?paid=false to the return location as well so the return script on the domain could then check if it received the payment correctly, or cancel the order.\n\nEdit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1599#msg1599"},{"f":"lachesis","d":1276717112,"b":[["q","Edit: the bitcoin interface should also have a password before you can confirm the payment. Otherwise you could scan for port 8330 being open on anybody and then automatically have it send payments.","Quote from: bencoder on June 16, 2010, 12:59:40 PM"],["t","That's not exactly true. At the moment, Bitcoin only binds RPC to the loopback interface, 127.0.0.1. I would assume that this web interface would be the same. However, there SHOULD be a password to prevent trojans from trivially sending your wallet away. Wallet encryption needs to happen, too."]],"u":"https://bitcointalk.org/index.php?topic=55.msg1601#msg1601"},{"f":"satoshi","d":1279469176,"b":[["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).","Quote from: lachesis on June 16, 2010, 06:14:05 AM"],["t","That's what I thought too."],["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.","Quote from: sirius-m on June 16, 2010, 08:26:14 AM"],["t","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...\n\nIf this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing.\n\nI'll get started on adding the password field."]],"u":"https://bitcointalk.org/index.php?topic=55.msg4008#msg4008","s":1,"n":240,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/240/"}]},{"id":"p31","k":"p","s":"bitcointalk","t":"The current Bitcoin economic model doesn't work","u":"https://bitcointalk.org/index.php?topic=57","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/31/","m":[{"f":"Suggester","d":1266477170,"b":[["t","Edit 24 May 2011: This post has just been majorly updated after more than a year to address the technical issues raised against the original suggestions. The ones presented now are practical. They're also credible as the early warning turned out to be true: Bitcoin has transformed into a ridiculously volatile speculation and hoarding tool rather than a stable medium of exchange.\n\n <http://postimage.org/image/2zivvoft0/>\n\nI dare not spend a coin today lest its price doubles tomorrow, nor dare I receive a payment in coins today lest their price crashes before I rush to sell them, nor dare I, naturally, store my wealth in the form coins so I'm relying on vulnerable exchangers to store it in the form of fiat currency. Something must be very wrong...\n\nYet that was all but unexpected; it was inevitable given how the limited supply system was designed. Let's stop and think about this for a minute:\n\nSatoshi stated in his FAQ that When Bitcoins start having real exchange value, the competition for coin creation will drive the price of electricity needed for generating a coin close to the value of the coin. Now the only problem is that this \"real exchange value\" itself would be determined in part by electricity, computer deterioration, and time expenditures needed to generate new BTCs. And those expenditures increase with time. We have a loop.\n\nEvery four years a miner needs to exert double the virtual effort to create the same amount of coins, which means he'll be constantly demanding higher prices to compensate for his costs. Which also means that bitcoins won't generally be spendable. Why? Because only an idiot spends a currency which he is certain its price will double within 4 years, effectively granting him about 19% real annual interest--significantly better than any bank or mutual fund.\n\nGreat! I hear you say, free money for everyone, right?\n\nWrong.\n\nJust as it's futile to create and distribute free extra coins to anyone already owning them \"to make everyone richer\", built-in deflation won't be helping anyone on the long term. That free money will encourage people to hoard BTCs forever or until another wishful investor buys them, fueling speculation and price bubbles. Bitcoin will ultimately be regarded as a phony investment with no real value, just like the good ol' Pyramid (Ponzi) Scheme where everyone purchases a ticket just to sell it to someone else later for a high profit until the whole system collapses when it runs out of new victims.\n\nThis scenario can only be avoided if the cost of generating new BTCs got constant. Which can only happen if participating nodes needed to exert a more or less constant amount of work (cost) to generate a given amount of BTCs. Only then will people be inclined to actually spend their coins, and they can finally serve their purpose as a stable medium of exchange.\n\nBut that's not it. The very fact that the newly-generated coin supply dwindles as its user base (hopefully) continues to grow will raise that 19% deflation rate even higher. Let alone that many coins are forever destroyed via HDD failures and lost thumb drives, pushing the deflation even higher and higher. High deflation is bad because nobody spends their money, they only save it because it gains value over time. Can you imagine what would've happened if, say, the Japanese government hasn't printed any (or very few) Yens during the last century while the population exploded? One 1911 Yen would have been more than enough to buy a house today. Who then would've spent their Yens in 1911? Why, almost noone of course! This scenario is only avoidable if the number of available BTCs continues to grow with its user base at least proportionally. If both figures match, we won't have deflation nor inflation.\n\nBut under the current model the price wouldn't necessarily be tied to the increasing generating electricity costs forever, which means there's a different scenario other than a perpetually deflating currency, and it's much worse: After about 14 years almost no new coins will be produced. Generating costs could then be largely irrelevant, resulting in a lack of a price anchor. This would leave the price solely to the market's supply and demand forces. Just like Picasso paintings, a coin could then be worth $1 on a given day then literally be worth $100 on the next and vice versa.\n\nSo what's the solution? Well, as you might have already guessed, we should remove both the 4-years doubling interval rule and the 21M limit. Just allow BTCs to be generated indefinitely.\n\nDon't sigh in relief just yet. After removing the limit we're better off but still have another issue: The number of users and generating nodes grows exponentially while the existing coins grow arithmetically. We therefore need a mechanism to reflect the number of generating nodes (i.e the total exerted effort) into the resulting bitcoins. But blocks aren't the answer: Technical difficulties have been addressed against my original suggestion which advised rendering the amount of generatable blocks unlimited and totally dependent on the number of nodes. The problem was that a minimum \"cooling down\" period is needed to propagate who owns the new block across the entire network to avoid conflicts.\n\nMy modified suggestion therefore is to reflect the total exerted effort in the number of coins, not blocks. So we'd still have only 144 new daily blocks, but the amount of coins in these new blocks will depend on the proof-of-work difficulty (which automatically adjusts to the number of generating nodes). That makes sense. A late adopter who needs to spend weeks, months, or even years to generate a block should end up with more coins in that block than an early adopter who had to spend only a couple of hours.\n\nAnd no, sorry, early adopters didn't take any risk to deserve a reward. Running a computer program which pops deflationary money isn't a risky activity, not one that warrants a 1,000,000% profit anyway. No wonder Satoshi (not his real name, which is unknown) was fiercely defending the original design and wanted to keep it going for as long as possible. It allowed him to initially produce all 144 daily blocks (7200 coins/day) for quite a while before having competing miners drive his coins' price way up. He's probably following up on this forum from his Caribbean beach seat now, with other \"early adopters\" eager to join him. The proposed system is the way to halt this pyramid scheme.\n\nThe coins' price will then depend on the total cost of electricity sacrificed to generate the newest block. Think of it as if everyone in the network bought some electricity from their utilities company before loading it all onto the network where the roulette runs every ten minutes on average with one lucky winner hitting the jackpot. Bitcoins would have a real value equal to the amount of electricity sacrificed to create them, and their price would essentially be a function of the (pretty stable) average worldwide home electricity costs, not a function of the number of generating nodes nor total demand, which will never stabilize in the foreseeable future. Under the proposed system, if the number of generating users doubles tomorrow, the number of coins generated tomorrow will double as well, offsetting the demand surge with a supply surge without the need for a price jump followed by price crash as is the case now.\n\nThis flexible supply system will be telling everyone there's no advantage to being an early adopter. A user doesn't need another victim to reap rewards later because there are no rewards to begin with. Bitcoin is a medium of exchange, not a profit-making tool. Speculators and investors can go ruin another currency for there's nothing for them to gain here until they can manipulate global electricity prices. By eliminating risk and uncertainty we're showing them the door, thus accomplishing the most important task towards achieving a stable medium of exchange the general population can trust.\n\nFinally, a simple numerical example: If we assume the average worldwide cost of running a modern CPU for 24 hours is 20 cents, and if our initial goal is to have one BTC roughly equaling one US dollar, then the amount of coins each new block contains should equal: (fifth of a BTC/144 * the estimated equivalent of the modern CPUs number in the network). Thus, if the exerted power was then estimated to equal 10,000 CPUs, the new block created at that point would contain 14 BTC because the whole network spent $14 during the last 10 minutes to create it. If it was 20,000 CPUs, the new block would have 28 BTC and so on. Once enough coins are produced for ฿1 equaling $1, miners would generate just enough to cover the economy's expansion because any excess will come to them at a loss. The price would then fluctuate approximately along the lines of 99¢-$1.03.\n\nPractically speaking, if the price of 1 BTC after implementing the new system was, say $10, we could simply add a zero to increase the amount of existing coins ten-fold, making 1 BTC equaling 1 dollar, after which the price will essentially stabilize itself automatically forever. Note that the estimated CPUs figure is arbitrarily set using current computer power and running costs. Errors won't be detrimental because the market will correct itself resulting in 1 BTC equaling slightly more or less than $1. For example, if computers became more energy-efficient while electricity costs stayed constant, then ฿1 will equal a bit less than $1 because it now costs less to produce and vice versa. Whatever the case may be, the price would be stable on the short term and move slowly along with electricity costs and CPU/GPU efficiency on the long term, rendering coins as stable as major fiat currencies.\n\nNote that some replies before page 7 might seem irrelevant because of the suggestion improvements addressing them. The removed obsolete paragraphs from the original entry have been copied below in the third post of this thread just in case anyone wants to have a look to understand the full context of the discussion.\n\nNote2: I've revived the thread at the bottom of page 20 due to the increased hacking and abuse of intermediary services such as the MtGox and Bitcoin7 exchangers. The underlying logic is that, had the coin's price been stable, we wouldn't have needed to trust them as often because we wouldn't have been forced to keep our wealth with them in the form of stable fiat instead of in our computers in the form of unstable coins."]],"u":"https://bitcointalk.org/index.php?topic=57.msg390#msg390"},{"f":"I-am-not-anonymous","d":1266478611,"b":[["q","Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins. ","Quote from: Suggester on February 18, 2010, 07:12:50 AM"],["t","As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.\n\nIn other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.\n\nAfter 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.\n\nI could be wrong though.  Somebody who know what they're talking about please comment instead of me!"]],"u":"https://bitcointalk.org/index.php?topic=57.msg391#msg391","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266478990,"b":[["q","> Quote from: Suggester on February 18, 2010, 07:12:50 AM\n> Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.\n\nAs I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.\n\nIn other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.\n\nAfter 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.\n\nI could be wrong though.  Somebody who know what they're talking about please comment instead of me!","Quote from: I-am-not-anonymous on February 18, 2010, 07:36:51 AM"],["t","The plan is to halve the value of the block every four years. So if your PC is making 6 blocks/day now (i.e 300 BTC/day), in 4 years it could be also be making 6 blocks/day, but your balance will only increase by 150 because the block would equal 25 instead of 50 BTCs\n\nEdit 24 May 2011: These are the removed paragraphs from the original 2010 first post. They are obsolete and no longer relevant as the post is now heavily edited. Nevertheless I thought I'd include them for anyone who wishes to understand the full context of the 2010 discussion (up to page 7).\n\nSo what's the solution? Well, as you might have already guessed, we should remove both the 4-years interval thing and the 21M limit. Just let BTCs continue to be created forever at a constant rate*. The rate should be divisible enough to give up to, say, 100,000 people an incentive to run the network simultaneously. In other words, the current 144 daily blocks (or units) aren't enough because this means that @ 100,000 users, one has to wait an average of 757.6 days (that's 2+ years) to see something pop up on his screen. 100k is an arbitrary figure, but remember that we need to mobilize as many nodes as possible to resist the tampering attempts of supercomputer-owning governments who can and will try to generate their own proof of work to ruin the project if it ever reaches mainstream. Also note that this will not lead to inflation in the foreseeable future, because the user base of bitcoin will continue to grow for years to come, let alone natural economic and population growth (unless the Mayans turn out to be right, of course).\n\nThis way, when the number of bitcoin-generating nodes approaches stability, we will end up with a slowly-growing number of bitcoins matching a slowly-growing number of nodes, resulting in the currency's relative price stability, leading in turn to the ultimate goal of it being used for exchange purposes.\n\nNow for the fun part, a numerical example: If the system is producing 10k bitcoins/day at a constant rate (with difficulty adjusted by collective CPU power just like it is now), and the number of users attempting to generate BTCs was 10k after 1,000 days from now, and increasing at a constant rate of 10 new users/day, we will have and continue to have an average of 1,000 BTCs/user. No inflation, no deflation, no incentive to hoard BTCs, and no incentive to spend BTCs quickly (though that wouldn't necessarily be a bad thing!). Remember that we can always add or remove zero's if the numbers turned out to be awkward at some point, like Germany did in the 1920's hyper-inflation. Note that under this model, an initial price surge is inevitable because the number of nodes increases at abnormal rates at the project's beginning. As the project matures, there would be only reasonable user-base increases, so the price won't fluctuate much any longer (think the percentage increase in newly opened email accounts from 2000 to 2001 vs from 2020 to 2021, for example).\n\n*Another idea would be to set the BTCs creation's difficulty irrelevant of total CPU power in the network so that, say, the average computer would create 1 BTC/day. The global price would then automatically adjust to the participants' average electricity and machine consumption cost. It would be sort of like buying some electricity from the utilities company and loading it on your machine as transferable BTCs. If electricity happens to be cheapest in India, Indians will initially profit from creating BTCs, but as their proportion among the nodes increases, the BTCs price will decrease as it approaches India's average electricity cost. Exchangers will quickly balance supply and demand just as in ForEx fluctuations, Econ 101, remember? Non-Indians would purchase BTCs from Indian exchangers at a very small profit margin because of competition. I personally prefer this model to the constant rate one because the amount of BTCs in circulation would generally be proportionate to the amount of users (sort of like farming gold in MMORPGs), instead of picking an arbitrary constant figure and letting users adjust to it. Thus this model avoids the initial price surge because there will be a balance from day one.\n\nAdmittedly, BTCs' price would be tied to energy's under this model. But then again, this is also the case in both my other and the current model. Besides, using Bitcoin for casual quick transfers (rather than as savings) would virtually eliminate this risk. Also granted that creating zillions of BTCs (eg. via governmental sabotage) would lead to inflation in this case if they flood the market with cheap coins, but then again this problem exists in the other two models as well, and can also be avoided by those using the coin for transfers only. But whereas in the other two models a supercomputer-or-two can ruin the whole project by barring most of the honest nodes from creating coins (via controlling most of the CPU power and skyrocketing coin-generating needed effort), under this uber-flexible model everybody will be able to create some coins and use them for transfers regardless of sabotage attempts."]],"u":"https://bitcointalk.org/index.php?topic=57.msg392#msg392","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"I-am-not-anonymous","d":1266479892,"b":[["q","> Quote from: I-am-not-anonymous on February 18, 2010, 07:36:51 AM\n> > Quote from: Suggester on February 18, 2010, 07:12:50 AM\n> > Every four years, the average BTC generator will need to spend double the effort to create the same amount of coins.\n>\n> As I understood it people will not need to double their CPU power to get the same amount of coins, rather there'd be half as many coins \"up for grabs\" by anybody with enough CPU power.\n>\n> In other words, let's say a Powerful CPU can pull in 500 coins a day and a weaker CPU can pull in 300 coins per day from a pool of 10,500,000.\n>\n> After 4 years, they are still pulling in 500 coins and 300 coins respectively, but now they can only access a pool of 5,250,000.\n>\n> I could be wrong though.  Somebody who know what they're talking about please comment instead of me!\n\nThe plan is to halve the value of the block every four years. So if your PC is making 6 blocks/day now (i.e 300 BTC/day), in 4 years it could be also be making 6 blocks/day, but your balance will only increase by 150 because the block would equal 25 instead of 50 BTCs","Quote from: Suggester on February 18, 2010, 07:43:10 AM"],["t","I think I understand, thank you for correcting me.\n\nRight now, Your average coin creation rate will be (6 * 50 coins / hour) * (your CPU speed / the total CPU speed in the system)\n\n4 Years from now, Your average coin creation rate will be (6 * 25 coins / hour) * (your CPU speed / the total CPU speed in the system)\n\nBecause the amount of bitcoins per block halves every 4 years.\n\nMy question is, what happens if (your CPU Speed) and (The total CPU Speed in the System) double  in 4 years?"]],"u":"https://bitcointalk.org/index.php?topic=57.msg394#msg394","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266480173,"b":[["q","I think I understand, thank you for correcting me.","Quote from: I-am-not-anonymous on February 18, 2010, 07:58:12 AM"],["t","NP, I just sent you a PM Smiley"],["q","My question is, what happens if (your CPU Speed) and (The total CPU Speed in the System) double  in 4 years?","Quote from: I-am-not-anonymous on February 18, 2010, 07:58:12 AM"],["t","If both doubles then the ratio will stay the same, so the generation will stay the same. You see, it's all relative. Practically, of course, what will probably happen is that your ratio will be much less since more people will hear about Bitcoin (also given the recent surge in capitalist-anarchists and communists)."]],"u":"https://bitcointalk.org/index.php?topic=57.msg395#msg395","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"I-am-not-anonymous","d":1266483005,"b":[["t","I'm really tired and I have work tomorrow so this will be my final post for possibly 18 hours but I see what you're saying--your ability to generate bitcoins will inevitably be reduced because people with high-power server farms will take over production.\n\nBut when the first system-wide \"halving\" of bitcoins occurs there will be 10,500,000 while the server farms get started on the 5,200,000.\n\nThis means twice as many bitcoins will be available via exchange than via creation.  If some CPU farmer determines that in now takes double his resources to make bitcoins and thus doubles his exchange rate for his fresh product, he is very likely to be underbid by the people controlling the 10,500,000 because of the time value of money.\n\nYou said \"only and idiot would sell at 19% interest rates\" (paraphrase) but in a free market, somebody HAS to be willing to sell for there to even BE an interest rate, people willing to exchange value today for value tomorrow."]],"u":"https://bitcointalk.org/index.php?topic=57.msg396#msg396","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266484212,"b":[["q","I see what you're saying--your ability to generate bitcoins will inevitably be reduced because people with high-power server farms will take over production.","Quote from: I-am-not-anonymous on February 18, 2010, 08:50:05 AM"],["t","That's only a tiny part of the problem!"],["q","This means twice as many bitcoins will be available via exchange than via creation.  If some CPU farmer determines that in now takes double his resources to make bitcoins and thus doubles his exchange rate for his fresh product, he is very likely to be underbid by the people controlling the 10,500,000 because of the time value of money.","Quote from: I-am-not-anonymous on February 18, 2010, 08:50:05 AM"],["t","What will probably happen is the other way around: Those who create BTCs in the first 4 years will make unreasonable profit as they enter the 5th year, and those who create BTCs in the second 4 years will make unreasonable profit as they enter the 9th year, etc"],["q","You said \"only and idiot would sell at 19% interest rates\" (paraphrase) but in a free market, somebody HAS to be willing to sell for there to even BE an interest rate, people willing to exchange value today for value tomorrow.","Quote from: I-am-not-anonymous on February 18, 2010, 08:50:05 AM"],["t","The \"interest rate\" would be the expected future value at best, or Bitcoin will be regarded as a currency without a future at worst. Just like Pyramid Schemes: Many people bought them but nobody took them seriously. It is well established that under perfectly free markets, commodities are sold at a very small or even no margin above their cost on the long run. Since BTCs cost will double every 4 years, so will their price. So nobody under normal circumstances would be willing to sell his ever-inflating BTCs unless he wants to escape the system with some profit before it collapses."]],"u":"https://bitcointalk.org/index.php?topic=57.msg397#msg397","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"sirius","d":1266499910,"b":[["t","Bitcoin is similar to gold in terms of finite supply and increasing mining costs. Every argument you can make against Bitcoin economy you can make against gold economy, but gold economy still works. Actually, gold currency has been throughout the history unmatched by any paper money in stability.\n\nIt's an old keynesian argument that deflation is bad because it leads to a \"deflationary spiral\" where nobody eventually buys anything, because they can get more the next day. That didn't happen where gold standard was applied. Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime. A good example is the computers market - you can get twice as good a computer with the same price if you wait a few years, but people still do buy computers today.\n\nAlso, it's good to note that production cost doesn't equal value. You could start printing a currency of your own, but it's value wouldn't be equal to your printing costs. The value is zero if nobody accepts them as payment, or it can be more than the printing costs if many people accept it for payment and there's not too many notes in circulation. That's why I've found NewLibertyStandard's pricing by the production costs a bit misleading, giving the wrong picture to some people that bitcoin value is somehow bound to the electricity cost. He may of course sell and buy at whatever price he wants, but he'll be short on either bitcoins or dollars if it's not the market price (supply/demand)."]],"u":"https://bitcointalk.org/index.php?topic=57.msg398#msg398","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266523135,"b":[["t","There isn't a right and wrong economic model. Every model adjusts to supply and demand, they just adjust in different ways.\n\nThe current model is beneficial to early adopters in three different ways. First, early adopters generate more bitcoins while there is less competition at the beginning. Second, the availability of bitcoins decreases, which cements their position of wealth. Last, the early adopters have the potential to get rich off the latecomers once generating blocks becomes extremely difficult. Latecomers will have to inject dollars or something else of worth in order to get access to bitcoins and the wealth will go disproportionately to the early adopters.\n\nThe idea of the swarm increasing the amount of bitcoins awarded as processing power increases is interesting, but I think it would give too much advantage to botnets. With a constant amount of bitcoins being generated, they can only collect a days worth of bitcoins per day, but if the number of bitcoins was variable, they could swoop in and generate a thousand years worth of bitcoins in a few weeks.\n\nIn my ideal model, the same amount of blocks would be generated per day, but 100 bitcoins with no decimal would be awarded for generating a block instead of 50.00 and the amount of bitcoins awarded per block would stay the same forever instead of halving every four years. This would give one advantage to the early adopters who would be able to generate bitcoins more easily while there is less competition at the beginning and it would allow deflation as more people adopt bitcoins, but it would also allow for inflation as more bitcoins are generated, thus encouraging people to spend their bitcoins. Eventually creating bitcoins will still become very difficult and dollars or something else of worth will have to be injected in order for latecomers to get access to bitcoins, but as time passes, that wealth will be distributed more and more evenly between early adopters and latecomers. I prefer 100 to 50.00 because bitcoins are going to take a while before they are worth enough to need to be more divisible and because it's not clear whether a single bitcoin is ฿1.00 or ฿0.01."]],"u":"https://bitcointalk.org/index.php?topic=57.msg399#msg399","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266527963,"b":[["q","Bitcoin is similar to gold in terms of finite supply and increasing mining costs. Every argument you can make against Bitcoin economy you can make against gold economy, but gold economy still works. Actually, gold currency has been throughout the history unmatched by any paper money in stability.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","No. Gold was synonymous to \"money\". Things were valued for how much gold they were worth, not vice versa. We should think of bitcoin today as a new unestablished currency in a world of established alternatives (eg. the Euro 10 years ago). Additionally, if we assume that it became impossible to mine virtually anymore gold today, and we further assume that the demand for gold was perpetually on the rise (for example because women were increasingly using it for jewelery), then yes, it will result in a perpetual deflation for its value and nobody would be willing to sell their gold except for emergencies. Under these conditions, using gold as a means of payment is a sure way for starting a depression!"],["q","It's an old keynesian argument that deflation is bad because it leads to a \"deflationary spiral\" where nobody eventually buys anything, because they can get more the next day.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","Old and true Smiley"],["q","That didn't happen where gold standard was applied.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","What has gold standard got with increasing the value of BTCs over time? Gold was ALREADY a medium of exchange when the gold standard was applied. I can imagine that the very first time some human discovered the first gold mine, everybody in their area thought it looked cool and started using it as a medium of exchange. People have been mining gold for thousands of years and we haven't still run out of it. BTCs will essentially stop its generation within 15 years."],["q","Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","They won't buy tomorrow when the price is lower because it will never be lower as we approach the \"next four years limit\"."],["q","A good example is the computers market - you can get twice as good a computer with the same price if you wait a few years, but people still do buy computers today.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","Computers are totally different because you can't sell them 4 years from now for double what they're worth today. Had this been the case, nobody would ever sell a computer unless he's starving. Heck, just look at NewLibertyStandard's graph. It will keep shooting up as long as this 4-year model continues."],["q","Also, it's good to note that production cost doesn't equal value. You could start printing a currency of your own, but it's value wouldn't be equal to your printing costs. The value is zero if nobody accepts them as payment, or it can be more than the printing costs if many people accept it for payment and there's not too many notes in circulation. That's why I've found NewLibertyStandard's pricing by the production costs a bit misleading, giving the wrong picture to some people that bitcoin value is somehow bound to the electricity cost.","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","If the value is more than my printing costs, I'll be busy printing like there's no tomorrow until the price equals my cost (remember that I'm acting like a selfish unorganized person, not an entity or a country, just like most of Bitcoin users will be). If the value is less than my printing costs, me or anyone who wishes to acquire that currency will buy it from others instead of creating it, raising the price of coins already in circulation and dropping the competition and cost of creating new ones (and in bitcoin's case that means network and proof-of-work failure). So you see, in our coin's case, its market value must equal electricity & computer cost. Not more or less. And in any perfectly free market you'll find a similar situation: price = cost."],["q","He may of course sell and buy at whatever price he wants, but he'll be short on either bitcoins or dollars if it's not the market price (supply/demand).","Quote from: sirius-m on February 18, 2010, 01:31:50 PM"],["t","You said it: Supply & demand. What will happen if BTC got successful is that demand will increase while supply dwindles. At some point (after about 15 years) there will be more and more people demanding coins while almost none is generated. This will result in the price increasing until every human on the planet who will potentially use bitcoin has already joined its market (assuming the 4-year doubling thing was removed). And you know what? Maybe that happened to gold in the beginning of its discovery, until almost all people on the planet had gold available to them if they had a reasonable equivalent (e.g. In Arabia, more than a thousand years ago, you could have sold a camel at a time for about 70 gold dinars, and a rabbit for tenth of a gold dinar. Not too difficult to make)."],["q","There isn't a right and wrong economic model. Every model adjusts to supply and demand, they just adjust in different ways.","Quote from: NewLibertyStandard on February 18, 2010, 07:58:55 PM"],["t","Pyramid Schemes is an absolutely \"wrong\" economic model!"],["q","The current model is beneficial to early adopters in three different ways.","Quote from: NewLibertyStandard on February 18, 2010, 07:58:55 PM"],["t","Who said it should be beneficial to early adopters? I mean, that's cool because I happen to be one, but if it undermines the model's sustainability then it shouldn't stay."],["q","The idea of the swarm increasing the amount of bitcoins awarded as processing power increases is interesting, but I think it would give too much advantage to botnets. With a constant amount of bitcoins being generated, they can only collect a days worth of bitcoins per day, but if the number of bitcoins was variable, they could swoop in and generate a thousand years worth of bitcoins in a few weeks.","Quote from: NewLibertyStandard on February 18, 2010, 07:58:55 PM"],["t","Uh huh, but botnets can't start generating now and collecting 90%+ of newly created blocks? Botnets/supercomputers will always be a problem in any model. But with a limited supply such as 6 blocks/hour, almost nobody can compete with them (can you wait 2 months for a coin to appear?). While if the supply is unlimited, at least we'll end up getting something, and hopefully trading it for a price close to what you've paid for it."],["q","In my ideal model, the same amount of blocks would be generated per day, but 100 bitcoins with no decimal would be awarded for generating a block instead of 50.00 and the amount of bitcoins awarded per block would stay the same forever instead of halving every four years.","Quote from: NewLibertyStandard on February 18, 2010, 07:58:55 PM"],["t","That's what I've been advocating as the second-best solution. But we'll need to increase the # of daily blocks to give enough incentives though as I explained in the initial post."]],"u":"https://bitcointalk.org/index.php?topic=57.msg400#msg400","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266532153,"b":[["t","I stand by my statement that the current economic model is not wrong. You might dislike it and I might not prefer it, but other people do prefer it. Our perspective is no more valid than theirs. But that's not to say that I wouldn't use a bitcoin variant if it more closely resembled the description I offered."],["q","Who said it should be beneficial to early adopters?","Quote from: Suggester on February 18, 2010, 09:19:23 PM"],["t","I'm just stating the facts, sir.\n\nCurrently a botnet could generate 99.9% of bitcoins per day, but if bitcoin generation payout was variable, they could generate over 9000% of how many bitcoins are generated per day without them. Botnet operators value their CPU cycles, so being able to generate over 9000% until they have as many as they currently want and then being able to stop and use their CPU cycles for other purposes is much more advantageous than having to use their spare CPU cycles to only generate a capped amount per day.\n\nThe number of blocks generated per day can not be easily increased or decreased because there has to be enough time to propagate the blocks to all other nodes while still being frequent enough to allow timely transactions. What can vary is the amount of bitcoins per block. The amount of bitcoins awarded per block can either increase, decrease or stay constant over time. If every person had an equal amount of CPU cycles at his disposal, I would prefer for the amount of bitcoins awarded per generated block to increase proportionally to the amount of CPU used to generate bitcoins. As it is, I'm in favor of the amount staying constant over time."]],"u":"https://bitcointalk.org/index.php?topic=57.msg401#msg401","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266532923,"b":[["q","> Quote from: sirius-m on February 18, 2010, 01:31:50 PM\n> Maybe some people will not buy today, but they'll buy tomorrow when the price is lower and they want to enjoy their finite lifetime.\nThey won't buy tomorrow when the price is lower because it will never be lower as we approach the \"next four years limit\".","Quote from: Suggester on February 18, 2010, 09:19:23 PM"],["t","He was referring to the price of goods decreasing as value of a bitcoin increases. Eventually the value of bitcoins will go high enough and the price of the goods will go low enough that the person will feel rich enough to spend his bitcoins. To take it to an extreme, if a person has ten thousand bitcoins and can buy the TV of his dreams for one bitcoin, the value of having the TV now is greater than the future potential increased value of the one 10,000th of his total bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=57.msg402#msg402","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266584794,"b":[["q","Currently a botnet could generate 99.9% of bitcoins per day, but if bitcoin generation payout was variable, they could generate over 9000% of how many bitcoins are generated per day without them.","Quote from: NewLibertyStandard on February 18, 2010, 10:29:13 PM"],["t","9000% of the now-cheaper-coin because so much of it is available after they joined. It all balances out in the end, and in both cases they have an incentive to join the network. Actually, under the current model they have even more incentive because the coin can never get cheaper!"],["q","Botnet operators value their CPU cycles, so being able to generate over 9000% until they have as many as they currently want and then being able to stop and use their CPU cycles for other purposes is much more advantageous than having to use their spare CPU cycles to only generate a capped amount per day.","Quote from: NewLibertyStandard on February 18, 2010, 10:29:13 PM"],["t","To be honest, I don't see what more harm a botnet can make if we changed to the suggested model. Economically, it would be just like 1,000 honest members joined the network. This can even help the project with some free advertising on security blogs Smiley"],["q","The number of blocks generated per day can not be easily increased or decreased because there has to be enough time to propagate the blocks to all other nodes while still being frequent enough to allow timely transactions. What can vary is the amount of bitcoins per block. The amount of bitcoins awarded per block can either increase, decrease or stay constant over time. If every person had an equal amount of CPU cycles at his disposal, I would prefer for the amount of bitcoins awarded per generated block to increase proportionally to the amount of CPU used to generate bitcoins. As it is, I'm in favor of the amount staying constant over time.","Quote from: NewLibertyStandard on February 18, 2010, 10:29:13 PM"],["t","How about a middle solution then? For example, the default difficulty be adjusted to about 1 block/CPU/day (assuming an average 2.4 GHz processor), but in case more than X blocks/day was being created (X = the maximum # of daily blocks afterwhich there is no enough time for propagation across the network), then difficulty gets automatically adjusted. Practically, it would end up being like my second-best and your best model. In other words, very close to the current situation except that we assume the current 4-years-period is extended to forever. So let's at least agree that the removal of the 4-year thing and the 21M limit is essential to avoid an ever-deflating currency."],["q","He was referring to the price of goods decreasing as value of a bitcoin increases. Eventually the value of bitcoins will go high enough and the price of the goods will go low enough that the person will feel rich enough to spend his bitcoins. To take it to an extreme, if a person has ten thousand bitcoins and can buy the TV of his dreams for one bitcoin, the value of having the TV now is greater than the future potential increased value of the one 10,000th of his total bitcoins.","Quote from: NewLibertyStandard on February 18, 2010, 10:42:03 PM"],["t","You only switched the problem to another user then: The TV seller! He would also keep this coin until he has 10,000 coins. The point is that it's very hard (albeit not impossible) to convince people to spend or transfer a coin they are pretty sure will be 19% more valuable within a year. Moreover, economic-savvy folks might as well choose not to join the network if they predict this will happen, or join it with the intent of \"hitting-and-running\" a quick profit before the system's failure becomes imminent, and they will be right."]],"u":"https://bitcointalk.org/index.php?topic=57.msg404#msg404","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266603978,"b":[["t","The problem with botnets is that their operators are stealing electricity, bandwidth and access to RAM, hard drive space and CPU time. Everyone else is paying for those resources out of their own pockets.\n\nThe order of my preferences for how I would like bitcoin to work is first, for the amount of bitcoins awarded to stay constant as I previously described <https://www.bitcoin.org/smf/index.php?topic=57.msg399#msg399>, second, for the amount of bitcoins awarded to increase at a constant rate, third, for the amount of bitcoins awarded to decrease at a constant rate, last and least, for the amount of bitcoins awarded to increase at a variable rate. If botnets did not exist than the variable option would be at the top of my list instead of the bottom.\n\nEDIT: My new highest preference for how I would like bitcoin to work is for the amount of bitcoins awarded to increase at the same rate as worldwide human population growth.\n\nIf the TV buyer is an early adopter and the TV seller is a latecomer, then the TV buyer already has many bitcoins and it would cost the TV seller more dollars worth of electricity than the price of the TV to generate 1 bitcoin. I do not agree that it will be hard to get people to spend their bitcoins. People do value potential future increases, but they also value having an item now. Why would someone borrow money on a credit card with a 19% interest rate instead of keeping their money in their savings account? They do it because they value having the TV now more than the potential losses over time. Life is short. You're welcome to save all your high returning money until the day you die, but the rest of us are going to make use of it before it's no use to us."]],"u":"https://bitcointalk.org/index.php?topic=57.msg405#msg405","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266605310,"b":[["q","Heck, just look at NewLibertyStandard's graph. It will keep shooting up as long as this 4-year model continues.","Quote from: Suggester on February 18, 2010, 09:19:23 PM"],["t","My exchange rate will only increase as Bitcoin becomes more popular. There are practical limits to the popularity of Bitcoin. Sure, potentially it could be run on every functional computer around the world, but from practical perspective, that will never happen. The swarm is currently pretty small, so when a few new users join, there is a large effect on my exchange rate and it increases fairly quickly. As the rate of growth slows or reverses and as my exchange rate average increases over the next two years, the exchange rate will steady out with only very small increases AND decreases every day. As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy. In any case, hopefully by then there will be other ways of calculating the value of a bitcoin other than my single solitary exchange service."]],"u":"https://bitcointalk.org/index.php?topic=57.msg406#msg406","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"I-am-not-anonymous","d":1266627962,"b":[["q","No. Gold was synonymous to \"money\". Things were valued for how much gold they were worth, not vice versa. ","Quote from: Suggester on February 18, 2010, 09:19:23 PM"],["t","In school, they taught us (i.e. me) that a good's value price is based solely on what people can exchange it for.  They also taught us that a good's value was not determined by how much labor went into the good.\n\nWe were essentially told that if one camel is worth 50 gold dinars, then 50 gold dinars is also worth one camel.  Or something to that effect.\n\nIf this is the case, then the cost of producing bitcoins would only a be a factor in, not a determinant of, their value.\n\nDid I understand the lesson correctly?\n\n_______________________________________________________________________________ ______________________________\nOn the general topic of whether bit-coin will/will not be successful--I don't really know.  I act as though I am a \"bitcoin defender\" but this is mostly because I am excited about the new currency and want to support it, not because I know enough about economics to predict it's eventual usefulness.  \n\nI would very much like to see people who dislike bitcoin's design organize and code alternative currencies that inflate according to a monetary rule, or have the built in safeguards you described.  That way, the market will eventually choose the best currency as people move towards the good ones and away from the bad.  \n\nI am not sure if bitcoin's creators will be convinced to implement the changes you recommend--but i think you are very likely to find people who agree with your plan for a better encrypted digital currency and will help you modify or re-write bitcoin's source to make it happen."]],"u":"https://bitcointalk.org/index.php?topic=57.msg407#msg407","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266628518,"b":[["q","The problem with botnets is that their operators are stealing electricity, bandwidth and access to RAM, hard drive space and CPU time. Everyone else is paying for those resources out of their own pockets.","Quote from: NewLibertyStandard on February 19, 2010, 06:26:18 PM"],["t","That's not a problem for Bitcoin or its users. If those CPU cycles aren't used to steal electricity for bitcoin, they'd be used to steal electricity to DDoS some site or brute-force some account. We shouldn't worry about them. As I said, they're just as if those users voluntarily joined the network for all practical purposes."],["q","EDIT: My new highest preference for how I would like bitcoin to work is for the amount of bitcoins awarded to increase at the same rate as worldwide human population growth.","Quote from: NewLibertyStandard on February 19, 2010, 06:26:18 PM"],["t","\"Human population\" is totally irrelevant. Even if human population was shrinking by, say 1% annually now, I assure you that Internet users population will be increasing and bitcoin users will be increasing at an even higher rate. \"Bitcoin users\" is the magic word here. With the suggested variable model, we're always sure that new coin generation matches the expanding (or shrinking) user base. But anyway, I see that you're beginning to side with me that the 4-year-doubling isn't a good idea."],["q","If the TV buyer is an early adopter and the TV seller is a latecomer, then the TV buyer already has many bitcoins and it would cost the TV seller more dollars worth of electricity than the price of the TV to generate 1 bitcoin.","Quote from: NewLibertyStandard on February 19, 2010, 06:26:18 PM"],["t","Man, if you paid $1,000 for an ounce of gold, then a few months later it was worth $2,000, are you going to sell it for $1,000?! No? Good. Because the early adopter will not treat his coins as if they're worth the pennies he paid for them anymore now that they're worth a ton of electricity. He'd treat them for what they're worth today."],["q","I do not agree that it will be hard to get people to spend their bitcoins. People do value potential future increases, but they also value having an item now. Why would someone borrow money on a credit card with a 19% interest rate instead of keeping their money in their savings account? They do it because they value having the TV now more than the potential losses over time. Life is short. You're welcome to save all your high returning money until the day you die, but the rest of us are going to make use of it before it's no use to us.","Quote from: NewLibertyStandard on February 19, 2010, 06:26:18 PM"],["t","My answer is simple: Assuming people approve the current Bitcoin's model, it will turn out to be the #1 worldwide investment: Just buy (or hack) a bunch of PCs, let them run, and you'll be earning at least 19% annually with no risk involved! Investors (and indeed, botnets) won't leave a chance for normal folks like you and me to earn any BTCs much less spend them. Any bitcoin will be spent 2-3 times at most before falling into the hands (well, \"the computers\" is the better term here) of an investor who'll keep it for a very long time or forever. This model has to change or it will destroy the otherwise excellent idea. Making bitcoin a way to INVEST rather than to SPEND is its one-way ticket to failure. You also forgot that bitcoins will leave the stream all the time (eg. computer failures or accidental deletion), which will add to their deflating. Might as well turn this 19% into 20% or something."],["q","My exchange rate will only increase as Bitcoin becomes more popular. There are practical limits to the popularity of Bitcoin. Sure, potentially it could be run on every functional computer around the world, but from practical perspective, that will never happen. The swarm is currently pretty small, so when a few new users join, there is a large effect on my exchange rate and it increases fairly quickly. As the rate of growth slows or reverses and as my exchange rate average increases over the next two years, the exchange rate will steady out with only very small increases AND decreases every day.","Quote from: NewLibertyStandard on February 19, 2010, 06:48:30 PM"],["t","Even if we assume that Bitcoin's current users will never increase (thus not making it more difficult to generate coins), we're sure that its value will increase by at least 19% annually because of the expected 4-year-old D-day when which all BTCs price magically doubles because it will cost double to generate them."],["q","As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy.","Quote from: NewLibertyStandard on February 19, 2010, 06:48:30 PM"],["t","Can you explain that part? I didn't understand how multiplying by two will achieve stability.\n\nPS. It might be a good idea to merge your previous double-posts in one via Edit to make reading easier for us and those following us. The world is watching (or some three-letter-agencies anyway Smiley)"],["q","We were essentially told that if one camel is worth 50 gold dinars, then 50 gold dinars is also worth one camel.  Or something to that effect.","Quote from: I-am-not-anonymous on February 20, 2010, 01:06:02 AM"],["t","If we assume that dinars can't be used for any other non-monetary purposes (such as jewelry, paperweights, etc), then it's practically very difficult for them to have a demand curve by themselves. Camels can be used to ride, so their gold price fluctuated (i.e. They become more or less popular with time). Bitcoin can only be used as money, so it's used solely to value things not vice versa."],["q","Did I understand the lesson correctly?","Quote from: I-am-not-anonymous on February 20, 2010, 01:06:02 AM"],["t","If raising a camel costed more than 50 dinars, you can count on people stopping raising camels until the price goes back up due to supply shortage. With the absolutely arbitray 4-year model, this can never happen. Supply will ALWAYS decrease no matter what. I'm asking for a more flexible method which depends on the actual number of users."],["q","On the general topic of whether bit-coin will/will not be successful--I don't really know.  I act as though I am a \"bitcoin defender\" but this is mostly because I am excited about the new currency and want to support it, not because I know enough about economics to predict it's eventual usefulness.  ","Quote from: I-am-not-anonymous on February 20, 2010, 01:06:02 AM"],["t","If I wasn't, I wouldn't be here crying my lungs out to correct the model for a one which will work!"],["q","but i think you are very likely to find people who agree with your plan for a better encrypted digital currency and will help you modify or re-write bitcoin's source to make it happen.","Quote from: I-am-not-anonymous on February 20, 2010, 01:06:02 AM"],["t","I know practically nothing about programming or coding. I'm interested in economics (as you might have guessed Smiley) and was trying to offer a bit of advice to the geeks who do the coding."]],"u":"https://bitcointalk.org/index.php?topic=57.msg408#msg408","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266633896,"b":[["q","> Quote from: NewLibertyStandard on February 19, 2010, 06:48:30 PM\n> As for the impending doom and gloom you're prophesying will accompany the decreased payout in a few years, all I have to do is add a little multiply by two to my exchange rate calculation and the problem is solved. The exchange rate stays constant and everyone is happy.\nCan you explain that part? I didn't understand how multiplying by two will achieve stability.","Quote from: Suggester on February 20, 2010, 01:15:18 AM"],["t","I use a formula to calculate my exchange rate which is described on my exchange rate page <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>. When I generate my first block of ฿25 rather than ฿50, I can simply change my formula to multiply bitcoins generated by two which will turn that ฿25 into ฿50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.\n\nI absolutely disagree that the current model is unsustainable and I absolutely disagree that people will not spend their bitcoins. If I had my druthers, the amount of bitcoins awarded would grow at the same rate as worldwide human population growth, but it doesn't matter because druthers are just druthers and they ain't important at all."]],"u":"https://bitcointalk.org/index.php?topic=57.msg409#msg409","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"Suggester","d":1266638186,"b":[["q","I use a formula to calculate my exchange rate which is described on my exchange rate page <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>. When I generate my first block of ฿25 rather than ฿50, I can simply change my formula to multiply bitcoins generated by two which will turn that ฿25 into ฿50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.","Quote from: NewLibertyStandard on February 20, 2010, 02:44:56 AM"],["t","OMG. The moment you do that you'll run out of coins immediately because buying them from you would cost only half as much as generating them!"],["q","I absolutely disagree that the current model is unsustainable and I absolutely disagree that people will not spend their bitcoins.","Quote from: NewLibertyStandard on February 20, 2010, 02:44:56 AM"],["t","Fine. But until someone answers the numerous doubts I've raised in here, I (and anyone with basic economics background) won't believe Bitcoin's current model has a promising future."],["q","If I had my druthers, the amount of bitcoins awarded would grow at the same rate as worldwide human population growth","Quote from: NewLibertyStandard on February 20, 2010, 02:44:56 AM"],["t","But I already explained why that was irrelevant. Oh well... nevermind."]],"u":"https://bitcointalk.org/index.php?topic=57.msg410#msg410","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"NewLibertyStandard","d":1266642771,"b":[["q","> Quote from: NewLibertyStandard on February 20, 2010, 02:44:56 AM\n> I use a formula to calculate my exchange rate which is described on my exchange rate page <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>. When I generate my first block of ฿25 rather than ฿50, I can simply change my formula to multiply bitcoins generated by two which will turn that ฿25 into ฿50 within my formula. Bitcoins are worth how much I say they are worth. If tomorrow I say they're all worth half as much as today then it would be so. Go ahead and create your own exchange service using your own formula to value bitcoins and you can have just as much control over the worth of bitcoins.\nOMG. The moment you do that you'll run out of coins immediately because buying them from you would cost only half as much as generating them!","Quote from: Suggester on February 20, 2010, 03:56:26 AM"],["t","I will always have dollars and bitcoins available to inject into my exchange service. I may run out today, but there will always be more available tomorrow. It's all detailed on my exchange rate page <http://newlibertystandard.wetpaint.com/page/Exchange+Rate>."],["q","Fine. But until someone answers the numerous doubts I've raised in here, I (and anyone with basic economics background) won't believe Bitcoin's current model has a promising future.","Quote from: Suggester on February 20, 2010, 03:56:26 AM"],["t","Fine. But regardless of whether someone answers the numerous doubts you've raised in here, I (and anyone with advanced economics background) will believe Bitcoin's current model has a promising future."]],"u":"https://bitcointalk.org/index.php?topic=57.msg411#msg411","sj":"Current Bitcoin economic model is sustainable"},{"f":"xc","d":1266647973,"b":[["t","Nothing to sweat people.  Nobody ever died of a 'deflationary spiral.'  Smiley  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.  \n\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.\n\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.\n\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.\n\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).\n\nXC"]],"u":"https://bitcointalk.org/index.php?topic=57.msg412#msg412","sj":"Re: Current Bitcoin economic model is unsustainable"},{"f":"satoshi","d":1266731064,"b":[["t","Excellent analysis, xc.\n\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.\n\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.\n\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.\n\nAt the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production."]],"u":"https://bitcointalk.org/index.php?topic=57.msg415#msg415","s":1,"n":65,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/65/","qt":["A 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.","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.","At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production."],"qc":["bitcoin-economics","economics"],"sj":"Re: Current Bitcoin economic model is unsustainable"}]},{"id":"p32","k":"p","s":"bitcointalk","t":"Number of connections","u":"https://bitcointalk.org/index.php?topic=58","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/32/","m":[{"f":"sirius","d":1266538376,"b":[["t","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..."]],"u":"https://bitcointalk.org/index.php?topic=58.msg403#msg403"},{"f":"satoshi","d":1266723828,"b":[["t","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.\n\nI don't know if there's any reason to have 15 connections.  Maybe it should be 10.\n\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.\n\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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=58.msg413#msg413","s":1,"n":63,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/63/"}]},{"id":"p33","k":"p","s":"bitcointalk","t":"Post your static IP","u":"https://bitcointalk.org/index.php?topic=59","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/33/","m":[{"f":"satoshi","d":1266725993,"b":[["t","It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works.  If you can accept incoming connections and you have a static IP address, post it here!\n\nAnything sent to these IPs should be considered a donation.  \n\nIf you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it'll be one-way.  They won't necessarily be watching for incoming transactions to send back."]],"u":"https://bitcointalk.org/index.php?topic=59.msg414#msg414","s":1,"n":64,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/64/"}]},{"id":"p34","k":"p","s":"bitcointalk","t":"UI improvements","u":"https://bitcointalk.org/index.php?topic=60","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/34/","m":[{"f":"satoshi","d":1266788881,"b":[["t","Uploaded some UI changes to SVN as version 0.2.5.\n\nInstead of View->Show Generated, we now have tabs:\n- All Transactions\n- Sent/Received\n- Sent\n- Received\n\nMakes it a lot easier to flip to received and check for payments.\n\nMoved the \"Your Addresses\" book inside the main address book.  It was confusing having two address books.\n\nI found the \"To:\" in \"From: unknown, To: (one of your bitcoin addresses)\" still confusing, so I changed it to \"From: unknown, Received with:\".  The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book.\n\nFixed a few UI glitches from the upgrade to wxWidgets 2.9.0.\n\nI haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing."]],"u":"https://bitcointalk.org/index.php?topic=60.msg426#msg426","s":1,"n":66,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/66/"},{"f":"Sabunir","d":1266789609,"b":[["t","These improvements sound good. Thank you for your continued development of the application. As a suggestion, you could consider shortening \"From: unknown, Received with:\" to \"From: unknown, Paid to:\""]],"u":"https://bitcointalk.org/index.php?topic=60.msg427#msg427"},{"f":"giik","d":1266869082,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=60.msg432#msg432"},{"f":"satoshi","d":1266887788,"b":[["t","There are now \"Sending\" and \"Receiving\" tabs in the Address Book.  Your addresses are referred to as \"receiving addresses\".\n\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.\n\nI think he had it working on FreeBSD, but he wanted a non-UI version.\n\nI have the command line and JSON-RPC daemon version working now.  Will SVN it in a day or two.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=60.msg434#msg434","s":1,"n":68,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/68/"},{"f":"sirius","d":1266926998,"b":[["t","In Ubuntu you can also switch to a non-graphical login screen by pressing ctrl + alt + F[1-8]."]],"u":"https://bitcointalk.org/index.php?topic=60.msg438#msg438"},{"f":"Xunie","d":1266928107,"b":[["t","And you can login to one of the TTY1-8 (what sirius-m was talking about) and execute /etc/init.d/gdm start and it will start gdm!"]],"u":"https://bitcointalk.org/index.php?topic=60.msg439#msg439"},{"f":"satoshi","d":1266944007,"b":[["q","/etc/init.d/gdm start and it will start gdm!","Quote from: Xunie on February 23, 2010, 12:28:27 PM"],["t","Ah yes, there we go, back to normal again.\n\nThe ctrl+alt+F[1-8] thing never worked on this computer.  The screen just goes haywire."]],"u":"https://bitcointalk.org/index.php?topic=60.msg446#msg446","s":1,"n":70,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/70/"}]},{"id":"p35","k":"p","s":"bitcointalk","t":"generation slowed down dramatically","u":"https://bitcointalk.org/index.php?topic=61","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/35/","m":[{"f":"m0mchil","d":1266844957,"b":[["t","Am I the only one seeing minuscule generation lately? It was decent until around 20:00 GMT February 21st, but after that my machine (4 core I7) produced only one block for entire >12 hours. And there isn't even a clue for new difficulty hike in the debug log.\n\nHere are my possible scenarios:\n\n1. Some big BC bot came along.\n\n2. Someone is trying some kind of DoSing the system.\n\n3. Someone built a bitcoin mod with GPGPU (CUDA or sorts) support.\n\n4. Some kind of growth problem (i.g. we reached first of a kind network size and there is problem with that).\n\nIdeas?"]],"u":"https://bitcointalk.org/index.php?topic=61.msg428#msg428"},{"f":"Sabunir","d":1266849580,"b":[["t","Ideas? I would want a copy of this hypothetical CUDA-enabled client. However, I doubt that GPGPU acceleration would affect generation speeds very much. Only the most expensive of modern graphics cards have a clock speed of over 1 Ghz, after all."]],"u":"https://bitcointalk.org/index.php?topic=61.msg429#msg429"},{"f":"NewLibertyStandard","d":1266867233,"b":[["t","No problem here. Other clients just happened to generate those blocks before you."]],"u":"https://bitcointalk.org/index.php?topic=61.msg431#msg431"},{"f":"satoshi","d":1266886196,"b":[["t","Just a random streak of bad luck.  It looks steady to me.\n\nCompetition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet.\n\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. \n\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."]],"u":"https://bitcointalk.org/index.php?topic=61.msg433#msg433","s":1,"n":67,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/67/"}]},{"id":"p36","k":"p","s":"bitcointalk","t":"Bitcoin Address Collisions","u":"https://bitcointalk.org/index.php?topic=62","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/36/","m":[{"f":"NewLibertyStandard","d":1266896804,"b":[["t","Although extremely unlikely, what would happen if two Bitcoin clients generated the same Bitcoin address? Would payments be delivered to whichever client encountered the payment first? If there is a mechanism in place to prevent such collisions, please explain it."]],"u":"https://bitcointalk.org/index.php?topic=62.msg435#msg435"},{"f":"ec","d":1266913517,"b":[["t","For two addresses to be equal, two identical private/public elliptical curve (ec Smiley) keys have to be generated. Without looking at the source code, let's assume the probability for this is 2^(-128) for a keyspace of 128 bits. See here <http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Random_UUID_probability_of_duplicates> for a perspective on how probable it is with a 122 bit collision.\n\nHowever, if something similar to the Debian ssl-scandal happens <http://lwn.net/Articles/282230/>, similar keys could indeed be generated. The effect of an individual generating an existing key, is (if I understand it correctly) in effect to make a copy of wallet.dat. Not good at all, but not devastating for all the members of the p2p network."]],"u":"https://bitcointalk.org/index.php?topic=62.msg436#msg436"},{"f":"NewLibertyStandard","d":1266916967,"b":[["t","Are you referring to the private key which is generated the first time a person runs Bitcoin? If someone were to successfully duplicate someone else's key then after they downloaded all the blocks, they would have the same balance as the person with the original key. That's what you're saying, right?\n\nI was referring to the custom Bitcoin addresses which you can label with the name of the person who is going to send you bitcoins so that you know from whom the payment came. I think these addresses are generated from the private key mentioned previously. I'm wondering about collisions because although they are very unique, they are easily generated over and over again by all by all bitcoin clients."]],"u":"https://bitcointalk.org/index.php?topic=62.msg437#msg437"},{"f":"ec","d":1266941876,"b":[["q","Are you referring to the private key which is generated the first time a person runs Bitcoin? If someone were to successfully duplicate someone else's key then after they downloaded all the blocks, they would have the same balance as the person with the original key. That's what you're saying, right?","Quote from: NewLibertyStandard on February 23, 2010, 09:22:47 AM"],["t","Yes, that is correct. They would share the wallet, and it becomes a race on spending the money first."],["q","I was referring to the custom Bitcoin addresses which you can label with the name of the person who is going to send you bitcoins so that you know from whom the payment came. I think these addresses are generated from the private key mentioned previously. I'm wondering about collisions because although they are very unique, they are easily generated over and over again by all by all bitcoin clients.","Quote from: NewLibertyStandard on February 23, 2010, 09:22:47 AM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=62.msg442#msg442"},{"f":"satoshi","d":1266942369,"b":[["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=62.msg443#msg443","s":1,"n":69,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/69/"},{"f":"NewLibertyStandard","d":1266951887,"b":[["t","Thanks for the explanation. I think it all makes sense.\n\nAre generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window? I may have mentioned this in an email message quite a while ago, but it would be cool for some very future version to allow people to see which of their bitcoins are encrypted with which of their addresses."]],"u":"https://bitcointalk.org/index.php?topic=62.msg450#msg450"},{"f":"satoshi","d":1266963840,"b":[["q","Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?","Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM"],["t","No, each generated transaction uses a new, single-use address.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=62.msg453#msg453","s":1,"n":72,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/72/"}]},{"id":"p37","k":"p","s":"bitcointalk","t":"Command Line and JSON-RPC","u":"https://bitcointalk.org/index.php?topic=63","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/37/","m":[{"f":"satoshi","d":1266963341,"b":[["t","Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC.\n\nOn Linux it needs libgtk2.0-0 installed, but does not need a GUI running.  Hopefully gtk can be installed without having a windowing system installed.\n\nThe command to start as a daemon is:\nbitcoin -daemon [switches...]\n\nOr, to run the UI normally and also be able to control it from command line or JSON-RPC, use the \"-server\" switch.\nbitcoin -server [switches...]\n\nWith either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332.  The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it's running under.\n\nTo control it from the command line, the interface is a command name without any switches, followed by parameters if any.\nbitcoin <command> [params...]\n\nFor example:\nbitcoin getinfo\nbitcoin getdifficulty\nbitcoin setgenerate true\nbitcoin stop\n\nIt's a simple JSON-RPC client and prints the JSON result.  Look at rpc.cpp for the list of commands.\n\nWeb apps or anything automated will normally use JSON-RPC directly, not command line.  There are JSON-RPC libraries for all the major languages.  In script languages like PHP and Python the syntax is as natural as calling a local function."]],"u":"https://bitcointalk.org/index.php?topic=63.msg452#msg452","s":1,"n":71,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/71/"},{"f":"The Madhatter","d":1266978557,"b":[["t","Oh thank you!\n\nYou have no idea how badly I needed something like this.\n\nI will have a payment library built in no time. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=63.msg459#msg459"},{"f":"theymos","d":1266980857,"b":[["q","On Linux it needs libgtk2.0-0 installed","Quote from: satoshi on February 23, 2010, 10:15:41 PM"],["t","Will this requirement be removed sometime? I'd rather not have to deal with GTK."]],"u":"https://bitcointalk.org/index.php?topic=63.msg467#msg467"},{"f":"sirius","d":1266981534,"b":[["t","Gtk is required by the GUI, so it must be linked if you want to use the same binary. Making a separate binary is another option, dunno how much code tweaking and ifdeffing that would take."]],"u":"https://bitcointalk.org/index.php?topic=63.msg468#msg468"},{"f":"The Madhatter","d":1266987645,"b":[["t","* madhatter2 pulls out razor sharp hex editor"]],"u":"https://bitcointalk.org/index.php?topic=63.msg478#msg478"},{"f":"satoshi","d":1266992243,"b":[["q","> Quote from: satoshi on February 23, 2010, 10:15:41 PM\n> On Linux it needs libgtk2.0-0 installed\nWill this requirement be removed sometime? I'd rather not have to deal with GTK.","Quote from: theymos on February 24, 2010, 03:07:37 AM"],["t","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. \n\nIt saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK."]],"u":"https://bitcointalk.org/index.php?topic=63.msg482#msg482","s":1,"n":74,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/74/"},{"f":"The Madhatter","d":1266993517,"b":[["t","*NIX peoples are \"purists\" of sorts. They don't like to pollute their OS installs with libraries that shouldn't be necessary.\n\nA million ifdefs are not the answer either. Hmm.. more thought to this may be required."],["q","> Quote from: theymos on February 24, 2010, 03:07:37 AM\n> > Quote from: satoshi on February 23, 2010, 10:15:41 PM\n> > On Linux it needs libgtk2.0-0 installed\n> Will this requirement be removed sometime? I'd rather not have to deal with GTK.\nHow 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. \n\nIt saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK.","Quote from: satoshi on February 24, 2010, 06:17:23 AM"]],"u":"https://bitcointalk.org/index.php?topic=63.msg483#msg483"},{"f":"theymos","d":1266994300,"b":[["t","I'm using Linux From Scratch, so installing a dependency-ridden package like GTK would be a bit of a pain. Why should I add a dozen additional packages and hundreds of megabytes to my system when BitCoin doesn't even use them?"]],"u":"https://bitcointalk.org/index.php?topic=63.msg488#msg488"},{"f":"The Madhatter","d":1266998178,"b":[["t","Why would you install them? Because you currently have to. I know the feeling. I run minimalist FreeBSD servers and to clutter them with X libraries is a pain.\n\nHowever, installing them onto a X workstation is totally fine -- you usually have all of the correct dependancies already. Tongue"]],"u":"https://bitcointalk.org/index.php?topic=63.msg493#msg493"},{"f":"sirius","d":1267035455,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=63.msg502#msg502"},{"f":"satoshi","d":1267049335,"b":[["t","When and how fast did memory usage increase?  Right away, slowly over a long time, or starting at some later event?\n\nI have -daemon running on ubuntu 9.10 64-bit and memory usage is steady.\n\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. "]],"u":"https://bitcointalk.org/index.php?topic=63.msg509#msg509","s":1,"n":77,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/77/"},{"f":"sirius","d":1267115537,"b":[["t","It started increasing right away. I'll see if valgrind can help me."]],"u":"https://bitcointalk.org/index.php?topic=63.msg538#msg538"},{"f":"satoshi","d":1267138457,"b":[["t","OK, I made a build target bitcoind that only links wxBase and does not link GTK.  Version 0.2.7 on SVN.\n\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."],["q","It started increasing right away. I'll see if valgrind can help me.","Quote from: sirius-m on February 25, 2010, 04:32:17 PM"],["t","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.\n\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.\n\nI suspect bitcoind will probably work fine, but I hope you can still debug the problem."]],"u":"https://bitcointalk.org/index.php?topic=63.msg539#msg539","s":1,"n":80,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/80/"},{"f":"theymos","d":1267175912,"b":[["t","I'm getting errors when trying to compile with just wxBase."],["c","g++ -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,\n                 from 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"],["t","Clipbrd.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."]],"u":"https://bitcointalk.org/index.php?topic=63.msg553#msg553"},{"f":"satoshi","d":1267201761,"b":[["t","wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI.\n\nUpdated headers.h on SVN.\n\nSorry, I linked to wxbase but I had full wxWidgets on my computer.\n\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?\n\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\n\nI suppose they might have added exists recently, using get before that."]],"u":"https://bitcointalk.org/index.php?topic=63.msg555#msg555","s":1,"n":82,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/82/"},{"f":"theymos","d":1267203534,"b":[["t","I'm using Berkeley DB 4.5.20."]],"u":"https://bitcointalk.org/index.php?topic=63.msg557#msg557"},{"f":"theymos","d":1267213070,"b":[["t","Using DB-4.7.25 fixed that problem.\n\nI'm now getting this error, though:"],["c","g++ -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"]],"u":"https://bitcointalk.org/index.php?topic=63.msg558#msg558"},{"f":"satoshi","d":1267228124,"b":[["t","Are you using wxWidgets 2.9.0?  I don't recommend using anything other than 2.9.0.\n\nIt looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase.\n\nRemoving -D__WXDEBUG__ from bitcoin's makefile would probably solve it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=63.msg562#msg562","s":1,"n":84,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/84/"},{"f":"Cdecker","d":1267240883,"b":[["t","The headless mode is incredibly usefull. Finally I can start generating on my servers in the night Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=63.msg564#msg564"},{"f":"theymos","d":1267255111,"b":[["t","Cool; it works! Grin Thanks for your help!\n\nI am using 2.9.0.\n\n(No memory issues for me.)"]],"u":"https://bitcointalk.org/index.php?topic=63.msg568#msg568"},{"f":"The Madhatter","d":1267544802,"b":[["t","That wchar thing was what I was stuck on for the OSX build. Cheesy\n\nGlad to see it is ironed out. I'll keep hacking away now."]],"u":"https://bitcointalk.org/index.php?topic=63.msg603#msg603"},{"f":"satoshi","d":1267753585,"b":[["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.","Quote from: sirius-m on February 24, 2010, 06:17:35 PM"],["t","sirius-m debugged this, it was 64-bit related. \n\nThe fix is now available on SVN, file util.cpp."]],"u":"https://bitcointalk.org/index.php?topic=63.msg633#msg633","s":1,"n":89,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/89/"}]},{"id":"p38","k":"p","s":"bitcointalk","t":"New icon/logo","u":"https://bitcointalk.org/index.php?topic=64","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/38/","m":[{"f":"satoshi","d":1267046663,"b":[["t","New icons, what do you think?  Better than the old one?\n\n      \n\nFull size 530x529 image for scaling down to custom sizes:\nhttp://www.bitcoin.org/download/bitcoin530.png\n\nThe perspective shadow was too thick on the larger sizes.  I updated 32, 48 and the full size.\n\nI release these images into the public domain (copyright-free).  I request that derivative works be made public domain."]],"u":"https://bitcointalk.org/index.php?topic=64.msg504#msg504","s":1,"n":75,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/75/"},{"f":"ihrhase","d":1267047149,"b":[["t","Pretty..."]],"u":"https://bitcointalk.org/index.php?topic=64.msg506#msg506","sj":"Re: New icons"},{"f":"Sabunir","d":1267062476,"b":[["t","I like them. Do they come in higher resolutions?"]],"u":"https://bitcointalk.org/index.php?topic=64.msg519#msg519"},{"f":"satoshi","d":1267062984,"b":[["q","I like them. Do they come in higher resolutions?","Quote from: Sabunir on February 25, 2010, 01:47:56 AM"],["t","Yes, the original is 546x531 pixels.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=64.msg521#msg521","s":1,"n":79,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/79/"},{"f":"SmokeTooMuch","d":1267063287,"b":[["t","I still dislike the currency symbol ... But at least the logos look good and clean."]],"u":"https://bitcointalk.org/index.php?topic=64.msg523#msg523"},{"f":"Sabunir","d":1267064929,"b":[["q","> Quote from: Sabunir on February 25, 2010, 01:47:56 AM\n> I like them. Do they come in higher resolutions?\nYes, the original is 546x531 pixels.","Quote from: satoshi on February 25, 2010, 01:56:24 AM"],["t","Excellent. This would be a good resource for those participating in the banner contest. Why unequal dimensions?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=64.msg525#msg525"},{"f":"satoshi","d":1267226239,"b":[["t","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.\n\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.\n\nIt's slightly wider than tall because the dark perspective under it goes more to the right than down.\n\nI finished and posted the 32x31 and 48x47 versions in the first message.  I like the 48 a lot.\n\nHow does everyone feel about the B symbol with the two lines through the outside?  Can we live with that as our logo?"]],"u":"https://bitcointalk.org/index.php?topic=64.msg561#msg561","s":1,"n":83,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/83/","qt":["How does everyone feel about the B symbol with the two lines through the outside?  Can we live with that as our logo?"],"qc":["bitcoin-design"]},{"f":"ihrhase","d":1267240362,"b":[["t","Works for me..."]],"u":"https://bitcointalk.org/index.php?topic=64.msg563#msg563"},{"f":"Cdecker","d":1267241047,"b":[["t","How about an SVG version? That way we could automatically generate smaller and larger versions as needed, and storage in the Source Control Management is an option too."]],"u":"https://bitcointalk.org/index.php?topic=64.msg565#msg565"},{"f":"satoshi","d":1267244909,"b":[["q","How about an SVG version? That way we could automatically generate smaller and larger versions as needed.","Quote from: Cdecker on February 27, 2010, 03:24:07 AM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=64.msg566#msg566","s":1,"n":85,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/85/"},{"f":"giik","d":1267427340,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=64.msg584#msg584"},{"f":"satoshi","d":1267497185,"b":[["t","We have the standard icon sizes, and the full size scales nicely to anything else.\n\nI added the full size to the first post."]],"u":"https://bitcointalk.org/index.php?topic=64.msg588#msg588","s":1,"n":87,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/87/"},{"f":"Sabunir","d":1267503401,"b":[["t","Thank you. I have updated my \"Accept Bitcoin\" buttons <http://bitcointalk.org/index.php?topic=45.msg479#msg479> and banner <http://bitcointalk.org/index.php?topic=45.msg547#msg547> (version twos) to use your new coin."]],"u":"https://bitcointalk.org/index.php?topic=64.msg590#msg590"},{"f":"Bitquux","d":1280424718,"b":[["t","Here's a vector graphic (SVG). I'm no expert, so it may not be optimal, but it should work for the most part.\n\nhttp://www.shalhoon.com/bitcoin.svg\n\n(You may need to right-click and \"Save As...\" if your browser thinks it knows how to display it)."]],"u":"https://bitcointalk.org/index.php?topic=64.msg6435#msg6435"},{"f":"Bitquux","d":1280425823,"b":[["t","After some toying, this one seems a bit more crisp.\n\nhttp://www.shalhoon.com/bitcoin2.svg"]],"u":"https://bitcointalk.org/index.php?topic=64.msg6438#msg6438"},{"f":"tcatm","d":1280889116,"b":[["t","I also made an SVG version. It's not as shiny as the original logo, though."]],"u":"https://bitcointalk.org/index.php?topic=64.msg7415#msg7415"},{"f":"ArrowJ","d":1288678874,"b":[["t","Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.\n\nThere is at least one other thread with a set of logos and badges that are really, really promising here: http://bitcointalk.org/index.php?topic=1631.0 I promise I don't know this guy/gal (I didn't even check the username). Heck if someone else came up with another alternative that would be cool too. It seems important that we have a really nice logo with all the sizes, resolutions, and formats that might be needed.\n\nIs there a reason we couldn't adopt something else before bitcoin gets too big and it's too late to change without hurting \"brand\" recognition? It seems silly to stick with something that is \"ok\" when we could have something great.\n\nI hope I didn't step on anyone's toes to badly. "]],"u":"https://bitcointalk.org/index.php?topic=64.msg19658#msg19658"},{"f":"Anonymous","d":1288682425,"b":[["q","Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.\n\nThere is at least one other thread with a set of logos and badges that are really, really promising here: http://bitcointalk.org/index.php?topic=1631.0 I promise I don't know this guy/gal (I didn't even check the username). Heck if someone else came up with another alternative that would be cool too. It seems important that we have a really nice logo with all the sizes, resolutions, and formats that might be needed.\n\nIs there a reason we couldn't adopt something else before bitcoin gets too big and it's too late to change without hurting \"brand\" recognition? It seems silly to stick with something that is \"ok\" when we could have something great.\n\nI hope I didn't step on anyone's toes to badly.","Quote from: ArrowJ on November 02, 2010, 06:21:14 AM"],["t","Satoshi created bitcoin so that is his preferred one hence it is the \"official\" one. The project is open source so if you can come up with something better people will adopt it. Thats the nature of things and of bitcoin itself.\n\nWhat exactly is your issue with the \"official\" logo?"]],"u":"https://bitcointalk.org/index.php?topic=64.msg19664#msg19664"},{"f":"srb123","d":1288694362,"b":[["t","ArrowJ is right, image is everything, and its best left to the Pro's. (i.e. Not me.)\n\nThat said, the name \"Bitcoin\" is pretty uninspiring start for a Graphic Designer, IMO. (But that is a whole other discussion.)\n\nKudos to Bitboy on his contribution, this kind of simple smooth and sharp image instantly tells the viewer that we are in 2010."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19669#msg19669"},{"f":"ShadowOfHarbringer","d":1288694779,"b":[["q","Is this the \"official\" logo? I understand how difficult it can be to make something truly professional when you don't have the skills (which I don't) or the software (which I also don't) so I'm not trying to be rude, but wouldn't it be better if we adopted something...better? I really am not trying to be mean...I really have struggled trying to figure out how to do the stuff that a lot of the artists on deviant do.","Quote from: ArrowJ on November 02, 2010, 06:21:14 AM"],["t","Stop complaining. The current logo is just good enough.\nIt has all the properties a good logo should have.\n\nPS.\nAfter bitcoin goes mainstream, satoshi will be incredibly rich and he can afford some professional artist to polish it more Wink\n\nPS2.\nAfter some consideration, i think that the logo could be easily polished a little by adding some more 3D-effect to the coin borders, so it would actually look like a real coin. But the rest is 100% OK."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19670#msg19670"},{"f":"ArrowJ","d":1288729251,"b":[["q","...The project is open source so if you can come up with something better people will adopt it...","Quote"],["t","I don't personally have the skills, but again, I think http://bitcointalk.org/index.php?topic=1631.0 is a great choice."],["q","\"What exactly is your issue with the \"official\" logo?\"","Quote"],["t","The most recent version isn't as bad as the original, but it is still not a crisp as could be desired, it doesn't scale well, has too many color shades, just has an overall \"generic\" look to it."],["q","Stop complaining. The current logo is just good enough.\nIt has all the properties a good logo should have.","Quote"],["t","I'm not actually complaining...just voicing an alternative opinion related to the quality of the current logo that represents the bitcoin project to most of the outside world. I feel it has few of the aesthetic properties a good logo should have.\n\nI don't see why this can't be discussed without being offensive (I'm trying not to attack anyone personally). I'm not saying anything about the qualities of the designer as a human being...he did after all come up with the cool idea of Bitcoin in the first place, but this does not mean his artwork should be the de facto face of the project IF the goal is to increase it's popularity. It seems to me that the better face we can put on the project the better. Is it bad to strive for fantastic?"],["q","After some consideration, i think that the logo could be easily polished a little by adding some more 3D-effect to the coin borders, so it would actually look like a real coin. But the rest is 100% OK.","Quote"],["t","I personally think less 3D is in order. It's ok for it to be \"abstract\" in that it doesn't look exactly like a coin...I would posit that it would be better if it doesn't try to look like a real coin...after all, we aren't dealing in real coins...we are dealing in BITcoins Wink"]],"u":"https://bitcointalk.org/index.php?topic=64.msg19720#msg19720"},{"f":"ShadowOfHarbringer","d":1288730450,"b":[["q","I don't see why this can't be discussed without being offensive (I'm trying not to attack anyone personally). I'm not saying anything about the qualities of the designer as a human being...","Quote from: ArrowJ on November 02, 2010, 08:20:51 PM"],["t","Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.\n\nYou're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.\nHowever i don't know if Satoshi will like the license (cc by-sa).\n\nIMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19723#msg19723"},{"f":"ArrowJ","d":1288731090,"b":[["q","Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.\n\nYou're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.\nHowever i don't know if Satoshi will like the license (cc by-sa).\n\nIMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain.","Quote"],["t","I'll be honest with you, I thought I had offended with the suggestion.\n\nI hadn't thought of the license issue, but of course your right, whatever logo is used it should probably be public domain. IF the community decided to adopt Bitboy's logo I'd contribute 5 btc to \"buy out\" his license and turn it over to the public domain.\n\nCan this sort of thing be settled with a vote or does it not work that way? I mean we can say it's open source and whatever people use will win, but you have to admit Satoshi's logo has a little bit of an advantage...nobody wants to offend the originator of the awesome idea...I don't want to anyhow...hope I haven't!"]],"u":"https://bitcointalk.org/index.php?topic=64.msg19725#msg19725"},{"f":"Anonymous","d":1288739296,"b":[["q","> Quote\n> Oh sorry, was i offensive again ? That's weird, i didn't feel it at all.\n>\n> You're right, actually the logo from my signature (designed by bitboy and improved by myself) may be better than the official one.\n> However i don't know if Satoshi will like the license (cc by-sa).\n>\n> IMHO perhaps Satoshi should either ask the author or pay the author some BTC to release the works into public domain.\n\nI'll be honest with you, I thought I had offended with the suggestion.\n\nI hadn't thought of the license issue, but of course your right, whatever logo is used it should probably be public domain. IF the community decided to adopt Bitboy's logo I'd contribute 5 btc to \"buy out\" his license and turn it over to the public domain.\n\nCan this sort of thing be settled with a vote or does it not work that way? I mean we can say it's open source and whatever people use will win, but you have to admit Satoshi's logo has a little bit of an advantage...nobody wants to offend the originator of the awesome idea...I don't want to anyhow...hope I haven't!","Quote from: ArrowJ on November 02, 2010, 08:51:30 PM"],["t","The licence should  be the same as the original logo imo because we know for sure that is the one satoshi supports. "]],"u":"https://bitcointalk.org/index.php?topic=64.msg19751#msg19751"},{"f":"ArrowJ","d":1288742323,"b":[["t","Is that a requirement for an open source project though?"]],"u":"https://bitcointalk.org/index.php?topic=64.msg19766#msg19766"},{"f":"ribuck","d":1288783621,"b":[["q","Is that a requirement for an open source project though?","Quote from: ArrowJ on November 02, 2010, 11:58:43 PM"],["t","No, just for this open source project, i.e. Satoshi's Bitcoin client."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19810#msg19810"},{"f":"Anonymous","d":1288784137,"b":[["q","Is that a requirement for an open source project though?","Quote from: ArrowJ on November 02, 2010, 11:58:43 PM"],["t","No its not...but you'd be more likely to get satoshi to support something we know he approves of!"]],"u":"https://bitcointalk.org/index.php?topic=64.msg19811#msg19811"},{"f":"ArrowJ","d":1288794293,"b":[["t","Understood. I had a friend explain some of the ideology a little more clearly to me. Bottom line, I hope we can end up with a top notch professional logo for this project."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19854#msg19854"},{"f":"FreeMoney","d":1288801882,"b":[["q","I personally think less 3D is in order. It's ok for it to be \"abstract\" in that it doesn't look exactly like a coin...I would posit that it would be better if it doesn't try to look like a real coin...after all, we aren't dealing in real coins...we are dealing in BITcoins Wink","Quote from: ArrowJ on November 02, 2010, 08:20:51 PM"],["t","Haha, I agree. Maybe it should be a holo-coin."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19865#msg19865"},{"f":"LZ","d":1288804727,"b":[["t","I like icons that Satoshi published in the first post."]],"u":"https://bitcointalk.org/index.php?topic=64.msg19870#msg19870"},{"f":"satoshi","d":1289609751,"b":[["t","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.\n\nIt'll be a lot simpler if authors could make their graphics public domain."]],"u":"https://bitcointalk.org/index.php?topic=64.msg21766#msg21766","s":1,"n":500,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/500/","qt":["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. It'll be a lot simpler if authors could make their graphics public domain."],"qc":["bitcoin-design"]}]},{"id":"p39","k":"p","s":"bitcointalk","t":"wxWidgets 2.9.0","u":"https://bitcointalk.org/index.php?topic=65","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/39/","m":[{"f":"Cdecker","d":1267290599,"b":[["t","I'm currently trying to get BitCoin to compile on the openSuse Build Service, which would allow us to create a wide range of precompiled packages for a variety of distros but I'm continually running into problems. The most important of them is the wxWidgets 2.9.0 requirement which is incredibly hard to provide, and the source of many of the problems described on the Forum. Why is it so important to have a 2.9.0? Looking through the source of 2.8.10 it appears that unicode is possible with that version too.\n\nRegards,\ncdecker"]],"u":"https://bitcointalk.org/index.php?topic=65.msg569#msg569"},{"f":"satoshi","d":1267305773,"b":[["q","Looking through the source of 2.8.10 it appears that unicode is possible with that version too.","Quote from: Cdecker on February 27, 2010, 05:09:59 PM"],["t","In the Windows world, \"unicode\" means UTF-16 (wchar).\n\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.\n\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.\n\nMake sure you read build-unix.txt and configure wxWidgets using the configure parameters given.\n\nCurious, why is it incredibly hard to provide wxWidgets 2.9.0?  If you mean for users, that's why we static link it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=65.msg571#msg571","s":1,"n":86,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/86/"}]},{"id":"p40","k":"p","s":"bitcointalk","t":"Money Transfer Regulations","u":"https://bitcointalk.org/index.php?topic=69","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/40/","m":[{"f":"NewLibertyStandard","d":1267514530,"b":[["t","Does anyone happen to know what kinds of regulations are in place for people who buy and sell unofficial digital currencies such as Bitcoin? I'm particularly interested in United States regulations, but please mention any regulations of which you are aware.\n\nRegistering a business or non-profit organization gives the advantage of being able to do transactions in the name of the business <http://en.wikipedia.org/wiki/Doing_business_as> and forming a corporation limits liability <http://en.wikipedia.org/wiki/Limited_liability_company>. But it seems like it would be more trouble than it's worth to incorporate or register a business until the profits are large enough to hire employees.\n\nI noticed that in the United States, financial institutions are required to submit a currency transaction report <http://en.wikipedia.org/wiki/Currency_Transaction_Report> for all transactions over $10,000 and a suspicious activity report <http://en.wikipedia.org/wiki/Suspicious_activity_report> for suspicious transactions. I don't think a private citizen would be required to submit either type of report. In any case, so long as the official currency part of the transaction is passing through a registered financial institution, the institution would already be submitting those reports for such transactions.\n\nI have read about money laundering <http://en.wikipedia.org/wiki/Money_laundering> and it seems that so long as a person is not knowingly laundering money, then the person is not committing the crime.\n\nProfits would need to be tracked for tax purposes but that can be accomplished easily enough using accounting software such as GnuCash <http://www.gnucash.org/>.\n\nAm I missing anything? Are there any regulations prohibiting me from sending money to and receiving money from random strangers who may be criminals unbeknownst to me?"]],"u":"https://bitcointalk.org/index.php?topic=69.msg592#msg592"},{"f":"theymos","d":1267515963,"b":[["t","http://en.wikipedia.org/wiki/E-gold"],["q","In 2007 the proprietors of the e-gold service were indicted by the United States Department of Justice on four counts of violating money laundering regulations. In July 2008 the company and its three directors pled guilty to charges of \"conspiracy to engage in money laundering\" and the \"operation of an unlicensed money transmitting business\" in the U.S. District Court for D.C.  The company faces fines of $3.7 million.","Quote"],["t","Running an exchange seems very dangerous. I would never do it without talking to a lawyer and setting up a LLC."]],"u":"https://bitcointalk.org/index.php?topic=69.msg593#msg593"},{"f":"NewLibertyStandard","d":1267520513,"b":[["t","Thanks for the reply. I agree that running an exchange does seem dangerous. I have started extremely small and limited my service so that if I am doing something wrong it will hopefully be so minor that I won't be prosecuted and so that if I am convicted of something the fines will be small enough to hopefully not bankrupt me.\n\nI've looked at that E-gold article before but this time I read it, I thought to look up some terms mentioned in it which turned up some interesting regulations concerning registration of money transmitting businesses <http://www.law.cornell.edu/uscode/31/usc_sec_31_00005330----000-.html> and prohibition of unlicensed money transmitting businesses <http://www.law.cornell.edu/uscode/18/1960.html>. I don't know whether my tiny service qualifies as an unlicensed money transmitting business, but if it does, I'll stop until I can get it registered. Although if there's a large non-refundable application fee, I'll have to re-evaluate whether it's worth the cost since I'm currently not trying to earn a profit."]],"u":"https://bitcointalk.org/index.php?topic=69.msg597#msg597"},{"f":"ihrhase","d":1267539238,"b":[["t","NLS, there is no \"legal\" way to do what you are looking to do on a large scale, knowledge is not necessary for indictment...\n\nYou are providing a tax shelter, you should automatically factor in illicit to your \"hobby\""]],"u":"https://bitcointalk.org/index.php?topic=69.msg599#msg599"},{"f":"The Madhatter","d":1267544341,"b":[["t","Nah.. you guys have it wrong.\n\nIt isn't the written law that you should be concerned with.\n\nYou need to rely on your courts to make the 'fair and just' decisions. That is the real problem. I wouldn't dream of running any sort of \"money transmitting business\" (their term) or currency exchange in the USA. (See e-gold and liberty dollar.)\n\nIt is probably best to run your exchanger from a different country than the one in which you reside. That would involve a corporation or trustee.\n\n($10,000 OR any \"suspicious\" transaction. That is subject to OPINION.. very open-ended if you ask me. So a court proceeding on failure to report based on suspicion would boil down to \"he who can afford to put forth the most motions in court\"... lol)\n\nAnother option is an estoppel. (Again, you need to really know what you are doing.)\n\nCheers! Tongue"]],"u":"https://bitcointalk.org/index.php?topic=69.msg601#msg601"},{"f":"NewLibertyStandard","d":1267566777,"b":[["t","Here's the legal definition of currency, 31 C.F.R. § 103.11(h) <http://www.fdic.gov/regulations/laws/rules/8000-1400.html#fdic8483> and the legal definition of a currency dealer or exchanger, 31 C.F.R. § 103.11(uu)(1) <http://www.fdic.gov/regulations/laws/rules/8000-1400.html#fdic8486> (both links take you slightly above the definitions). My lawyer friend indicated that that my service seems legal, but that's absolutely not legal advice for you folks. I'm running my little service as honestly and as legally as I know how, so until I find out that I'm doing something wrong, I'm not going to stop."]],"u":"https://bitcointalk.org/index.php?topic=69.msg609#msg609"},{"f":"The Madhatter","d":1267583122,"b":[["t","Don't forget to look at state money transmitting licenses. That's what killed Goldage. (They were one of the largest e-gold exchangers). They were unlicensed because that thought that digital gold was outside the jurisdiction (not legal tender) of the state/federal governments. The state laws were vague enough, and law enforcement was ignorant enough, that they were prosecuted by the state of New York.\n\n(See: http://en.wikipedia.org/wiki/Goldage)\n\nLots of people speculate that they were prosecuted for political reasons and not for \"legal\" ones. The central banks (and therefore the governments under their economic debt rule) do not want competing currencies. This isn't because it is competition (e-gold was soooo small compared to the FRN paper game). They didn't want e-gold to open up people's mind to the idea of alternate currencies. That is a far bigger threat.\n\nRemember that a license is an act of privilege that can be revoked/regulated. I firmly believe that any action that you can purchase a license for is fundamentally lawful. (Ex: you can't buy a license to commit a crime. No \"license to kill\", Bond. Tongue).\n\nIt is possible to claim lawful excuse to operate unlicensed. (By pronouncement or claim by right of notary.. again, you need to know what you are doing.)\n\nPeace!"]],"u":"https://bitcointalk.org/index.php?topic=69.msg610#msg610"},{"f":"ihrhase","d":1267586131,"b":[["t","Remember NLS\n\nThere are two types of law...\n\nThe Law you can read, and the one the government chooses to apply to you...\n\nYour Lawyer friends may be right, but so were joe stack's and he got prosecuted..."]],"u":"https://bitcointalk.org/index.php?topic=69.msg611#msg611"},{"f":"I-am-not-anonymous","d":1267588113,"b":[["q","Remember NLS\n\nThere are two types of law...\n\nThe Law you can read, and the one the government chooses to apply to you...\n\nYour Lawyer friends may be right, but so were joe stack's and he got prosecuted...","Quote from: ihrhase on March 03, 2010, 03:15:31 AM"],["t","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!\n\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.\n\nHowever---\n\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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=69.msg612#msg612"},{"f":"satoshi","d":1267590536,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=69.msg614#msg614","s":1,"n":88,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/88/"}]},{"id":"p41","k":"p","s":"bitcointalk","t":"bitcoin auto-renice-ing","u":"https://bitcointalk.org/index.php?topic=72","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/41/","m":[{"f":"fergalish","d":1268040596,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=72.msg673#msg673"},{"f":"satoshi","d":1268678652,"b":[["t","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\n#define THREAD_PRIORITY_LOWEST          PRIO_MIN\n#define THREAD_PRIORITY_BELOW_NORMAL    2\n#define THREAD_PRIORITY_NORMAL          0\n\nThe priorities converted from Windows priorities were probably from a table like this:\n\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.\n\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\"\n\nIf you have better values, suggestions welcome.\n\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\n    // threads are processes on linux, so PRIO_PROCESS affects just the one thread\n    setpriority(PRIO_PROCESS, getpid(), nPriority);"]],"u":"https://bitcointalk.org/index.php?topic=72.msg717#msg717","s":1,"n":90,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/90/"},{"f":"asdfman","d":1278921957,"b":[["t","Hello,\n\nThis same behavior was bugging me too.. I would renice all the threads to 19, as it was interrupting system responsiveness since bitcoind was taking priority, but every so often the program would automatically reset the priority to something that would disrupt system responsiveness ..\nso what I did was just edit util.h\nand change the function that manipulates the priority:\n\ninline void SetThreadPriority(int nPriority)\n{\n    printf(\"No, were not changing any damn priority\");\n}\n\nand then recompiled bitcoind\n\nnow I just renice all the threads once, and they are stuck at what I set them to until program exit (NI column staying at 19):"],["c","   1  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Time: 03:59:40\n  2  [||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]     Uptime: 253 days(!), 01:12:27\n  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||501/1255MB]     Load: 4.01\n  Swp[||||||||||||||||||||||||||||||||||||||||||||||||||||||                                            501/1004MB]     Load average: 4.01 4.15 3.49\n         __   __         __   __        __  __   __         __   __         __   __         __   __                             __  __              __\n        |  | |__         __| |__       |__||__  |__|       |  | |  |       |  | |  |       |  | |  |                            __| __|   |           |\n  Avg:  |__|.|__|% sy:  |__ . __|% ni:  __||__|.|__|% hi:  |__|.|__|% si:  |__|.|__|% wa:  |__|.|__|%                   Tasks:  __| __|   | total,    | running\n\n  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command\n\n 4523 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.66  `- bitcoind -gen -daemon\n 4534 root      39  19  126M 46280  3424 R 90.0  3.6 12:43.73  |   `- bitcoind -gen -daemon\n 4533 root      39  19  126M 46280  3424 R 45.0  3.6 10:49.02  |   `- bitcoind -gen -daemon\n 4532 root      39  19  126M 46280  3424 R 46.0  3.6 10:05.83  |   `- bitcoind -gen -daemon\n 4531 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.03  |   `- bitcoind -gen -daemon\n 4530 root      39  19  126M 46280  3424 S  1.0  3.6  0:15.53  |   `- bitcoind -gen -daemon\n 4529 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.72  |   `- bitcoind -gen -daemon\n 4527 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.02  |   `- bitcoind -gen -daemon\n 4526 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.03  |   `- bitcoind -gen -daemon\n 4525 root      39  19  126M 46280  3424 S  0.0  3.6  0:00.06  |   `- bitcoind -gen -daemon"],["t","in my debug.log:\n\n[root@raidserv] (~/.bitcoin)# grep \"No,\" debug.log\nNo, were not changing any damn priority\nNo, were not changing any damn priority\nNo, were not changing any damn priority\nNo, were not changing any damn priority\n...\n\nSo now I can leave bitcoind running all day long without me noticing much..."]],"u":"https://bitcointalk.org/index.php?topic=72.msg2268#msg2268"},{"f":"asdfman","d":1278922874,"b":[["t","I think that this might be a bug... http://bitcointalk.org/index.php?topic=285.0"]],"u":"https://bitcointalk.org/index.php?topic=72.msg2272#msg2272"},{"f":"lachesis","d":1278975768,"b":[["t","Asdfman, what program is generating that output? I like it Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=72.msg2413#msg2413"},{"f":"asdfman","d":1278976284,"b":[["t","lachesis - htop\nits awesome.. has ANSI colors, you can fully configure it to display all threads, tree view, etc ,etc"]],"u":"https://bitcointalk.org/index.php?topic=72.msg2416#msg2416"},{"f":"satoshi","d":1279129111,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=72.msg2886#msg2886","s":1,"n":182,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/182/"}]},{"id":"p42","k":"p","s":"bitcointalk","t":"Idea for file hosting and proxy services","u":"https://bitcointalk.org/index.php?topic=83","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/42/","m":[{"f":"satoshi","d":1268680616,"b":[["t","When you want to upload an image to embed in a forum post, there are services like imageshack, but because they're free, they limit the number of views.  It's a minuscule amount of bandwidth cost, but they can't just give it away for free, there has to be something in it for them.  It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.\n\nIt's worse if you want to upload a file for others to download.  There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.\n\nIt would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins.  Anyone with some extra bandwidth quota could throw it on their webserver and run it.  Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles.  Ideally, it should be MIT license or public domain.\n\nServices like this would be great for anonymous users, who have trouble paying for things."]],"u":"https://bitcointalk.org/index.php?topic=83.msg719#msg719","s":1,"n":91,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/91/"},{"f":"BitcoinFX","d":1268734675,"b":[["t","Good idea.\n\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.\n\nI'm UK based so it will be good for using BBC iplayer etc. Smiley I will be giving bitcoin users priority service, as well as users from 'restricted' countries.\n\nI doubt I'll have the spare bandwidth for a file hosting service though, maybe."]],"u":"https://bitcointalk.org/index.php?topic=83.msg728#msg728","sj":"Re: Idea for file hosting service"},{"f":"satoshi","d":1268770654,"b":[["t","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.\n\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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=83.msg731#msg731","s":1,"n":93,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/93/","sj":"Re: Idea for file hosting service"},{"f":"dwdollar","d":1268914924,"b":[["t","There are a ton of Python options for web frameworks.  I'm in the process of learning CherryPy, and I'm new to web development, so it's slow going.  Looks like they have an example for basic uploading.  Something in PHP would probably be best for the community though.  Are there any Python people here?"]],"u":"https://bitcointalk.org/index.php?topic=83.msg751#msg751","sj":"Re: Idea for file hosting service"},{"f":"BitcoinFX","d":1268923010,"b":[["t","Yes. Any built proxy implementation would be open source and automated bitcoin payments would be great.\n\nI will post the psiphon info. and links because the project has just moved from v1 to v2 and the implementations are very different.\n\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\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.\n\nLicense: GNU General Public License\nSource code: http://psiphon.ca/download/psiphon-src-1.6.tar.gz\n\nhttp://wikipedia.org/wiki/Psiphon\n\nhttp://psiphon.ca/\n\nhttps://launchpad.net/psiphon\n\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.\n\nPlease contact the project leader if you're interested in helping us take Psiphon forward.\n\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.\n\nThe new project is Psiphon 2.x, a centrally managed web proxy system deployed by Psiphon Inc. to provide censorship circumvention services.\"\n\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.\n\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;\n\nSSL - http://www.slproweb.com/products/Win32OpenSSL.html\n\nVisual C++ 2008 Redistributables for msvcpXX.dll and msvcrXX.dll\n\nhttp://www.sqlite.org/download.html\n\nPrecompiled Binaries For Windows for sqlite3.dll\n\nJava and some flash support is always an issue though !\n\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 ?\n\nI understand that the Tor project is also looking for a payment / incentive system for it's server operators. Smiley\n\nCould you change the thread title to \"Re: Idea for file hosting and proxy services\". Thanks.\n\nRegards,\n\nBitcoinFX"]],"u":"https://bitcointalk.org/index.php?topic=83.msg752#msg752","sj":"Re: Idea for file hosting service"},{"f":"satoshi","d":1269453717,"b":[["t","Title changed.\n\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)"]],"u":"https://bitcointalk.org/index.php?topic=83.msg809#msg809","s":1,"n":96,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/96/"},{"f":"satoshi","d":1269453775,"b":[["t","Mihalism Multi Host is a popular open source PHP file hosting server.\n\nIt's geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting.  They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed.\n\nIt doesn't have a bunch of client side scripting or anti-embedding junk to rip out.  It generates standard links that work normally.\n\nThere's a turnover churn in these free hosting sites.  Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth.  Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs.  It's a perfect example of a service where the needed price point is in the no-man's-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment.  It's in the gap between 0 and 19.95.  The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders.  It can't really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.\n\nAn example of a site running the software:\nhttp://www.imagez.ws/\n\nForum:\nhttp://www.mihalism.net/\n\nDownload:\nhttp://code.google.com/p/mihalismmh/\n\nWhat do you think?  If I made a Bitcoin payment integration for this, would anyone be interested in running it?  It might be the first fully automated service available to buy with Bitcoins.  The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops.  It would give a normal link directly to the file."]],"u":"https://bitcointalk.org/index.php?topic=83.msg810#msg810","s":1,"n":97,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/97/"}]},{"id":"p43","k":"p","s":"bitcointalk","t":"On IRC bootstrapping","u":"https://bitcointalk.org/index.php?topic=84","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/43/","m":[{"f":"soultcer","d":1268683132,"b":[["t","A week or so ago I met a very nice Freenoder staffer in the #bitcoin and #bitcoin-dev channels. He told me that the #bitcoin channel turned up on Freenode's radar as it looks like a Botnet Command and Control channel, but after I explained to him how Bitcoin works and why they need IRC, he said that the channel at it's current size is not a problem.\n\nHowever, this got me thinking and later this week I also discussed the topic on IRC, and I came to the conclusion, that IRC is the wrong method for bootstrapping, especially in it's current form. At the moment, each client will connect to IRC and stay connected. Using /who and join messages, the client will connect to the found IPs on port 8333 as a bootstrapping method. However, the clients internally also talk to each other and broadcast new nodes via the Bitcoin protocol. Still, they are always online in IRC. This has various disadvantages:\n\n• IRC connectivity is necessary for bootstrapping (firewalls often block it and Freenode blocks TOR)\n\n• There is a single point of failure (Freenode)\n\n• We are leeching Freenode's services instead of using our own infrastructure. Many servers actually disallow bot connections in their MOTDs.\n\n• Minor point: The additional protocol inside Bitcoin brings extra complexity\n\nThere is already a list of permanently-on Bitcoin IPs around in this forum, which is a nice idea, but not very scalable, thus I propose the following solution: Gnutella and MUTE face very similar bootstrapping problems. To solve them, they rely on a list of \"Gnutella Webcaches\". Those webcaches are run by volunteers on simple PHP servers and a master list of them is distributed with each Gnutella/MUTE release. When a client wants to join the network, it asks one or two of the Webcaches via HTTP for a list of other nodes and also gets added to that list (which is usually a list of the last X clients seen). Every few hours (or days) a running client reconnects to the webcache to tell it, that it is still alive and does not have to be deleted from the list. I suggest, that the same thing is implemented for Bitcoin. Volunteers could run those webcaches on cheap PHP webspace and tell their URL to Satoshi or Sirius, who in turn could add the list to each release. This would allow users running behind a restrictive firewall or TOR to use Bitcoin without manually finding other nodes, and it is a much more scalable approach. (As a bonus we could remove those HTTP calls to whatismyip.com or similar sites).\n\nOf course, there might be a better idea for bootstrapping Bitcoin and I would love to hear it. Or maybe suggestions for the Webcache idea. Please post them here!\n\nCheers,\nsoultcer"]],"u":"https://bitcointalk.org/index.php?topic=84.msg721#msg721"},{"f":"theymos","d":1268702892,"b":[["t","To eliminate segmentation, every peer should have a list of every other peer. Tor also has this requirement, so we should copy them: have several trusted directory servers periodically create a signed list of all peers and publish it via HTTP. All BitCoin clients have the option to act as a directory mirror, which will be indicated in the dirServers' list. Generators need to ask to be added to the list (which could also include info like the maximum number of connections that peer will accept), but people just wishing to make transactions can just get the list from a dirMirror and connect to a few random peers.\n\nIf this is too centralized, we can do what I2P did and allow anyone to become a directory server. You need to be able to detect when a dirServer goes rogue in this case, though."]],"u":"https://bitcointalk.org/index.php?topic=84.msg724#msg724"},{"f":"The Madhatter","d":1268704644,"b":[["t","I vote for the I2P method, myself. It works great."]],"u":"https://bitcointalk.org/index.php?topic=84.msg725#msg725"},{"f":"satoshi","d":1268768927,"b":[["t","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.\n\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.\n\nBitcoin can get the list of IPs from any bitcoin node.  In that sense, every node serves as a directory server.\n\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.\n\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?\n\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. Smiley  Bitcoin's IRC client implementation is already thoroughly tested."]],"u":"https://bitcointalk.org/index.php?topic=84.msg729#msg729","s":1,"n":92,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/92/"},{"f":"Xunie","d":1270756653,"b":[["t","We all talk about bootstrapping systems, how ever, my idea might be a bit better.\n\nA user starts bitcoin on a host for the first time, and it will initially download a list of nodes that it will connect to.\n(until, of course, we have a lot of static nodes we can hard code into bitcoin...)\nThen, the client tries to connects to those IPs on that list it downloaded, or when it already has a list downloaded from the last time it started bitcoin, connect to those.\nWhen we're connected, the client asks every node for a list of nodes they know and updates its node list.\nOnce a complete list is obtained, it is saved on the hard drive and a copy is kept in memory. (This is because we want to have a list of nodes without actually connect to that indexing server.)\nAnd finally, the node is completely connected to the network.\nWhen a new node connects (when it receives a \"new node packet\"), the list is both updated in memory and saved to the hard drive again.\nTo make updating the list with new nodes so bandwidth friendly as possible, I suggest that every node \"echoes\" the IP of a new node connecting to the network to all the nodes it knows...\n\nPros:\n* Has bootstrapping in mind.\n* Is distributed for clients that have a node list\n\nCons:\n* Every new client needs to connect to a server to get a new node list until we're done with bootstrapping.\n\nThis, in my eyes, seems like the best solution to our bootstrapping problem...\nPS: If we implement this, we might just wanna check if the \"new node packet\" we received contains bogus IPs, or IPs that resolve to .gov domains! Tongue"]],"u":"https://bitcointalk.org/index.php?topic=84.msg876#msg876"},{"f":"D҉ataWraith","d":1272639074,"b":[["t","Hi all.\n\nThis may be a stupid idea, and if it's not stupid, may not be viable for the next few years, but I thought I'd toss it out there anywhere:\n\nWhat about Multicasting?\n\nIPv6 is supposed to have better multicasting support than IPv4, and if I did not misunderstand the Bitcoin protocol, most messages need to be broadcasted to the entire network. Theoretically a node could send such messages to a global multicast address, and everyone will receive it in a bandwith-efficient way.\n\nThat would make bootstrapping in the traditional sense obsolete, since the client would just have to subscribe to the multicast channel. The remaining \"Give me block xyz\" requests could be handled by optionally including a field in messages to the multicast channel that basically says \"My address is 2001:db8::42, and I'm willing to answer direct queries for specific blocks\". After listening to the channel for a while, such a packet should come around, because, at the very least, new blocks will be announced there every so often."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1036#msg1036"},{"f":"Xunie","d":1272918994,"b":[["t","I don't know that much about IPv6, but it sounds good, if it's possible.\nHow ever, keep in mind that as of now, 9/10th of the world still uses IPv4!\nSo it is a great idea, and developer(s) (how much does bitcoin have anyways?) should implement it in bitcoin (in my humbly opinion).\nHow ever, making it default to use IPv6 isn't a good idea.\n\nIt's totally viable when everyone will be using IPv6, it's just everyone still uses IPv4!\n\n(And I see now that in my previous post I basically explained what other people adviced... Oops!)"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1058#msg1058"},{"f":"theymos","d":1272925343,"b":[["t","TCP doesn't work with multicasting. And I doubt it will ever be easy for a home user to join a multicast group."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1059#msg1059"},{"f":"laszlo","d":1272943143,"b":[["t","If you guys are interested in ipv6, there are a lot of transition mechanisms available.  Windows comes with teredo which is kind of complicated for what it does.. I like 6to4, basically every ipv4 node has an ipv6 prefix which is 2002:<ipv4 addr> /48.  It is very easy to set up 6to4 on a linux box.  Here is my setup as an example:"],["c","echo 0 > /proc/sys/net/ipv6/conf/all/autoconf\necho 0 > /proc/sys/net/ipv6/conf/all/accept_ra\necho 0 > /proc/sys/net/ipv6/conf/all/accept_redirects\necho 0 > /proc/sys/net/ipv6/conf/all/router_solicitations\necho 1 > /proc/sys/net/ipv6/conf/all/forwarding\nip tunnel add 6to4tunnel mode sit ttl 200 remote any local 76.122.46.187\nip link set dev 6to4tunnel up\n# listen for 6to4 traffic to me\nip -6 addr add 2002:4c7a:2ebb::1/16 dev 6to4tunnel\n# route to non 6to4 ipv6 hosts\nip -6 route add 2000::/3 via ::192.88.99.1 dev 6to4tunnel metric 1\n# add address to lan0\nip addr add 2002:4c7a:2ebb:0001::1/64 dev lan0\n# add address to lan1\nip addr add 2002:4c7a:2ebb:0002::1/64 dev lan1\necho \"Starting radvd...\"\n/opt/radvd/sbin/radvd"],["t","That is literally all it takes.  This is for my linux box which is acting as a router.  You just convert your ipv4 address to hex.  For instance mine, 76.122.46.187 == 4c 7a 2e bb\n\nThe v4 address 192.88.99.1 is an anycast address.. There are routers that pick up the 6to4 traffic and bridge it over into the native v6 land.  Because of how routing works you will just get to the closest (network wise) bridge router when you transmit to v6 addresses.\n\nSetting up radvd allows the client machines on your lans (I have lan0 and lan1) to receive an automatic ipv6 address.  With this set up you can hit ipv6.google.com and see the letters bouncing to know it works.\n\nIf you're planning to try this, google up some info on 6to4 first so you understand how it works.  Also be aware that your machines which are NAT'd with ipv4 are globally accessible with this set up and are not filtered unless you set that up separately (windows firewall, ip6tables, etc)"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1062#msg1062"},{"f":"lachesis","d":1275602171,"b":[["t","I throughly agree with this. In the long run, IRC should be completely phased out and replaced with something like Gnutella's host caches or Tor's dictionary servers (as others have suggested).\n\nAt the very least, Bitcoin should disconnected from IRC as soon as it has a list of peers to connect to. It should also cache that list so it wouldn't need to reconnect upon the next startup.\n\nJust my 0.02฿."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1336#msg1336"},{"f":"Cdecker","d":1275999065,"b":[["t","Anyone into a set of multi entity owned DNS servers that cooperate for a Fast Flux [1] network to ensure bootstrap availability?\n\n[1] http://en.wikipedia.org/wiki/Fast_flux"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1407#msg1407"},{"f":"laszlo","d":1276000742,"b":[["t","What's wrong with IRC?  It's just another method that's used to exchange the peer list.  You can just prevent it from connecting and use -addnode=1.2.3.4 to connect to a known node for bootstrapping if you want..\n\nIf nodes disconnect from IRC after they get their list then it makes it less useful for bootstrapping since it will be empty except for the node that's trying to bootstrap at the time.\n\nIRC has been around forever and it's well documented (and easy to understand for newcomers) - why create something more complicated?"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1408#msg1408"},{"f":"lachesis","d":1276005429,"b":[["t","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.\n\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.\n\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.\n\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?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1409#msg1409"},{"f":"satoshi","d":1276539201,"b":[["t","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.\n\nWhat do you think, should I go ahead with adding the seeds?\n\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.\n\nIs there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us?"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1579#msg1579","s":1,"n":117,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/117/"},{"f":"laszlo","d":1276540258,"b":[["t","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.\n\nMy box is a dedicated irc server:\n 2:28PM  up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08\n\nYou can use irc.lfnet.org to connect.\n\nI hang out on #linuxos if anyone wants to drop in."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1580#msg1580"},{"f":"blanu","d":1276837968,"b":[["t","This is a common problem in P2P, known as Original Introduction, although bootstrapping is also a good word for it. The problem with bootstrapping is that you can't decentralize it. Whether it's IRC or HTTP or DNS, the client needs to be hardcoded with an address or list of addresses which is sufficiently fresh that at least one of the listed addresses is still active. After the first node is reached, you are no longer in Original Introduction mode and can use the full range of techniques for decentralization, such as gossip. Unless, of course, you get disconnected from the network and all of your known peers go away, in which case you're back to bootstrapping.\n\nThere are two properties that are at odds when you chose a bootstrapping method: robustness (scalability/reliability) and freshness. Robustness is increased at the expense of freshness by caching on multiple servers, as is usually done with HTTP peer lists. Freshness is maximized (at least up to the TCP timeout) at the expense of robustness by having everyone connected, as with IRC. Of course, the key is finding the right mix of robustness and freshness because you need both for the bootstrap to be successful.\n\nHere are some of my current favorite methods for bootstrapping:\n\nAppend list of fresh peers to executable or installer dynamically on download. People usually get the application from its official website, so the website is already a point of failure for new users. You're already hardcoding an address in the application, the address that the application will use to bootstrap. So instead just add fresh peers at the moment of download. You need some fancy code in the executable to read the list off the end, but I've implemented this in an NSIS installer and it's not that hard. Most software developers are upset by the idea of this method.\n\nConnect via XMPP to Google App Engine application. This gives the freshness of IRC, but with more robust scaling. App Engine is mostly for writing web apps, but it provides email and XMPP handling as well. It would be simple to write one application that could handle peer lists via either XMPP or HTTP with the same handler code. I'm currently using this in an application and it works well and is very reliable. I only wish there was a second App Engine to use as a fallback because it does have occasional downtime.\n\nAn alternative to requiring all nodes to include the complexity of a protocol like IRC or XMPP is to have a few special sentinel nodes which sit on the network and collect addresses of connected nodes via the usual decentralized methods available to an active node. These sentinel nodes periodically upload fresh addresses, say via HTTP POST to a number of websites. A new node can then download a fresh address list from any of the websites which is currently functioning and reachable. If you have 5 sentinels each uploading every 5 minutes (staggered), then you'll have updates roughly once a minute. This is on par with IRC in terms of freshness and is robust as you care to make it by varying the number of HTTP mirrors and the number of sentinels."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1614#msg1614"},{"f":"D҉ataWraith","d":1276870103,"b":[["t","I think the way eMule handles bootstrapping for its KAD-network is pretty close to optimal:\n\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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1616#msg1616"},{"f":"satoshi","d":1276882098,"b":[["t","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.\n\nThis means TOR users won't need to -addnode anymore, it'll get connected automatically.  "]],"u":"https://bitcointalk.org/index.php?topic=84.msg1619#msg1619","s":1,"n":128,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/128/"},{"f":"satoshi","d":1277505647,"b":[["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.\n\nMy box is a dedicated irc server:\n 2:28PM  up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08\n\nYou can use irc.lfnet.org to connect.","Quote from: laszlo on June 14, 2010, 06:30:58 PM"],["t","This seems like a good idea.\n\nWhat does everyone think, should we make the switch for 0.3?"]],"u":"https://bitcointalk.org/index.php?topic=84.msg1781#msg1781","s":1,"n":148,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/148/"},{"f":"Vasiliev","d":1277509815,"b":[["t","You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's."]],"u":"https://bitcointalk.org/index.php?topic=84.msg1785#msg1785"},{"f":"sirius","d":1278464747,"b":[["t","Maybe we should have an option dialog that allows you to choose the IRC server and channel you connect to?"]],"u":"https://bitcointalk.org/index.php?topic=84.msg2009#msg2009"},{"f":"satoshi","d":1278466267,"b":[["t","Everybody needs to connect to the same IRC server and channel so they can find each other."],["q","You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.","Quote from: Vasiliev on June 25, 2010, 11:50:15 PM"],["t","It might not be good if we suddenly rushed freenode with a ton of users all at once.\n\nThe fallback is our own seed system.\n\nirc.lfnet.org is pretty old and has impressive uptime.  I think it's going to be fine.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=84.msg2010#msg2010","s":1,"n":170,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/170/"}]},{"id":"p44","k":"p","s":"bitcointalk","t":"Exchange Methods","u":"https://bitcointalk.org/index.php?topic=87","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/44/","m":[{"f":"dwdollar","d":1269048799,"b":[["t","Hi everyone.  I'd like to see a good discussion on different methods for transferring into and out of cash.  It has been touched on elsewhere, but I'd like to create a definitive thread for it.  This discussion should include, but shouldn't be limited to the following...\n\n1.)  Methods mentioned previously on the forum, along with their pros and cons.\n2.)  New ideas including ones that are \"outside of the box\"\n3.)  As a customer, which method do you prefer?  What is more important to you?  Anonymity, security, convenience or other?\n\nNewLibertyStandard is using direct transactions with Paypal.\nI think Sirius-m is working on several different direct transactions that the customer may select from.\nI am using a deposit and withdraw system using Paypal (for the time being).\n\nLet's dicuss everything from satoshi's sophisticated \"e-bay-like\" idea, to madhatter2's \"money in the mail\" idea, and everything in between."],["q","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.\n\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.\n\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.","Quote from: satoshi on March 03, 2010, 04:28:56 AM"],["q","Nice! Wink\n\nI might do 'well hidden cash in the mail' here for small amounts.","Quote from: madhatter2 on February 24, 2010, 04:59:55 AM"],["t","One last thing.  Legality can be listed as a pro/con but let's not get wrapped up in it here.  NewLibertyStandard already has a good thread <http://bitcointalk.org/index.php?topic=69.0> started on that topic."]],"u":"https://bitcointalk.org/index.php?topic=87.msg767#msg767"},{"f":"The Madhatter","d":1269054643,"b":[["t","Cash in the mail is the best option, in my opinion.\n\n1. It is fairly anonymous (there would be a postmark from your side and you'd know my address).\n2. I know the laws inside and out here. I wouldn't violate them.\n3. I am not in the USA.\n\nWink\n\nOh and PayPal is a horrible choice.\n\nAll it would take is for a competitor to rat you out to PayPal and you'd be out of business.\n\nExchanging in and out of physical gold/silver is another option. I have experience with shipping goods, and a friend of mine is a bullion dealer. Tongue\n\nedit by Xunie: merged two posts."]],"u":"https://bitcointalk.org/index.php?topic=87.msg769#msg769"},{"f":"NewLibertyStandard","d":1269057046,"b":[["t","PayPal\nFree and easy to open an account.\nVery inexpensive to deposit, transfer and withdraw money.\nEasily accessible by people all around the world.\nPayPal is known to frequently freeze funds for long periods of time.\nReveals first and last name.\nTransactions can be contested fairly easily.\n\nBank Wire\nMost well established electronic money transfer method.\nFees are prohibitively expensive for small transactions.\nBank can request to reverse transaction, but it's very rare.\nI presume first and last name don't need to be revealed.\nSome personal account information must be revealed.\n\nBank Wire through MutoNovo\nFee in addition to wire fee.\nDo not need to reveal personal account information to send or receive wire.\n\nWestern Union\nMany locations worldwide.\nNeither party needs a bank account.\nFees are fairly expensive.\nWeak identity verification.\n\nPecunix Digital Gold Currency\nTransaction fee is small.\nTransactions are fairly anonymous.\nCurrency must be purchased and sold through a third party, presumably with expensive fees.\n\nPostal Mail\nLots of domestic mailing options available within USA.\nMailing of currency generally discouraged.\nVarious types of checks can only be cashed in certain countries.\nCash can be lost or stolen.\nValue of some kinds of checks can be lost or stolen.\nValue of other kinds of checks do not get withdrawn until named recipient cashes check.\nAlthough extremely unlikely and highly punishable, postal mail can be used as a delivery method for harmful biological agents.\n\nPayPal works best for me because it's inexpensive and easy. If I was planning on expanding and making a profit from my exchange service, I would probably get an account at a big bank and offer as many payment options as possible."]],"u":"https://bitcointalk.org/index.php?topic=87.msg771#msg771"},{"f":"The Madhatter","d":1269057503,"b":[["t","Not anymore. They were just recently slapped with fines. They are tightening up ID requirements now."],["q","Western Union\nWeak identity verification.","Quote from: NewLibertyStandard on March 20, 2010, 03:50:46 AM"]],"u":"https://bitcointalk.org/index.php?topic=87.msg772#msg772"},{"f":"BitcoinFX","d":1269080461,"b":[["t","I like Liberty Reserve https://www.libertyreserve.com/\n\nIts easy to use, fast, secure and has a good API. It's been around since 2002. USD, EUR and Gold holdings. No formal ID verification process is required. You are allowed to create multiple accounts as long as you register your details fully (i.e. no fake accounts) Its based in Costa Rica, which makes the list of the 'Worlds 22 Oldest Democracies' http://wikipedia.org/wiki/Costa_Rica - Intel has a main micro processor facility in Costa Rica and I like coffee. Grin I trust and use Liberty Reserve more than any another eCurrency or online payment system. https://www.libertyreserve.com/en/exchangers/index.aspx has loads of useful exchange links.\n\nHere are some other suggestions for discussion:\n\nExchange Zone - http://exchangezone.com/ - easy and secure, member to member, eCurrency auction service.\n\nAlertPay - https://www.alertpay.com/\n\nc-gold - https://c-gold.com/\n\nStrict Pay - https://www.strictpay.com/\n\nSolidTrust Pay - https://solidtrustpay.com/\n\nPerfect Money - https://perfectmoney.com/\n\nGlobal Digital Pay - https://www.globaldigitalpay.com/\n\nePassport - https://www.epassporte.com/\n\nEuroGoldCash - https://www.eurogoldcash.com/\n\nHyper Wallet - http://www.hyperwallet.com/\n\nWeb Money - http://www.wmtransfer.com/\n\nPro Currex - https://www.procurrex.com/\n\nECU Money - http://www.ecumoney.com/\n\nWith many of these e-currencies and providers / exchangers now implementing mobile phone payments it would seem logical to pursue that route. Most countries have 'pay-as-you-go' providers. This is as good as 'anonymous' if bought for cash. Apparently, mobile phone payments have a much higher conversion rate than credit cards etc. for online payments.\n\nHere are some services I found for discussion and which I might be implementing myself in the future:\n\nZong - http://www.zong.com/zong/\n\nObo Pay - https://www.obopay.com/\n\nBango - http://bango.com/\n\nMobileTransactions - http://www.mobiletransaction.org/\n\nSelf Bank Mobile - https://www.selfbankmobile.com/\n\nImplementation:\n\nFortumo - http://fortumo.co.uk/\n\nAsterisk - http://www.asterisk.org/\n\nConsider the above with a Bitcoin mobile App. and we are really getting somewhere.\n\nI don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...\n\nThis reminds me of a few Google Hoaxes.\n\nGmail Paper - http://mail.google.com/mail/help/paper/index.html\n\nGoogle Gulp - http://www.google.com/googlegulp/ lol Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=87.msg773#msg773"},{"f":"The Madhatter","d":1269113316,"b":[["t","As a business, why would I accept Bitcoin and not LR/Pecunix? It doesn't make any sense to do exchanges between LR/Pecunix and Bitcoin.\n\nOh, and asterisk sucks. You'll want freeswitch instead. (freeswitch.org)\n\nSo you are saying that people are lazy? lol Big surprise there. Tongue"],["q","I don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...","Quote from: BitcoinFX on March 20, 2010, 10:21:01 AM"],["t","Oh and LR is a fractional reserve currency on top of a fractional reserve currency. Do not keep money in your LR accounts. Use it as a pass-thru only. Also, PerfectMoney is ran by a sociopath who is currently in prison.\n\nedit by Xunie: merged 4 posts."]],"u":"https://bitcointalk.org/index.php?topic=87.msg777#msg777"},{"f":"BitcoinFX","d":1269123947,"b":[["q","As a business, why would I accept Bitcoin and not LR/Pecunix? It doesn't make any sense to do exchanges between LR/Pecunix and Bitcoin.","Quote from: madhatter2 on March 20, 2010, 07:28:36 PM"],["t","You can decide to accept Bitcoins and / or LR/Pecunix, both or neither !\n\nIt does make sense to exchange LR/Pecunix with Bitcoins and vice versa;\n\n(1) You (customers) can generate Bitcoins.\n\n(2) You (customers) can buy, sell, or exchange items, goods and services which you can't with just Bitcoins and vice versa.\n\nYou know you can obtain a bank card to withdraw LR USD from an ATM ! You can't do that with Bitcoins, yet ! Grin"]],"u":"https://bitcointalk.org/index.php?topic=87.msg783#msg783"},{"f":"BitcoinFX","d":1269124226,"b":[["q","Oh, and asterisk sucks. You'll want freeswitch instead. (freeswitch.org)","Quote from: madhatter2 on March 20, 2010, 07:29:55 PM"],["t","Thanks for the opinion, link and info. I will look into and try that one.\n\nWe are all here to learn, discuss and share information."]],"u":"https://bitcointalk.org/index.php?topic=87.msg784#msg784"},{"f":"BitcoinFX","d":1269124659,"b":[["q","So you are saying that people are lazy? lol Big surprise there. Tongue\n\n> Quote from: BitcoinFX on March 20, 2010, 10:21:01 AM\n> I don't agree with the land mail method. Its comparatively slow and less anonymous than you might think - Just remember to handle the envelope and its contents, lick the seal and stamp and send it from your local mail box...","Quote from: madhatter2 on March 20, 2010, 07:31:26 PM"],["t","Yes. I was also highlighting the fact that 'snail mail' is slow. Also, on a 'paranoid' note it's not 'anonymous' to send a 'franked' envelope, revealing your location and which also contains your DNA. Shocked\n\nNot that this is a realistic consideration for micro payments anyway. Much better to buy a 'mobile' credit card and toss it in a ditch. If you are that way inclined.\n\nI'm not saying 'snail mail' is a bad idea. Just discussing the pros and cons..."]],"u":"https://bitcointalk.org/index.php?topic=87.msg785#msg785"},{"f":"BitcoinFX","d":1269125183,"b":[["q","Oh and LR is a fractional reserve currency on top of a fractional reserve currency. Do not keep money in your LR accounts. Use it as a pass-thru only. Also, PerfectMoney is ran by a sociopath who is currently in prison.","Quote from: madhatter2 on March 20, 2010, 07:40:50 PM"],["t","Yep. Never keep money in a bank, always keep it under the bed, much safer... lol  Wink\n\nYes. I have also heard of 'problems' with Perfect Money.\n\nMost of what I listed was for discussion and was not a recommendation. Again, we are here to share ideas and information, good, bad or indifferent. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=87.msg786#msg786"},{"f":"BitcoinFX","d":1269125387,"b":[["t","Also found liqpay (mobile payments) - https://www.liqpay.com"]],"u":"https://bitcointalk.org/index.php?topic=87.msg787#msg787"},{"f":"The Madhatter","d":1269125815,"b":[["t","I think as Bitcoin's adoption rates go up more and more LR+Pecunix only sites will pick up Bitcoin as an alternate payment option. After all, the people already accepting LR/Pecunix are very like-minded.\n\nYes, we are all here to learn and discuss. My apologies if I came across as a \"know-it-all\". I have just been in the payment processing industry and law studies for over 10 years, and I know a lot about it. Wink\n\nSure, you can be worried about me taking your DNA from an envelope that you send. Tongue Just use gloves when preparing the envelope and use water or tape instead of saliva. (Wear a hair net too if you are that paranoid! ha!)\n\nA franked envelope has information about the general area from where the letter was mailed. It is rather useless to an investigator, assuming that you don't use a real return address. Or you use a return address that I provide you (lets just say). You can also go for a little drive to a different part of town and mail from there. Or another city. Or get a friend to re-mail it from his city. There are plenty of options.\n\n'Snail mail' when properly prepared (making the envelopes as machine-readable as possible and using the proper Zip code 5+4 digit extension, etc) is actually quite speedy. (I have experience with shipping as well.)"]],"u":"https://bitcointalk.org/index.php?topic=87.msg788#msg788"},{"f":"The Madhatter","d":1269126220,"b":[["t","Epassporte is kinda scammy. It is ran by the same folks who run Paycom/Epoch Billing (adult billing). I personally know a handful of people who were ripped off, had their accounts frozen for various non-issues (see: PayPal).\n\nWhen I had signed up for a physical card when they first opened I never received anything in the mail, they charged my CC, my bank called me asking me if it was fraudulent. They told me that those epassporte charges had caused a lot of disputes at my bank. I explained to the guy on the phone what I had ordered online and that I hadn't received anything. (It wasn't my intention to chargeback or cause any \"friendly fraud\", people do that to me all the time so I know how it feels. It is aggravating.) My money was refunded by epassporte after I called them in California (they claim to be in Antigua).\n\nWhen people ask me to pay them with Epassporte, I usually just laugh.\n\nAnyone want to hear my stories about PayPal? lol I have a few.\n\nHow about with Visa International? Or MasterCard's broken securecode system?\n\nTongue"]],"u":"https://bitcointalk.org/index.php?topic=87.msg789#msg789"},{"f":"The Madhatter","d":1269126382,"b":[["t","Great minds think alike. (There are better places than under your bed.)"],["q","Yep. Never keep money in a bank, always keep it under the bed, much safer... lol  Wink","Quote from: BitcoinFX on March 20, 2010, 10:46:23 PM"]],"u":"https://bitcointalk.org/index.php?topic=87.msg790#msg790"},{"f":"BitcoinFX","d":1269127202,"b":[["q","I think as Bitcoin's adoption rates go up more and more LR+Pecunix only sites will pick up Bitcoin as an alternate payment option. After all, the people already accepting LR/Pecunix are very like-minded.\n\nYes, we are all here to learn and discuss. My apologies if I came across as a \"know-it-all\". I have just been in the payment processing industry and law studies for over 10 years, and I know a lot about it. Wink\n\nSure, you can be worried about me taking your DNA from an envelope that you send. Tongue Just use gloves when preparing the envelope and use water or tape instead of saliva. (Wear a hair net too if you are that paranoid! ha!)\n\nA franked envelope has information about the general area from where the letter was mailed. It is rather useless to an investigator, assuming that you don't use a real return address. Or you use a return address that I provide you (lets just say). You can also go for a little drive to a different part of town and mail from there. Or another city. Or get a friend to re-mail it from his city. There are plenty of options.\n\n'Snail mail' when properly prepared (making the envelopes as machine-readable as possible and using the proper Zip code 5+4 digit extension, etc) is actually quite speedy. (I have experience with shipping as well.)","Quote from: madhatter2 on March 20, 2010, 10:56:55 PM"],["t","No. You don't come across as a 'know-it-all'. I enjoy reading your post and contributions.\n\nHowever, I would much rather just sit at my desk and transfer 'payments' around by text msg etc. than have to drive across town to post a letter. Only to return home and remember that I'd forgotten to buy the darn hair nets (again) rofl.\n\nGoogle Paper has experience of shipping to http://mail.google.com/mail/help/paper/more.html"]],"u":"https://bitcointalk.org/index.php?topic=87.msg791#msg791"},{"f":"The Madhatter","d":1269127466,"b":[["t","Maybe one should have a lackey that does the driving and mailing. Tongue Pay him in Bitcoins!"],["q","However, I would much rather just sit at my desk and transfer 'payments' around by text msg etc. than have to drive across town to post a letter. Only to return home and remember that I'd forgotten to buy the darn hair nets (again) rofl.","Quote from: BitcoinFX on March 20, 2010, 11:20:02 PM"]],"u":"https://bitcointalk.org/index.php?topic=87.msg792#msg792"},{"f":"dwdollar","d":1269208171,"b":[["t","Here is an idea I have been pondering.  I think it's similar to Satoshi's, only transfers are made directly...  Feel free to rip apart or amend.  I created a goofy .pdf <http://www.filesavr.com/distributedtransfering> to explain what is happening.\n\nIn theory this could be used for any third party such as Paypal, etc.  I think it would be very difficult for them to prove that individuals are participating in a currency exchange.  And, I think it becomes more difficult to prove as the number of traders increase.\n\nOne big problem.  Person A and Person B must follow through with their transfers and be honest about their actions.  A solution might be to require an initial deposit from each individual to be held as collateral before any orders are made.  These deposits could be in Bitcoins and offered as compensation when a trade \"goes bad\" for whatever reason.\n\nPros:\n1.)  No centralized account that can be seized or frozen.\n2.)  No tax reporting burden on accounts.\n\nCons:\n1.)  Transfers are less anonymous since individuals can \"see\" one another.\n2.)  Parties must be trustworthy."]],"u":"https://bitcointalk.org/index.php?topic=87.msg796#msg796"},{"f":"The Madhatter","d":1269286347,"b":[["t","During an audit (taxman, or otherwise) how will \"Person B\" explain a donation? Person B would need to have some sort of cover. A fake charity or something?"]],"u":"https://bitcointalk.org/index.php?topic=87.msg800#msg800"},{"f":"dwdollar","d":1269305949,"b":[["q","During an audit (taxman, or otherwise) how will \"Person B\" explain a donation? Person B would need to have some sort of cover. A fake charity or something?","Quote from: madhatter2 on March 22, 2010, 07:32:27 PM"],["t","I'm not sure what Paypal is required to report on individuals and/or merchants.  This <https://www.thepaypalblog.com/2008/08/proposed-irs-reporting-requirements-become-law/> explains some of it for US domestic.  It's a little dated though.  Maybe someone could elaborate."]],"u":"https://bitcointalk.org/index.php?topic=87.msg803#msg803"},{"f":"The Madhatter","d":1269309604,"b":[["t","None of that matters. PayPal's corporate policies are not law. Under the slightest inquiry they will give you up. I guarantee that fact.\n\nSee 'jurisdiction' again. Is PayPal a registered corporation? I'd imagine so. Obtaining a corporate charter is a PRIVILEGE (means \"private law\"), not a right. (Rights are inherent, you don't apply for them.) It makes PayPal subject to the jurisdiction of the REGISTRAR. (The state or federal government.) So when they are asked for your information and are stuffed with a pile of statutes, they have to comply or face civil (See: Roman Civil Law) penalties or the revocation of the charter. (Revocation of charters is rare, but it does happen.)\n\nAfter PayPal gives up your information; they (IRS/boogieman/whoever) will look at the real world items you have in your 'keep' and determine that they were paid for with these so-called donations online.\n\nYou'll enter your plea with the courts (a plea is a verbal contract that also establishes civil jurisdiction with your consent), they'll find you guilty, and you'll get a nice piece of paper called a court order to pay fines (or possibly jail time).\n\nCall me jaded if you wish. They are very 'tricky monkeys'. Wink"]],"u":"https://bitcointalk.org/index.php?topic=87.msg804#msg804"},{"f":"The Madhatter","d":1269313429,"b":[["t","Add this to the 'cons list' for cash:\n\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."]],"u":"https://bitcointalk.org/index.php?topic=87.msg805#msg805"},{"f":"satoshi","d":1269365734,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=87.msg807#msg807","s":1,"n":95,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/95/"}]},{"id":"p45","k":"p","s":"bitcointalk","t":"who is bitcoin.com","u":"https://bitcointalk.org/index.php?topic=88","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/45/","m":[{"f":"Anonymous","d":1269278177,"b":[["t","Is http://www.bitcoin.com a valid implementation of the bitcoin protocol?  How are they able to use the name? Does anyone know who is behind it?"]],"u":"https://bitcointalk.org/index.php?topic=88.msg799#msg799"},{"f":"sirius","d":1269289095,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=88.msg801#msg801"},{"f":"satoshi","d":1269357761,"b":[["t","It's unrelated.  There wasn't anything there when I started.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=88.msg806#msg806","s":1,"n":94,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/94/","qt":["The 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."],"qc":["general"]}]},{"id":"p46","k":"p","s":"bitcointalk","t":"removing bitcoin addresses","u":"https://bitcointalk.org/index.php?topic=101","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/46/","m":[{"f":"SheriffWoody","d":1270738585,"b":[["t","Is there any way to remove bitcoin addresses that you have generated for yourself? What about if you have received payments to those addresses? Are they needed to show ownership for the coins after they have been transferred?"]],"u":"https://bitcointalk.org/index.php?topic=101.msg873#msg873"},{"f":"sirius","d":1270879951,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=101.msg888#msg888"},{"f":"satoshi","d":1274052880,"b":[["t","SheriffWoody:\nBitcoin 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.\n\nsirius-m:\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.\n\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\n    // Keep giving the same key to the same ip until they use it\n    if (!mapReuseKey.count(pfrom->addr.ip))\n        mapReuseKey[pfrom->addr.ip] = GenerateNewKey();\n    \n    ...sends the key mapReuseKey[pfrom->addr.ip]\n\n...later...\n\n    // Received something with this key\n    mapReuseKey.erase(pfrom->addr.ip);\n\nIf it's not convenient to know when you've received, just clear the cached keys every 20 minutes.\n\nI want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address."]],"u":"https://bitcointalk.org/index.php?topic=101.msg1134#msg1134","s":1,"n":102,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/102/","qt":["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."],"qc":["bitcoin-design"]}]},{"id":"p47","k":"p","s":"bitcointalk","t":"Is there a way to automate bitcoin payments for a website?","u":"https://bitcointalk.org/index.php?topic=112","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/47/","m":[{"f":"Minsc","d":1271290360,"b":[["t","I run a website hosted on freebsd and well right now nobody visits it ever and so I can totally change it.  I am wanting to change it to allow people to pay for services from the website exclusively through bitcoins.  Now I see bitcoin has some linux program but I'm not sure that's compatible with FreeBSD or not.  I also don't know how I can integrate bitcoin into a website to automatically take the bitcoin payments so they show up immediately.  I'd really like them to work so my website immediately recognizes the payment coming in."]],"u":"https://bitcointalk.org/index.php?topic=112.msg928#msg928"},{"f":"dwdollar","d":1271290582,"b":[["t","Not sure about FreeBSD, but payments can be automated with the new version.  http://bitcointalk.org/index.php?topic=63.0"]],"u":"https://bitcointalk.org/index.php?topic=112.msg929#msg929"},{"f":"The Madhatter","d":1271292560,"b":[["t","I have the latest SVN snapshot running on FreeBSD (bitcoind) with automation running on a few servers.\n\nYou just install databases/db48, x11-toolkits/gtk20, devel/gmake, and devel/boost-all from the ports tree, download wxwidgets 2.9 and install it manually (the port version is 2.8.. that's no good), change a few paths in the makefile.unix file, and run \"gmake -f makefile.unix bitcoind\". You will end up with a binary called \"bitcoind\" (it is headless). Run \"strip ./bitcoind\" to make it smaller (it is really big with the debugging symbols). You can, of course, leave the debugging symbols in. I had to use gdb on bitcoind a few times in the past to figure out a strange crash.\n\nI have tested bitcoind on 32 and 64 bit systems running FreeBSD. I didn't detect any memory leaks or see any crashes."]],"u":"https://bitcointalk.org/index.php?topic=112.msg931#msg931"},{"f":"generica","d":1271868820,"b":[["t","madhatter, thanks for these instructions.  I edited the makefile and installed the dependencies.  Here are the changes I had to make if anyone is interested:\n\n- Added these three INCLUDEPATH entries:\n -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" \\\n -I\"/usr/local/include/db48\" \\\n -I\"/usr/local/include\"\n\n- Added this LIBPATH entry:\n -L\"/usr/local/lib/db48\"\n\n- Changed \"wx_gtk2ud-2.9\" to \"wx_gtk2u-2.9\" because I didn't build wxwidgets with debugging\n\nThis is with SVN Rev 75.  However, the end result won't compile:"],["c","[root@colo /usr/src/bitcoin/trunk]# gmake -f makefile.unix bitcoind\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/util.o util.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/script.o script.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/db.o db.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/net.o net.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/irc.o irc.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/main.o main.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/rpc.o rpc.cpp\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp: In instantiation of 'boost::mpl::less_impl<mpl_::integral_c_tag, mpl_::integral_c_tag>::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul> >':\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:73:   instantiated from 'boost::mpl::less<mpl_::size_t<8ul>, mpl_::size_t<1ul> >'\n/usr/local/include/boost/mpl/aux_/has_type.hpp:20:   instantiated from 'boost::mpl::aux::has_type<boost::mpl::less<mpl_::size_t<8ul>, mpl_::size_t<1ul> >, mpl_::bool_<true> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/quote.hpp:56:   instantiated from 'boost::mpl::quote2<boost::mpl::less, mpl_::void_>::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/bind.hpp:207:   instantiated from 'boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >::apply<mpl_::size_t<8ul>, mpl_::size_t<1ul>, mpl_::na, mpl_::na, mpl_::na>'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, 0>, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73:   instantiated from 'boost::mpl::apply2<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, mpl_::size_t<8ul>, mpl_::size_t<1ul> >'\n/usr/local/include/boost/mpl/max_element.hpp:42:   instantiated from 'boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::apply<boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73:   instantiated from 'boost::mpl::apply2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:115:   instantiated from 'boost::mpl::aux::iter_fold_impl<4, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:146:   instantiated from 'boost::mpl::aux::iter_fold_impl<6, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/iter_fold.hpp:40:   instantiated from 'boost::mpl::iter_fold<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/max_element.hpp:65:   instantiated from 'boost::mpl::max_element<boost::mpl::l_item<mpl_::long_<6l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<5l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<4l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<3l>, mpl_::size_t<1ul>, boost::mpl::l_item<mpl_::long_<2l>, mpl_::size_t<8ul>, boost::mpl::l_item<mpl_::long_<1l>, mpl_::size_t<8ul>, boost::mpl::l_end> > > > > >, boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >'\n/usr/local/include/boost/variant/variant.hpp:123:   instantiated from 'boost::detail::variant::max_value<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::mpl::sizeof_<mpl_::arg<1> > >'\n/usr/local/include/boost/variant/variant.hpp:232:   instantiated from 'boost::detail::variant::make_storage<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>'\n/usr/local/include/boost/variant/variant.hpp:1098:   instantiated from 'boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>'\njson/json_spirit_value.h:89:   instantiated from 'json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >'\nrpc.cpp:34:   instantiated from here\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:90: warning: comparison between 'enum mpl_::size_t<1ul>::<anonymous>' and 'enum mpl_::size_t<8ul>::<anonymous>'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp: In instantiation of 'boost::mpl::less_impl<mpl_::integral_c_tag, mpl_::integral_c_tag>::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >':\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:73:   instantiated from 'boost::mpl::less<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'\n/usr/local/include/boost/mpl/aux_/has_type.hpp:20:   instantiated from 'boost::mpl::aux::has_type<boost::mpl::less<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >, mpl_::bool_<true> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/quote.hpp:56:   instantiated from 'boost::mpl::quote2<boost::mpl::less, mpl_::void_>::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/bind.hpp:207:   instantiated from 'boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >::apply<boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul>, mpl_::na, mpl_::na, mpl_::na>'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::bind2<boost::mpl::quote2<boost::mpl::less, mpl_::void_>, mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, 0>, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73:   instantiated from 'boost::mpl::apply2<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> >, boost::integral_constant<long unsigned int, 8ul>, boost::integral_constant<long unsigned int, 1ul> >'\n/usr/local/include/boost/mpl/max_element.hpp:42:   instantiated from 'boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::apply<boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply_wrap.hpp:49:   instantiated from 'boost::mpl::apply_wrap2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/apply.hpp:73:   instantiated from 'boost::mpl::apply2<boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:115:   instantiated from 'boost::mpl::aux::iter_fold_impl<4, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/iter_fold_impl.hpp:146:   instantiated from 'boost::mpl::aux::iter_fold_impl<6, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::l_iter<boost::mpl::l_end>, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/iter_fold.hpp:40:   instantiated from 'boost::mpl::iter_fold<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > >, boost::mpl::l_iter<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > > >, boost::mpl::protect<boost::mpl::aux::select_max<boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >, 0> >'\n/usr/local/include/boost/mpl/max_element.hpp:65:   instantiated from 'boost::mpl::max_element<boost::mpl::l_item<mpl_::long_<6l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<5l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<4l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<3l>, boost::integral_constant<long unsigned int, 1ul>, boost::mpl::l_item<mpl_::long_<2l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_item<mpl_::long_<1l>, boost::integral_constant<long unsigned int, 8ul>, boost::mpl::l_end> > > > > >, boost::mpl::less<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >'\n/usr/local/include/boost/variant/variant.hpp:123:   instantiated from 'boost::detail::variant::max_value<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::alignment_of<mpl_::arg<1> > >'\n/usr/local/include/boost/variant/variant.hpp:238:   instantiated from 'boost::detail::variant::make_storage<boost::mpl::l_item<mpl_::long_<6l>, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::mpl::l_item<mpl_::long_<5l>, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<4l>, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::mpl::l_item<mpl_::long_<3l>, bool, boost::mpl::l_item<mpl_::long_<2l>, long int, boost::mpl::l_item<mpl_::long_<1l>, double, boost::mpl::l_end> > > > > >, boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>::has_fallback_type_>'\n/usr/local/include/boost/variant/variant.hpp:1098:   instantiated from 'boost::variant<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::recursive_wrapper<std::vector<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Pair_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, boost::recursive_wrapper<std::vector<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >, std::allocator<json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > >, bool, long int, double, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_, boost::detail::variant::void_>'\njson/json_spirit_value.h:89:   instantiated from 'json_spirit::Value_impl<json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >'\nrpc.cpp:34:   instantiated from here\n/usr/local/include/boost/mpl/aux_/preprocessed/gcc/less.hpp:90: warning: comparison between 'enum mpl_::integral_c<long unsigned int, 1ul>::<anonymous>' and 'enum mpl_::integral_c<long unsigned int, 8ul>::<anonymous>'\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -DwxUSE_GUI=0 -o obj/nogui/init.o init.cpp\ng++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -O3 -o obj/sha.o sha.cpp\ng++ -O0 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include/wx-2.9\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.9\" -I\"/usr/local/include/db48\" -I\"/usr/local/include\"  -o bitcoind -L\"/usr/lib\" -L\"/usr/local/lib\" -L\"/usr/local/lib/db48\" 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(.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*)'\ngmake: *** [bitcoind] Error 1"],["t","This is on FreeBSD 7.2.  Any ideas? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=112.msg984#msg984"},{"f":"Minsc","d":1271891092,"b":[["t","I don't even understand what madhatter2 said.\n\nIt'd be nice to have just one single port to install and then I could just leave it as a terminate and stay resident program.  Then it would log payments received in a file and could be communicated with via shell commands."]],"u":"https://bitcointalk.org/index.php?topic=112.msg990#msg990"},{"f":"Link2VoIP","d":1271896306,"b":[["t","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. Wink"]],"u":"https://bitcointalk.org/index.php?topic=112.msg994#msg994"},{"f":"satoshi","d":1274151491,"b":[["t","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:"],["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'\n\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*)'","Quote"],["t","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.\n\nbitcoind runs as a daemon and can either be controlled by command line or JSON-RPC.\n\nThanks madhatter and generica for detailing the instructions for building on freebsd."]],"u":"https://bitcointalk.org/index.php?topic=112.msg1143#msg1143","s":1,"n":104,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/104/"}]},{"id":"p48","k":"p","s":"bitcointalk","t":"Ummmm... where did my bitcoins go?","u":"https://bitcointalk.org/index.php?topic=125","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/48/","m":[{"f":"Anonymous","d":1272846815,"b":[["t","adgadg"]],"u":"https://bitcointalk.org/index.php?topic=125.msg1049#msg1049","sj":"dasg"},{"f":"theymos","d":1272849503,"b":[["t","Did your new installation finish downloading all of the blocks (currently about 54,200)? The transaction probably won't appear until it does."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1050#msg1050"},{"f":"NewLibertyStandard","d":1272881875,"b":[["t","The blocks are currently about 34 MB. I'm sure future versions will improve the download process. Including them with the installation would not be correct way of speeding up the initial download. But a trusted source could certainly host the majority of the blocks as a separate download. That would definitely speed up the process, although I think that Bitcoin double checks each block that it downloads and it probably wouldn't double check each block if you just added the file to the bitcoin user folder."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1054#msg1054"},{"f":"NewLibertyStandard","d":1272900421,"b":[["q","34 MB... on a fast DSL plan, that should take a couple of minutes. Not 3 hours....","Quote from: davidonpda on May 03, 2010, 02:40:35 PM"],["t","Downloading the blocks as a single file would only take a few minutes but Bitcoin doesn't download the blocks as a single file. Try comparing the time it takes to copy a 50 GB file from one hard drive to another versus copying 50 GB of 1 KB files from one hard drive to another. The 50 GB of 1 KB files will take an eternity to copy. Try to do the same test over the Internet and the 50 GB of 1 KB files will take infinite eternities to finish. I believe Bitcoin already has a few small optimizations for how it downloads blocks but there is still a lot of room for improvement. On the bright side, Bitcoin only has to download old blocks once, after which it stays continuously up to date."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1056#msg1056"},{"f":"theymos","d":1272910759,"b":[["t","The BitCoin paper mentions \"simplified payment verification\" that could be used to accept payments without downloading all of the blocks. I don't know if this is implemented yet. It might only be enabled for clients that have \"generate BitCoins\" turned off."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1057#msg1057"},{"f":"NewLibertyStandard","d":1272937872,"b":[["q","The BitCoin paper mentions \"simplified payment verification\" that could be used to accept payments without downloading all of the blocks. I don't know if this is implemented yet. It might only be enabled for clients that have \"generate BitCoins\" turned off.","Quote from: theymos on May 03, 2010, 06:19:19 PM"],["t","Is that referring to sending bitcoins by IP address rather than by bitcoin address?\n-----\nFull Member! Woot Woot! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=125.msg1060#msg1060"},{"f":"theymos","d":1272939376,"b":[["t","No."],["q","It is possible to verify payments without running a full network node.  A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.","Quote from: BitCoin paper"],["t","So you would only download the most recent 200 or so blocks and then new blocks as they come in, relying on the network to verify the blocks for you. It would be a really lightweight way to use BitCoin. It would even be useful for \"full network nodes\" as they are downloading the whole block chain.\n\nCongrats on 100 posts!  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=125.msg1061#msg1061"},{"f":"The Madhatter","d":1273140585,"b":[["t","We should bundle a snapshot of the block chain with each release of the Bitcoin software to save the user from having to download the entire chain upon a new install.\n\nIn terms of trust: The user is already trusting bitcoin.org's download to be valid. Combining the zip/exe installer with a snapshot of the block chain is not a big deal in my opinion. They can publish hashes and signatures to ensure file integrity, etc.\n\nEven in a worst case scenario where the block chain snapshot was compromised nothing bad will happen. The longest block chain always wins. The client would download a new copy from the P2P network. (Besides, if the block chain was compromised we have bigger problems such as the software itself being trojaned, but this is another topic).\n\nIt's ++good!"],["q","34 MB... on a fast DSL plan, that should take a couple of minutes. Not 3 hours....","Quote from: davidonpda on May 03, 2010, 02:40:35 PM"]],"u":"https://bitcointalk.org/index.php?topic=125.msg1073#msg1073"},{"f":"laszlo","d":1273155101,"b":[["t","Really from a purist stance, people should audit the code and build it themselves.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1075#msg1075"},{"f":"satoshi","d":1274213206,"b":[["t","It's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time.\n\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?\n\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.\n\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.\n\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.\n\nIn the meantime, sites like vekja.net <http://vekja.net> and www.mybitcoin.com <http://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."]],"u":"https://bitcointalk.org/index.php?topic=125.msg1149#msg1149","s":1,"n":105,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/105/","qt":["Simplified 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."],"qc":["bitcoin-design"]}]},{"id":"p49","k":"p","s":"bitcointalk","t":"A New Currency System for the World","u":"https://bitcointalk.org/index.php?topic=128","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/49/","m":[{"f":"Derrick","d":1273252742,"b":[["t","Hello there,\n\nToday I wrote an article encapsulating my idea for a new currency system of the world.  One that is based on real value, open banking and technology.\n\nAfter publishing it, someone pointed out to me that there is in fact already a \"prototype\" of my idea in existence.   And they shared the link to Bitcoin.\n\nTo my pleasant surprise, the Bitcoin project is indeed a viable new world currency system based on the same principals I proposed in the article.\n\nSo I guess I just wanted to congratulate the developers on bringing your vision of Bitcoin to life - and that I'm excited to get involved in the project however I can."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1078#msg1078"},{"f":"dwdollar","d":1273288943,"b":[["t","Welcome Derrick!  Watch out everyone...  He's another one of those crazy Paulites! : P"]],"u":"https://bitcointalk.org/index.php?topic=128.msg1079#msg1079"},{"f":"dwdollar","d":1273291497,"b":[["t","Maybe when you get up to speed, you can be a spokesmen or something.  Trying to explain this to the people on Ron Paul Forums gives me a terrible headache."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1080#msg1080"},{"f":"The Madhatter","d":1273308737,"b":[["t","Nice article. Smiley\n\nWelcome to Bitcoin, Derrick."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1081#msg1081"},{"f":"hugolp","d":1273315131,"b":[["t","Another crazy paulite here...  Cheesy\n\nI am using this thread to introduce myself, since I have started using bitcoin because of this article link in RonPaulForums.org . I knew bitcoin from before and I though it was a interesting project it seemed too young at the moment. But after speaking with dwdollar over there, I decided to give it a try.\n\nBitcoin is running now in the linux server of my home (and it should be generating coins, I just dont know how long does it take to generate one). Its running on a atom 330 with 1gig RAM and not the processor nor the memory is going out of hand, but I have a problem. I connect to my server using a VNC connection. 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."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1082#msg1082"},{"f":"The Madhatter","d":1273316403,"b":[["t","Hello and welcome! Cheesy\n\nBitcoin is maturing nicely. More and more shops are accepting it as payment as time goes on.\n\nThe Atom processor is quite slow. Expect to wait a few days to gain some coins. The generation difficulty has been slowly climbing lately as well so that is also working against you. Tongue\n\nTry selling something for coins; that's the easiest way to get them and provide something useful to the Bitcoin economy.\n\nIt's ++good!"]],"u":"https://bitcointalk.org/index.php?topic=128.msg1083#msg1083"},{"f":"dsg","d":1273316912,"b":[["t","Welcome hugolp!\n\nRegarding your sluggishness, you can fix that by giving bitcoin a lower priority (it won't slow down generation normally, just means if you want to use the computer for something else that'll get priority) by a command like:\nrenice -n 15 $(pidof bitcoin)\n\nI'm sure there's a GUI option for it as well somewhere. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=128.msg1084#msg1084"},{"f":"The Madhatter","d":1273319808,"b":[["t","Also make sure your cpu fans are working, your heatsink is actually on, machine is clear of dust, etc or you might overheat."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1085#msg1085"},{"f":"hugolp","d":1273325579,"b":[["q","Welcome hugolp!\n\nRegarding your sluggishness, you can fix that by giving bitcoin a lower priority (it won't slow down generation normally, just means if you want to use the computer for something else that'll get priority) by a command like:\nrenice -n 15 $(pidof bitcoin)\n\nI'm sure there's a GUI option for it as well somewhere. Smiley","Quote from: dsg on May 08, 2010, 11:08:32 AM"],["t","Thanks. At the end I minimized bitcoin in the tray icon bar and the sluginesh disapeared. Now bitcoin its taking over the cpu (all the cores running at near 100%) but the machine works fine."],["q","Also make sure your cpu fans are working, your heatsink is actually on, machine is clear of dust, etc or you might overheat.","Quote from: The MadHatter"],["t","Thanks. The computer is running my Mythtv server and my torrents 24h so it would have broke alredy if it was in bad state. Also, the Atom 330 does not have a fan. Thre is a fan in the system but it is for the chipset. Curiously enough, Intel did not have time to optimize the chipset as much as the cpu, so the cpu is fanless but the chipset is not, unlike any normal computer system. The next Atom generation is coming or was released shortly and I believe they have integrated the cpu+gpu+memory management (and maybe other stuff) in one chip and the chipset part is small, so it will probably wont require fan. I am not sure if the cpu now requires fan, but if it does not its perfect for a home server. I was previously running a VIA chipset and I dont like Intel too much, but the Atom's are the best at their thing: Low power, low cost and best performance for those characteristics. The atom 330 even runs 720p video without problems (it can not handle 1080p)."]],"u":"https://bitcointalk.org/index.php?topic=128.msg1089#msg1089"},{"f":"The Madhatter","d":1273379947,"b":[["t","You'll want to renice +20 bitcoin then. I wouldn't dream of sharing a bitcoin in generation mode on a box that was playing videos. Choppy videos annoy the hell outta me.\n\nTongue"]],"u":"https://bitcointalk.org/index.php?topic=128.msg1090#msg1090"},{"f":"dianamonte03","d":1279250438,"b":[["t","So you think there are really new currency systems for the world? Most governments attempt to control of their currencies. When the government fixes exchange rates, there usually exists a black market. That is what I have learned in my Economics subject."]],"u":"https://bitcointalk.org/index.php?topic=128.msg3370#msg3370"},{"f":"Anonymous","d":1279253125,"b":[["q","So you think there are really a new currency system for the world? Most governments attempt to control of their currencies. When the government fixes exchange rates, there usually exists a black market. That is what I have learned in my Economics subject.","Quote from: dianamonte03 on July 16, 2010, 03:20:38 AM"],["t","They can only resist market forces for so long because Governments are restricted to a defined geographical area. Bitcoin has no boundaries or motives."]],"u":"https://bitcointalk.org/index.php?topic=128.msg3382#msg3382"},{"f":"satoshi","d":1279318809,"b":[["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.","Quote from: hugolp on May 08, 2010, 10:38:51 AM"],["t","0.3.1 fixes that, sets the generate threads to the lowest priority.  Download links are on the homepage now."]],"u":"https://bitcointalk.org/index.php?topic=128.msg3605#msg3605","s":1,"n":228,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/228/"}]},{"id":"p50","k":"p","s":"bitcointalk","t":"For a website taking payments with bitcoins, better: IP or bitcoin addresses?","u":"https://bitcointalk.org/index.php?topic=129","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/50/","m":[{"f":"Minsc","d":1273380241,"b":[["t","For a website taking payments with bitcoins, which is better: taking payments through IP solely or using tons of bitcoin addresses that you have to reuse and reuse?\n\nAnd why?"]],"u":"https://bitcointalk.org/index.php?topic=129.msg1091#msg1091"},{"f":"dwdollar","d":1273424590,"b":[["t","Right now, Bitcoin Addresses are the only option if you want automation.  If you're only taking donations, or only handling manual transactions, IP Addresses might be better suited.  That way they can send you comments or messages about their account info."]],"u":"https://bitcointalk.org/index.php?topic=129.msg1096#msg1096"},{"f":"dsg","d":1273424978,"b":[["t","Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity."]],"u":"https://bitcointalk.org/index.php?topic=129.msg1098#msg1098"},{"f":"Xunie","d":1273799817,"b":[["q","Bitcoin addresses also provide better anonymity. In my opinion they are ideal. Otherwise it's necessary to use tor or the like also to guarantee anonymity.","Quote from: dsg on May 09, 2010, 05:09:38 PM"],["t","Isn't that \"unsafe\"?\nSay I am an exit node listening for bitcoin transactions and grab them?\nOr is everything public/private key encrypted?[1]\n\n[1]Which is my guess."]],"u":"https://bitcointalk.org/index.php?topic=129.msg1120#msg1120"},{"f":"Xunie","d":1273873973,"b":[["q","Actually no, transfering coins via IP address isn't encrypted. When you transfer coins to an IP, the recipient creates a new address just for that transaction and tells you to transfer coins to that address. A malicious exit node could sniff all Bitcoin traffic and intercept those transactions easily.\n\nSo for everyone: DO NOT USE IP ADDRESSES AS DESTINATIONS, ALWAYS USE BITCOIN ADDRESSES.","Quote from: soultcer on May 14, 2010, 07:58:57 PM"],["t","I suggest we disable IP transactions while the user uses a Proxy!\nJust to be on the safe side."]],"u":"https://bitcointalk.org/index.php?topic=129.msg1124#msg1124"},{"f":"satoshi","d":1274045856,"b":[["q","I suggest we disable IP transactions while the user uses a Proxy!\nJust to be on the safe side.","Quote from: Xunie on May 14, 2010, 09:52:53 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=129.msg1131#msg1131","s":1,"n":99,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/99/"}]},{"id":"p51","k":"p","s":"bitcointalk","t":"Could the bitcoin network be destroyed by someone generating endless bitcoin add","u":"https://bitcointalk.org/index.php?topic=130","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/51/","m":[{"f":"Minsc","d":1273380311,"b":[["t","Could the bitcoin network be destroyed by someone generating endless bitcoin addresses nonstop?  I mean it sounds like it would do something really bad to it.\n\nI'm pretty sure at some point a website will take payments in bitcoins and will decide to generate a new bitcoin address for each payment and end up endlessly generating new addresses like mad and do something bad to the network.  Then more will start in."]],"u":"https://bitcointalk.org/index.php?topic=130.msg1092#msg1092"},{"f":"theymos","d":1273383297,"b":[["t","Generating addresses is CPU-intensive, and you don't touch the network when you generate a new address. It could only cause damage if a non-unique address was created, but this is so unlikely that it's not even worth considering."]],"u":"https://bitcointalk.org/index.php?topic=130.msg1093#msg1093"},{"f":"dsg","d":1273421522,"b":[["t","Yes.\n\nAlso, generating a new address for each payment is the best way to do it. Maximum anonymity because of least re-use of addresses. The keyspace is large enough that we don't need to worry about exhausting it."]],"u":"https://bitcointalk.org/index.php?topic=130.msg1095#msg1095"},{"f":"dwdollar","d":1273430828,"b":[["t","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.\n\nThe possibility of accidentally sending to a random BA is insanely small though."]],"u":"https://bitcointalk.org/index.php?topic=130.msg1099#msg1099"},{"f":"satoshi","d":1274043704,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=130.msg1130#msg1130","s":1,"n":98,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/98/","qt":["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."],"qc":["bitcoin-design"]}]},{"id":"p52","k":"p","s":"bitcointalk","t":"Exception: 9key_error error","u":"https://bitcointalk.org/index.php?topic=135","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/52/","m":[{"f":"bitcoin2paysafe","d":1273860470,"b":[["t","Today, I've got an error message:\n\nException: 9key_error\nCKey::CKey(); EC:KEY_new_by_curve_name failed\nbitcoin in ThreadBitcoinMiner()\n\nConsole:\n\nterminate called after throwing an instance of 'key_error'\n  what():  CKey::CKey() : EC_KEY_new_by_curve_name failed\nAborted\n\nI hope that isn't a buffer overflow. Have anybody this error message too?\n\nOS: linux"]],"u":"https://bitcointalk.org/index.php?topic=135.msg1122#msg1122"},{"f":"satoshi","d":1274050439,"b":[["t","Does it happen every time you run it, or just happened once at some random time?\n\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.\n\nThe code is:\n\nkey.h:\n    EC_KEY* pkey;\n\n        pkey = EC_KEY_new_by_curve_name(NID_secp256k1);\n        if (pkey == NULL)\n            throw key_error(\"CKey::CKey() : EC_KEY_new_by_curve_name failed\");\n\nNID_secp256k1 is a constant."]],"u":"https://bitcointalk.org/index.php?topic=135.msg1133#msg1133","s":1,"n":101,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/101/"}]},{"id":"p53","k":"p","s":"bitcointalk","t":"Odd amount of generated coins","u":"https://bitcointalk.org/index.php?topic=141","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/53/","m":[{"f":"dkaparis","d":1274348333,"b":[["t","Greetings,\n\nHow is the amount of bitcoins generated per block determined? It was my understanding that is is currently fixed to 50, however a few days ago I happened to generate amount of 52.64:\n\nStatus: 729 blocks\nDate: 05/15/10 08:38\nSource: Generated\nCredit: 52.64\nNet amount: +52.64\n\nHow comes?\n\nRegards,\nDimitri"]],"u":"https://bitcointalk.org/index.php?topic=141.msg1165#msg1165"},{"f":"NewLibertyStandard","d":1274389435,"b":[["t","Internally, bitcoins are bundled into packs of 50.00 or however many get sent over the network. Bitcoins usually have to be re-bundled each time they get sent. If a certain very large number of bitcoin bundles have to be re-bundled, there is a very small fee which the sender has to pay. The fee goes to the bitcoin client (yours in this case) which verifies the large re-bundling. It's not a well known behavior and I hope that future versions will display a warning or confirmation before such a fee is charged.\n\nThere is a post somewhere with more specific details. I'll look for it for a few minutes and I'll edit this post if I happen to find it. As always, the source code, which is open source, will reveal the exact behavior. I haven't examined the code and my description of the behavior is based on my poor memory, so it might not be exactly correct.\n\nEdit: Here's the explanation I mentioned <http://bitcointalk.org/index.php?topic=48.msg327#msg327>. It seems that if more than 500 bundles of bitcoins are re-bundled, there's roughly a 0.002% fee. So during that ten minute period, one or more people each re-bundled 500 bundles of bitcoins, totaling roughly 132,000 bitcoins.\n\nSince the sender pays the fee, I'd like to know what happens when a person sends all their bitcoins. I would expect that if there weren't enough bitcoins to cover the fee, then the amount of the fee which can not be paid would be subtracted from the payment. If this is not the case, then the fee could be avoided by sending all your coins to yourself before sending a large payment."],["q","A transaction over the size limit can still be sent if a small fee is added.","Quote from: satoshi on February 14, 2010, 06:28:03 AM"],["t","This makes it sound like a payment wouldn't send successfully if there were insufficient funds for the fee."]],"u":"https://bitcointalk.org/index.php?topic=141.msg1168#msg1168"},{"f":"satoshi","d":1274909672,"b":[["t","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?\"\n\nIf you don't have enough money with the fee added, it says\n\"Total exceeds your balance when the # transaction fee is included  \""]],"u":"https://bitcointalk.org/index.php?topic=141.msg1260#msg1260","s":1,"n":112,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/112/"}]},{"id":"p54","k":"p","s":"bitcointalk","t":"CLI bitcoin generation","u":"https://bitcointalk.org/index.php?topic=145","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/54/","m":[{"f":"molybdenum","d":1274553860,"b":[["t","So I'm poking around creating a simple web interface for simple bitcoin usage (something a little lighter and less stateful than a full-on wx/GTK GUI) and I haven't seen any way to see the status of generated blocks in progress of verification... I have seen my balance jump up by 50, but of course that doesn't show up in getallreceived.\n\nFor a headless coin generation box, being able to see my status right away would be nice, or at least, being able to know if I have 30 blocks awaiting confirmation, or am still trying to get the first... if it's purely automated and just checking-and-forwarding the balance, that's not a problem though.\n\nAdditionally, in the GUI client a transaction will appear as soon as it's seen, while getallreceived only shows a transaction after a block has gone by... yet the balance jumps up by the appropriate amount right away.\n\nI can imagine some poor nervous customer pacing back and forth worrying about his payment going through, when that wouldn't really be needed. While this *could* be used to cheat the system if a malicious machine managed to generate the winning block and exclude its own payment, but some instant indication that something was happening would be nice none the less even if it needed a \"don't accept transactions while the confirmations are still at 0\" warning tag... perhaps a separate function that included 0-confirmation transactions? 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)?"]],"u":"https://bitcointalk.org/index.php?topic=145.msg1194#msg1194"},{"f":"satoshi","d":1274904574,"b":[["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)?","Quote from: molybdenum on May 22, 2010, 06:44:20 PM"],["t","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.\n\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\n\nor listreceivedbylabel if you're labelling addresses with their username.\n\nSo far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet."]],"u":"https://bitcointalk.org/index.php?topic=145.msg1256#msg1256","s":1,"n":109,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/109/"}]},{"id":"p55","k":"p","s":"bitcointalk","t":"Bitcoin in Ubuntu 10.04","u":"https://bitcointalk.org/index.php?topic=149","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/55/","m":[{"f":"NewLibertyStandard","d":1274632092,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1203#msg1203"},{"f":"Xunie","d":1274649526,"b":[["t","Can you upload a screenshot? It'd help out great."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1205#msg1205"},{"f":"NewLibertyStandard","d":1276086913,"b":[["t","I didn't feel like editing images, so I just took a few partial screenshots.\n\nEdit: I just added a screenshot of the file menu in gcalctool as an example of how the menu should be displayed."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1428#msg1428"},{"f":"Xunie","d":1276487386,"b":[["t","I don't see any problems here, running 10.04 myself now!"]],"u":"https://bitcointalk.org/index.php?topic=149.msg1563#msg1563"},{"f":"NewLibertyStandard","d":1276496840,"b":[["t","The problem is with the default theme. You're screen shot is not the default theme."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1569#msg1569"},{"f":"virtualcoin","d":1277111316,"b":[["t","I'm new, but it works fine here. It's version 0.2 though.\n\nhttp://i45.tinypic.com/1z5knb8.jpg"]],"u":"https://bitcointalk.org/index.php?topic=149.msg1633#msg1633"},{"f":"dwdollar","d":1277126289,"b":[["t","I think the default theme in 10.04 makes everything look ugly.  And why are mini/maxi/close on the left side and not the right?  That's really annoying."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1637#msg1637"},{"f":"virtualcoin","d":1277126882,"b":[["t","I don't thinks it looks ugly.\nYou can change the buttons back to the right side if you wish, just google for it. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=149.msg1639#msg1639"},{"f":"satoshi","d":1277140821,"b":[["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.","Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM"],["t","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.\n\nI checked all the standard themes and it seems reasonable with all of them.\n\nUbuntu minimize,maximize,close buttons to the right:\ngconf-editor\napps->metacity->general\nbutton_layout=menu:minimize,maximize,close\n\nThey've got it awfully buried considering 9 out of 10 users are used to having it on the right."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1646#msg1646","s":1,"n":130,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/130/"},{"f":"lachesis","d":1277172254,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1650#msg1650"},{"f":"satoshi","d":1277178356,"b":[["t","On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.\n\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.\n\nUpdated SVN.\n\nThanks for testing."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1653#msg1653","s":1,"n":133,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/133/"},{"f":"lachesis","d":1277187472,"b":[["t","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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=149.msg1657#msg1657"},{"f":"satoshi","d":1277224783,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=149.msg1668#msg1668","s":1,"n":136,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/136/"}]},{"id":"p56","k":"p","s":"bitcointalk","t":"Website and software translations","u":"https://bitcointalk.org/index.php?topic=151","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/56/","m":[{"f":"HostFat","d":1274702201,"b":[["t","Can I help to translate the official homepage ( and main others ) into italian language?\nIs there a way to make it easy for many other random people that want to do the same?\n\nsirius-m: changed topic"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1212#msg1212"},{"f":"sirius","d":1274708034,"b":[["q","Can I help to translate the official homepage ( and main others ) into italian language?\nIs there a way to make it easy for many other random people that want to do the same?","Quote from: Joozero on May 24, 2010, 11:56:41 AM"],["t","Translations are very welcome! Translations show that there's a big community behind a project, and are of course helpful to those who don't speak English. You can post your translation in this thread as an attached txt-file. Please use the same html tags (h1, h2, h3, ul, li, strong, em, img, a) as in the English page. You can translate the front page and the FAQ, or just the front page if the FAQ feels too long. Trade page changes too often to be translated, and contact info is unnecessary for people who don't speak English.\n\nGerman, Spanish, Chinese and Russian translations would be especially helpful, as they're big language areas that have a lot of people who don't speak English. Of course other languages are good to have too.\n\nAttached: the English pages with html tags, to be used as a template for translation. Download notepad++ if you want syntax highlighting Smiley\n\nEdit 6.1.2011: You can add and update translations at https://en.bitcoin.it/wiki/Bitcoin.org_translations.\n\nUpdate 9.8.2013: Bitcoin.org translations: https://www.transifex.com/projects/p/bitcoinorg/"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1215#msg1215","sj":"Re: Homepage language"},{"f":"SmokeTooMuch","d":1274708314,"b":[["t","that reminds me of my intention to do a german translation ^^"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1216#msg1216","sj":"Re: Homepage language"},{"f":"D҉ataWraith","d":1274710843,"b":[["q","that reminds me of my intention to do a german translation ^^","Quote from: SmokeTooMuch on May 24, 2010, 01:38:34 PM"],["t","Eh, me too... this post finally got me started, actually. I'm using Google's Translation Toolkit, so if you want in on the fun, PM me with your Google account name, and I'll invite you to contribute to or comment on the translation."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1217#msg1217","sj":"Re: Homepage language"},{"f":"HostFat","d":1274710951,"b":[["t","Italian homepage Smiley"],["c","removed by sirius-m, sorry :P"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1218#msg1218","sj":"Re: Website translations"},{"f":"sirius","d":1274711279,"b":[["q","Italian homepage Smiley","Quote from: Joozero on May 24, 2010, 02:22:31 PM"],["t","Sorry, I ninja-edited my post while you were translating. Realized that an attachment is better than a long code block that makes the thread difficult to read (I'll remove it from your post).\n\nThanks for your translation, I'll add it!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1219#msg1219","sj":"Re: Website translations"},{"f":"HostFat","d":1274711418,"b":[["t","Ok, I'll translate FAQ also for sure Wink"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1220#msg1220","sj":"Re: Website translations"},{"f":"D҉ataWraith","d":1274712248,"b":[["t","Even though I've started using Google's Tools now, it would probably be a good idea to put all of this under version control. That'd also make it easier to see when the original page changes and you need to update the translation. I especially like how http://whygitisbetterthanx.com/ does it -- with one branch per language in a git repository (see bottom of page).\n\nEdit: Bitcoin front page is done. Would be good if someone else could proof-read it though. SmokeTooMuch?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1221#msg1221","sj":"Re: Website translations"},{"f":"SmokeTooMuch","d":1274735097,"b":[["t","In my opinion your translation is fine, DataWraith.\n\nJust two things:\n1. I think the \"f\" in Sourceforge should be uppercase. At least that`s what wikipedia tells me.\n2. "],["q","Abhängig davon, wieviel CPU-Zeit im Leerlauf Sie beitragen können, kann es einige Tage dauern bis die ersten Münzen erzeugt werden &endash; haben Sie also bitte etwas Geduld.","Quote"],["t","It sounds better when you write it like this:\nAbhängig davon, wieviel CPU-Zeit Sie im Leerlauf beitragen können, kann es einige Tage dauern bis die ersten Münzen erzeugt werden - haben Sie also bitte etwas Geduld.\n(the &endash; doesn`t get resolved correctly, you better check that again or replace it with a normal comma)"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1227#msg1227","sj":"Re: Website translations"},{"f":"sirius","d":1274810074,"b":[["t","Thanks for the German translation."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1233#msg1233","sj":"Re: Website translations"},{"f":"D҉ataWraith","d":1274822152,"b":[["t","My pleasure. Smiley\n\nI've fixed the problems SmokeTooMuch mentioned (thanks!) in the attached version. I also should have the FAQ translated soonish (first draft is done).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1239#msg1239","sj":"Re: Website translations"},{"f":"satoshi","d":1274908594,"b":[["t","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.\n\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.\n\nUpdated bitcoin.po attachment for 0.3.1"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1259#msg1259","s":1,"n":111,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/111/","qt":["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."],"qc":["releases"],"sj":"Re: Website translations"},{"f":"Xunie","d":1274937454,"b":[["t","I'm translating this into Dutch myself.\nDon't blame my grammar or anything if I screw up! Tongue"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1265#msg1265","sj":"Re: Website translations"},{"f":"D҉ataWraith","d":1274954789,"b":[["t","I'm done with the FAQ, it's attached to this post. I've also attached the front_page again, because the \"Advantages:\" before the list of bullet points needed to be in its own paragraph (I assume from the structure of the files that three blank lines serve as paragraph-break in whatever  CMS is used for the homepage).\n \nI'll also take a look at the .po-file, but it'll probably take a few days."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1266#msg1266","sj":"Re: Website translations"},{"f":"HostFat","d":1274958216,"b":[["t","Here there is the italian translation of the software.\nThere can be some mistakes, but it's just ok for the first version Smiley\nI hope that someone will come to do something better."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1267#msg1267","sj":"Re: Website translations"},{"f":"satoshi","d":1274969902,"b":[["t","Hurray!  We have our first language.  I uploaded it to SVN to go in with the 0.3 release."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1269#msg1269","s":1,"n":113,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/113/","sj":"Re: Website translations"},{"f":"Xunie","d":1274985003,"b":[["t","Here is the almost complete (93%) translation into Dutch.\nIt might contain some errors though.\n\nI can has credit now? Grin"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1271#msg1271","sj":"Re: Website translations"},{"f":"satoshi","d":1275517089,"b":[["t","I uploaded the 93% complete Dutch translation to SVN.  Thanks!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1324#msg1324","s":1,"n":116,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/116/","sj":"Re: Website translations"},{"f":"D҉ataWraith","d":1275564289,"b":[["t","Here's the German translation for the client.\n\nIt may require some modification, because, on average, German sentences are a third longer than English ones and thus may not fit the available space. Also, I couldn't test the access keys (e.g. E&xit) properly, so I may have introduced collisions there..."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1331#msg1331","sj":"Re: Website translations"},{"f":"Xunie","d":1275764565,"b":[["t","Hey Satoshi, if I translate to tlhIngan Hol (Klingon), will you add it to the SVN? Tongue"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1377#msg1377","sj":"Re: Website translations"},{"f":"SmokeTooMuch","d":1275788810,"b":[["t","lol!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg1386#msg1386","sj":"Re: Website translations"},{"f":"satoshi","d":1276707214,"b":[["t","Thanks DataWraith!  The German translation is uploaded to SVN.\n\nThis is great, we've already got 3 major languages."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1600#msg1600","s":1,"n":124,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/124/","sj":"Re: Website translations"},{"f":"sirius","d":1277215064,"b":[["t","I got the simplified and traditional Chinese translations of bitcoin.org front page from my friend Michael Chen. Thanks Michael!\n\nThe simplified page still says \"page not found\" for some reason, I'm trying to make it work.\n\nFor the record: the Dutch translation is by giik."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1661#msg1661","sj":"Re: Website translations"},{"f":"D҉ataWraith","d":1277239559,"b":[["t","Sirius, Can you update the German translation of the frontpage to the last version I posted? It contains the fixes proposed by SmokeTooMuch, foremost for the screwup with the &ndash; HTML entity. I'll attach it to this post again, for your convenience."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1682#msg1682","sj":"Re: Website translations"},{"f":"sirius","d":1277669925,"b":[["q","Sirius, Can you update the German translation of the frontpage to the last version I posted? It contains the fixes proposed by SmokeTooMuch, foremost for the screwup with the &ndash; HTML entity. I'll attach it to this post again, for your convenience.","Quote from: D҉ataWraith on June 22, 2010, 08:45:59 PM"],["t","Done. You don't need those extra line breaks in the cms.\n\nThanks to Jonatan Lehtonen for the Swedish front page translation."]],"u":"https://bitcointalk.org/index.php?topic=151.msg1839#msg1839","sj":"Re: Website translations"},{"f":"sirius","d":1278983647,"b":[["t","Anyone willing to help us with a Spanish, Russian or French translation here? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=151.msg2447#msg2447","sj":"Re: Website translations"},{"f":"Xunie","d":1279025374,"b":[["t","I have a friend who might be willing to translate it into Romanian, already dropped him a message."]],"u":"https://bitcointalk.org/index.php?topic=151.msg2542#msg2542"},{"f":"aidos","d":1279039616,"b":[["t","I'm working on the french translation Smiley"]],"u":"https://bitcointalk.org/index.php?topic=151.msg2575#msg2575"},{"f":"SmokeTooMuch","d":1279047355,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg2619#msg2619"},{"f":"milkiway","d":1279132634,"b":[["t","I'm working on spanish translation for the faq and the main web Wink\n\nAlso the soft, i just downloaded the po file"]],"u":"https://bitcointalk.org/index.php?topic=151.msg2906#msg2906"},{"f":"milkiway","d":1279139021,"b":[["t","Here is the spanish po file. When I can see it into the program, I'll check the translation errors and I'll try to fix it Wink\n\nTomorrow I'll start to traslate the main web and the last will be the faq  Wink\n\nPD: Can anyone post the last versión of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!\n\nEdit: I'll check and update the spanish po file  Wink"]],"u":"https://bitcointalk.org/index.php?topic=151.msg2933#msg2933"},{"f":"sirius","d":1279142071,"b":[["q","PD: Can anyone post the last versión of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!","Quote from: milkiway on July 14, 2010, 08:23:41 PM"],["t","I updated the .txt files in my post on the first page."]],"u":"https://bitcointalk.org/index.php?topic=151.msg2948#msg2948"},{"f":"aidos","d":1279154951,"b":[["t","Ok here is the .po file for French. While I'm at it, I noted a couple of issues:\n\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.\n2. 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.\n3. Some translated strings don't fit in the dialog box anymore (French is a bit more verbose than English). Some cases can be solved by inserting a \"\", but that's not always possible (window titles for example).\n4. 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.\n   - Many strings have all their words capitalized, which just looks strange in French. I checked, none of my other software do it, so I've used normal capitalization everywhere.\n   - There are a couple message strings that are almost identical, maybe using the same string for each of those messages would be better ? Example : \"This is an oversized transaction that requires a transaction fee of %s\" and \"Error: This is an oversized transaction that requires a transaction fee of %s  \". It's the exact same text except for \"Error:\" at the beginning and an extra space at the end (which is probably useless ?).\n\nFinally, The provided .po file is not up-to-date, as one of the settings string has changed, and is not getting translated (the one about starting Bitcoin at login).\n\nOtherwise Bitcoin seems like a great concept, good work !"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3017#msg3017"},{"f":"milkiway","d":1279182892,"b":[["q","> Quote from: milkiway on July 14, 2010, 08:23:41 PM\n> PD: Can anyone post the last versión of the main web and the faq in txt file? The txt's that I've downloaded are older. Thanks!\n\nI updated the .txt files in my post on the first page.","Quote from: sirius-m on July 14, 2010, 09:14:31 PM"],["t","Thanks! Wink"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3114#msg3114"},{"f":"milkiway","d":1279183142,"b":[["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.","Quote from: aidos on July 15, 2010, 12:49:11 AM"],["t","I noticed it right now. I must review the spanish po-file  Embarrassed"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3115#msg3115"},{"f":"milkiway","d":1279186510,"b":[["t","Here, the po file updated and the front page translated into Spanish Wink\n\nThis afternoon I'll start to translate the faq"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3123#msg3123"},{"f":"satoshi","d":1279218622,"b":[["q","Ok here is the .po file for French. While I'm at it, I noted a couple of issues:\n\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.","Quote from: aidos on July 15, 2010, 12:49:11 AM"],["t","I need to give an updated .po file."],["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.","Quote from: aidos on July 15, 2010, 12:49:11 AM"],["t","OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can."],["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.","Quote from: aidos on July 15, 2010, 12:49:11 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3238#msg3238","s":1,"n":196,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/196/"},{"f":"satoshi","d":1279219033,"b":[["t","I uploaded an updated bitcoin.po for 0.3.1 attached to this message:\nhttp://bitcointalk.org/index.php?topic=151.msg1259#msg1259\n\nplease use it if you're starting a new translation.\n\nIf you already have a po file, poedit can update it. \n- Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:\nhttp://bitcointalk.org/index.php?topic=383.0\n- Make a subdirectory under src: locale/??/LC_MESSAGES\n(?? could be anything really, \"en\" or your language 2-letter code)\n- Put your .po file there\n- Open it with poedit\n- In poedit, Catalog->Update from sources\n\nThe key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3242#msg3242","s":1,"n":197,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/197/"},{"f":"satoshi","d":1279219434,"b":[["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.","Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM"],["t","I updated them to 0.3.0.\n\nI am tempted to remove the download links from the other languages and only keep it on English.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3247#msg3247","s":1,"n":198,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/198/"},{"f":"satoshi","d":1279221134,"b":[["t","Thanks for the Spanish and French translations!  The edited and updated .po files are attached.\n\nI uploaded these to the SVN."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3257#msg3257","s":1,"n":199,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/199/"},{"f":"eurekafag","d":1279274553,"b":[["t","Working on Russian translation, will be available in a day or two."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3425#msg3425"},{"f":"eurekafag","d":1279280535,"b":[["t","BTW, there is a bug with translating this string:\n\n#: ../../../ui.cpp:634\nmsgid \"From: unknown, Received with: \"\n\nRussian translation doesn't show in the main window, only colons and comma appear. So it looks like: « : , : 18RRVv...» (cut the address) Looks like unicode problem, although there is correctly translated string in the first column (confirmations ⇒ подтверждений). Despite this the translation is almost complete but I have to be sure that everything looks like it should."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3440#msg3440"},{"f":"d1337r","d":1279291388,"b":[["t","BTW, translated the wiki page \"getting started\" to Russian. There should be a DokuWiki add-on or setting which displays the 'translations of this page' combobox like the home page of dokuwiki.org. For now, it's just a link in the getting started page."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3487#msg3487"},{"f":"eurekafag","d":1279292521,"b":[["t","Looks like the translation is nice, except the already mentioned bug. File attached.\n\nFix: I reuploaded the file with some corrects. I don't really get what does \"Net amount:\" mean so translated it literally."]],"u":"https://bitcointalk.org/index.php?topic=151.msg3501#msg3501"},{"f":"milkiway","d":1279373887,"b":[["t","Spanish FAQ translated.\n\nLater, I'll check if there are errors Wink"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3738#msg3738"},{"f":"milkiway","d":1279459539,"b":[["t","Spanish frontpage and FAQ cleaned for errors and updated.\n\nPlease, update from this two files. Thanks!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg3984#msg3984"},{"f":"sirius","d":1279471608,"b":[["q","Spanish frontpage and FAQ cleaned for errors and updated.\n\nPlease, update from this two files. Thanks!","Quote from: milkiway on July 18, 2010, 01:25:39 PM"],["t","Updated. Thanks."]],"u":"https://bitcointalk.org/index.php?topic=151.msg4020#msg4020"},{"f":"milkiway","d":1279477370,"b":[["q","> Quote from: milkiway on July 18, 2010, 01:25:39 PM\n> Spanish frontpage and FAQ cleaned for errors and updated.\n>\n> Please, update from this two files. Thanks!\n\nUpdated. Thanks.","Quote from: sirius-m on July 18, 2010, 04:46:48 PM"],["t"," Smiley"]],"u":"https://bitcointalk.org/index.php?topic=151.msg4033#msg4033"},{"f":"sirius","d":1279766059,"b":[["t","Thanks to Tao Wan for the Chinese FAQ. We'd appreciate if somebody could check the translation or fill in the missing questions."]],"u":"https://bitcointalk.org/index.php?topic=151.msg4927#msg4927"},{"f":"d1337r","d":1279815380,"b":[["t","Hmm.. Here are some \"beta\" versions of Russian translations for the site itself. (They are complete, but not perfect)"]],"u":"https://bitcointalk.org/index.php?topic=151.msg5065#msg5065"},{"f":"sirius","d":1279943406,"b":[["q","Hmm.. Here are some \"beta\" versions of Russian translations for the site itself. (They are complete, but not perfect)","Quote from: d1337r on July 22, 2010, 04:16:20 PM"],["t","Thanks. You can send updates when they're ready."]],"u":"https://bitcointalk.org/index.php?topic=151.msg5446#msg5446"},{"f":"NewLibertyStandard","d":1280048156,"b":[["t","It looks like a Russian branch of the wiki now exists. I imagine it would be a good idea to have the Russian Documentation link on the front page link to it."]],"u":"https://bitcointalk.org/index.php?topic=151.msg5666#msg5666"},{"f":"bitcoinex","d":1280090088,"b":[["t","Translation of bitcoin-0.3.2 into Russian"]],"u":"https://bitcointalk.org/index.php?topic=151.msg5747#msg5747"},{"f":"bitcoinex","d":1280090274,"b":[["q","Despite this the translation is almost complete","Quote from: eurekafag on July 16, 2010, 11:42:15 AM"],["t","Damn! I also made this work. I so wanted to be helpful!\n\n(But I insist that an \"unknown\" != \"anonymous\")"]],"u":"https://bitcointalk.org/index.php?topic=151.msg5750#msg5750"},{"f":"eurekafag","d":1280141507,"b":[["q","Damn! I also made this work. I so wanted to be helpful!\n\n(But I insist that an \"unknown\" != \"anonymous\")","Quote from: bitcoinex on July 25, 2010, 08:37:54 PM"],["t","Do you have the same problem with russian text in the main window?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg5830#msg5830"},{"f":"bitcoinex","d":1280178236,"b":[["q","> Quote from: bitcoinex on July 25, 2010, 08:37:54 PM\n> Damn! I also made this work. I so wanted to be helpful!\n>\n> (But I insist that an \"unknown\" != \"anonymous\")\nDo you have the same problem with russian text in the main window?","Quote from: eurekafag on July 26, 2010, 10:51:47 AM"],["t","I don't tried to build the program.\nIf you tell me what command builds this project under linux I can do it."]],"u":"https://bitcointalk.org/index.php?topic=151.msg5944#msg5944"},{"f":"bitcoinex","d":1280279110,"b":[["t","I propose to make national sections of the forum. As a minimum, the Russian section is ripe.\nhttp://bitcointalk.org/index.php?topic=593.msg6125"]],"u":"https://bitcointalk.org/index.php?topic=151.msg6126#msg6126"},{"f":"sirius","d":1280340369,"b":[["t","Russian board created. Let me know if there's demand for a board in some other major language."]],"u":"https://bitcointalk.org/index.php?topic=151.msg6241#msg6241"},{"f":"milkiway","d":1280583763,"b":[["t","Please, update the links for 0.3.6 version in the spanish translation!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg6809#msg6809"},{"f":"caveden","d":1281550836,"b":[["t","I'm translating the po file to Brazilian Portuguese."]],"u":"https://bitcointalk.org/index.php?topic=151.msg8777#msg8777"},{"f":"caveden","d":1281554127,"b":[["t","My first draft is attached, but it surely has issues (masculine/feminine, plural/singular, the placing of the & etc). Is there a way I could test the program with this translation in order to correct stuff?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg8785#msg8785"},{"f":"sirius","d":1282118939,"b":[["t","Anyone interested in making a French translation? Twitter shows there might be interest towards the project from that direction. Cool"]],"u":"https://bitcointalk.org/index.php?topic=151.msg10034#msg10034"},{"f":"checker","d":1282945607,"b":[["t","smf supports too much languages. If only u install them Smiley\nOr maybe i did'nt found where can i change it in profile settings?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg11437#msg11437"},{"f":"eurekafag","d":1285052899,"b":[["t","Updated russian translation. Now works fine without issues. Hope it will be included in the next version."]],"u":"https://bitcointalk.org/index.php?topic=151.msg13550#msg13550"},{"f":"grondilu","d":1285537551,"b":[["q","Anyone interested in making a French translation? Twitter shows there might be interest towards the project from that direction. Cool","Quote from: sirius-m on August 18, 2010, 08:08:59 AM"],["t","I see on this thread that some people made a french translation.  Still, I don't see it on the main page.\n\nI made one myself, in html format.  It's just a basic translation of the main page."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14164#msg14164"},{"f":"eurekafag","d":1285562155,"b":[["t","A little update on translation. Haven't understood \"matures in %d blocks\" phrase right but generated a block today and fixed this."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14200#msg14200"},{"f":"kaja","d":1285680791,"b":[["t","http://ompldr.org/vNW56aw/index.html ← The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).\n\nPlease do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop. "]],"u":"https://bitcointalk.org/index.php?topic=151.msg14393#msg14393"},{"f":"grondilu","d":1285701059,"b":[["q","http://ompldr.org/vNW56aw/index.html  The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).\n\nPlease do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop.","Quote from: kaja on September 28, 2010, 01:33:11 PM"],["t","Saluton, kaja !\n\nNi babilis en freenode #esperanto, cxu ne ?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14413#msg14413"},{"f":"grondilu","d":1285702811,"b":[["q","> Quote from: kaja on September 28, 2010, 01:33:11 PM\n> http://ompldr.org/vNW56aw/index.html  The main page in Esperanto. (I will eventually also translate the wiki and the FAQ).\n>\n> Please do this quickly as I suspect I may be able to get some small online Esperanto shops interested in the project, and maybe even a moderately large shop.\n\nSaluton, kaja !\n\nYour traduction doesn't seems very good.  For instance, we can't use 'kriptmonunuo' since the word 'kripto' doesn't mean 'to cypher' at all.  The correct esperantist world is 'Cxifri', I think.","Quote from: grondilu on September 28, 2010, 07:10:59 PM"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14414#msg14414"},{"f":"kaja","d":1285725871,"b":[["t",":O Grondilu, you are correct. I didn't know that kripto meant that. I thought it was a synonym for ĉifro!\n\nAnyway, that's fixed now. Are there any other errors? http://ompldr.org/vNW83OQ/index.html\n\nBy the way, the English word for 'traduction' is 'translation'. "]],"u":"https://bitcointalk.org/index.php?topic=151.msg14459#msg14459"},{"f":"grondilu","d":1285770907,"b":[["q",":O Grondilu, you are correct. I didn't know that kripto meant that. I thought it was a synonym for ifro!\n\nAnyway, that's fixed now. Are there any other errors? http://ompldr.org/vNW83OQ/index.html\n\nBy the way, the English word for 'traduction' is 'translation'.","Quote from: kaja on September 29, 2010, 02:04:31 AM"],["t","Cxifromono seems much better, I think.   I'm not a very experienced esperantist, so I'm not much confident about my skills to judge your translation.  I suggest you post your work on soc.culture.esperanto or something."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14531#msg14531"},{"f":"sirius","d":1285778004,"b":[["t","Thanks for the French and Esperanto translations!"],["q","I see on this thread that some people made a french translation.  Still, I don't see it on the main page.","Quote from: grondilu on September 26, 2010, 09:45:51 PM"],["t","I don't see a previous French translation of the main page."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14563#msg14563"},{"f":"grondilu","d":1285791927,"b":[["q","Thanks for the French and Esperanto translations!\n\n> Quote from: grondilu on September 26, 2010, 09:45:51 PM\n> I see on this thread that some people made a french translation.  Still, I don't see it on the main page.\n\nI don't see a previous French translation of the main page.","Quote from: sirius-m on September 29, 2010, 04:33:24 PM"],["t","It is now.\n\nHowever, I made a few mistake.\n\nHere is a slighlty modified version.\n\nAlso, the esperanto version is incorrect.  Please use this one instead."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14617#msg14617"},{"f":"kaja","d":1285811797,"b":[["t","How can I find the English .po file so that I may translate the software to Esperanto?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14636#msg14636"},{"f":"LZ","d":1285824614,"b":[["t","Edit any po-file, they all contain English strings. Esperanto? WOW! LOL! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14657#msg14657"},{"f":"grondilu","d":1285826975,"b":[["q","Esperanto? WOW! LOL! Cheesy","Quote from: lzsaver on September 30, 2010, 05:30:14 AM"],["t","Pretty cool, hum ?  :-)\n\nBut I'll feel much better when someone edit the current page and change the horrible word 'Kriptomonunuo' to 'Cxifromono'."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14660#msg14660"},{"f":"LZ","d":1285833838,"b":[["t","Yeah, it would be very funny. Cheesy\n\nI also have a claim to the translation but to the Bitcoin's Russian localization.\nWe have historically two variants of the word 'transaction'. One word is used\nin banks and business when it comes to money transfer, and another word is\nused in computer science: words 'трансакция' and 'транзакция' accordingly."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14673#msg14673"},{"f":"eurekafag","d":1285834119,"b":[["t","I updated the translation and replaced «транзакция» with more neutral and casual word «перевод». Also made some corrections on other phrases."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14675#msg14675"},{"f":"Golobulus","d":1285862246,"b":[["t","Hi guys,\n\nI only heard about the bitcoin project a few days ago from my friend and really liked the idea. Since then my PC has been trying to generate some bitcoins. Smiley\n\nI am going to translate the page to Polish. I assume all I do is just view the HTML source of the original page and replace English with Polish?\n\nThanks and regards."]],"u":"https://bitcointalk.org/index.php?topic=151.msg14707#msg14707"},{"f":"kaja","d":1285897242,"b":[["t","In addition to the kriptomonunuo problem, there's another problem that the righthand side menu for all languages is English no matter which language is selected!"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14796#msg14796"},{"f":"grondilu","d":1285899390,"b":[["q","In addition to the kriptomonunuo problem, there's another problem that the righthand side menu for all languages is English no matter which language is selected!","Quote from: kaja on October 01, 2010, 01:40:42 AM"],["t","Maybe you should pm sirius-m directly.\n\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 !"]],"u":"https://bitcointalk.org/index.php?topic=151.msg14799#msg14799"},{"f":"satoshi","d":1286156681,"b":[["t","Thanks eurekafag, Russian translation added to SVN rev 160."]],"u":"https://bitcointalk.org/index.php?topic=151.msg15176#msg15176","s":1,"n":483,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/483/"},{"f":"eurekafag","d":1286189756,"b":[["t","Glad to hear that. Where can I find the latest English .po file to keep the translation up-to-date?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg15248#msg15248"},{"f":"LZ","d":1286210047,"b":[["t","It does not exist."]],"u":"https://bitcointalk.org/index.php?topic=151.msg15316#msg15316"},{"f":"grondilu","d":1286212566,"b":[["t","Seriously : could anyone replace \"Kriptomonunuo\" by \"Cxifromono\" in the esperanto page ?   \"Kriptomonunuo\" is very ugly for it means \"the money unit from the crypt\".   In esperanto, \"kripto\" is the underground cell where we burry dead people.\n\nPlease !"]],"u":"https://bitcointalk.org/index.php?topic=151.msg15324#msg15324"},{"f":"sirius","d":1286217649,"b":[["q","I am going to translate the page to Polish. I assume all I do is just view the HTML source of the original page and replace English with Polish?","Quote from: Golobulus on September 30, 2010, 03:57:26 PM"],["t","Yes, but only the content part and no downloads."],["q","Seriously : could anyone replace \"Kriptomonunuo\" by \"Cxifromono\" in the esperanto page ?","Quote from: grondilu on October 04, 2010, 05:16:06 PM"],["t","Done Tongue"]],"u":"https://bitcointalk.org/index.php?topic=151.msg15344#msg15344"},{"f":"satoshi","d":1286220061,"b":[["q","Where can I find the latest English .po file to keep the translation up-to-date?","Quote from: eurekafag on October 04, 2010, 10:55:56 AM"],["t","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.\n\nSo for example, you have:\nsrc\nsrc\\base58.h\nsrc\\bignum.h\n...\nsrc\\util.cpp\nsrc\\util.h\nsrc\\xpm\nsrc\\locale\ru\\LC_MESSAGES\\bitcoin.po\n\nOpen bitcoin.po with poedit, do Catalog->Update from sources.  It looks for the sourcecode up 3 directories (..\\..\\..) from where bitcoin.po is.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg15360#msg15360","s":1,"n":484,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/484/"},{"f":"eurekafag","d":1286265048,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=151.msg15456#msg15456"},{"f":"satoshi","d":1286379759,"b":[["t","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?\n\nStrings aren't added or changed very often.  It's months before enough changes build up.\n\nI uploaded the changes.\n\nThis Windows build has the Russian translation in it:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe"]],"u":"https://bitcointalk.org/index.php?topic=151.msg15660#msg15660","s":1,"n":486,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/486/"},{"f":"eurekafag","d":1286393976,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=151.msg15697#msg15697"},{"f":"satoshi","d":1287701447,"b":[["t","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.\n\nI can still put it back into normal order by making poedit rescan it.\n\nIt is normal that untranslated strings are shown on top."],["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.","Quote from: eurekafag on October 06, 2010, 07:39:36 PM"],["t","I know, but not easily without complicating the sourcecode."]],"u":"https://bitcointalk.org/index.php?topic=151.msg17965#msg17965","s":1,"n":492,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/492/"}]},{"id":"p57","k":"p","s":"bitcointalk","t":"Share database blocks ?","u":"https://bitcointalk.org/index.php?topic=153","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/57/","m":[{"f":"HostFat","d":1274726629,"b":[["t","I have a question.\nI saw that everyone need to get blocks before starting to get coins.\nDoes it mean that these blocks are the same for everyone?\nIs there a database with all of them?\nSo ... can I share this database with someone else to make him able to generate coins after few seconds?\nI'm not sure if I have understood correctly how everything works\nIf I'm right ... can we share an always updated database of blocks somewhere on the official website?"]],"u":"https://bitcointalk.org/index.php?topic=153.msg1223#msg1223"},{"f":"Xunie","d":1274730540,"b":[["t","Well, what if the main website gets hacked and the blocks you are downloading are not the original blocks?\nI mean, this makes the network a hell of a lot of insecure."]],"u":"https://bitcointalk.org/index.php?topic=153.msg1224#msg1224"},{"f":"HostFat","d":1274730954,"b":[["t","I think that probably they won't be accepted by the majority of the network, that they have a different database/hash ... is it right?"]],"u":"https://bitcointalk.org/index.php?topic=153.msg1225#msg1225"},{"f":"Dynotor","d":1274736639,"b":[["q","I have a question.\nI saw that everyone need to get blocks before starting to get coins.\nDoes it mean that these blocks are the same for everyone?\nIs there a database with all of them?\nSo ... can I share this database with someone else to make him able to generate coins after few seconds?\nI'm not sure if I have understood correctly how everything works\nIf I'm right ... can we share an always updated database of blocks somewhere on the official website?","Quote from: Joozero on May 24, 2010, 06:43:49 PM"],["t","I'll defer to others on whether having a central database is a good idea, but if you're creating multiple directories with the -datadir command line option, you can safely bootstrap that directory by copying \"blkindex.dat\" and \"blk0001.dat\" from an already established data directory into your new one.  "]],"u":"https://bitcointalk.org/index.php?topic=153.msg1228#msg1228"},{"f":"molybdenum","d":1274758857,"b":[["t","While a central database, or at least a partially-completed centralized copy of a certain number of blocks would speed things up, but then, so would mass-transfer between clients (requests for 500 blocks or so instead of one blocks at a time) and the latter would implement it within the confines of the network, without needing web hosting for a copy of the block database.\n\nCurrently, I believe one could grab a copy of someone else's blk*.dat files and speed the process up that way, but it really shouldn't be needed when the same thing can be done with a few snippets of code.\n\nA draft standard for the bitcoin wire protocol would possibly be a help here, in that it would be possible for someone C++-illiterate to see what actually is possible in the current system ;-)\n\nEDIT: if I understand correctly, a complete false start that wouldn't disappear as soon as a client connected to the network at large would require generating as many blocks as were currently in the network, so, one individual would have to generate 57525 blocks to do major harm to the network.\n\nIt could give someone a head start in forging a block, but not really. Having a rouge starter set of blocks would be just like having each new node started from that set of blocks be a rouge node, so it should be similarly impractical to forge anything."]],"u":"https://bitcointalk.org/index.php?topic=153.msg1229#msg1229"},{"f":"NewLibertyStandard","d":1274762645,"b":[["t","Most of the slowness results from the blocks needing to be verified one at a time in order, not from network delays. At least according to, if I'm not mistaken, satoshi, the Bitcoin author, in another thread. There has been some talk about a lightweight client, which doesn't verify all the blocks, but instead only broadcasts transactions. I'm not familiar with the algorithm, but if it's possible, I think it would be best to just alter the regular client so that when it starts up the first time, it grabs the most current block and verifies blocks in reverse order while also continuing to verify new blocks. That way Bitcoin could start generating blocks immediately."]],"u":"https://bitcointalk.org/index.php?topic=153.msg1230#msg1230"},{"f":"Xunie","d":1274771905,"b":[["q","I'm not familiar with the algorithm, but if it's possible, I think it would be best to just alter the regular client so that when it starts up the first time, it grabs the most current block and verifies blocks in reverse order while also continuing to verify new blocks. That way Bitcoin could start generating blocks immediately.","Quote from: NewLibertyStandard on May 25, 2010, 04:44:05 AM"],["t","Good idea, but we would need some form of indicator it did that to the user, and warn the user about the potential hazards.\n(Atleast, that's my idea.)"]],"u":"https://bitcointalk.org/index.php?topic=153.msg1231#msg1231"},{"f":"laszlo","d":1274789663,"b":[["t","It only verifies the last few as it is, to speed things up, but it doesn't work backwards.\n\nSatoshi has mentioned a simplified payment verification system that he is planning to implement, which would allow payment only clients which do not have to verify all the blocks - he just hasn't written it yet.\n\nI think even if you could just have someone 'click here to install instantly' it wouldn't do any good because they wouldn't have any bitcoins and they wouldn't know what a bitcoin is Smiley"]],"u":"https://bitcointalk.org/index.php?topic=153.msg1232#msg1232"},{"f":"NewLibertyStandard","d":1274818670,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=153.msg1235#msg1235"},{"f":"satoshi","d":1274906074,"b":[["t","It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks.\n\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.\n\nHow long is the initial block download taking for you?"]],"u":"https://bitcointalk.org/index.php?topic=153.msg1258#msg1258","s":1,"n":110,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/110/"}]},{"id":"p58","k":"p","s":"bitcointalk","t":"Tracing a coin's lineage","u":"https://bitcointalk.org/index.php?topic=154","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/58/","m":[{"f":"Dynotor","d":1274812039,"b":[["t","Assuming a goal of bitcoin is to introduce anonymity to online transactions, one of the things that concerns me most is the traceability of coins to previous transactions.  I've read a lot of discussion about this in the forums, but there's still some open questions for me. \n\nSo first, let me state what I do understand:\n\n1) All transactions are public in their amounts and public key identities as follows:\n  a) In a transaction, you can see the public key of the person who spent the money\n  b) In a transaction, I *think* but am not completely sure you can see the public key of the person who gets the money.  (If you can't, you'll see it when they spend the money later, so this isn't that important.\n\n2) Keeping your public keys from being associated with your identity is required if you don't want your transactions to be attributable to you.\n\nWe need to better educate users on how to do #2.  I have an information security background, and it's not even immediately obvious to me what the best ways of handling bitcoins are to maximize your privacy.\n\nI have these specific questions or comments regarding this topic:\n\n1) Are one-time public keys disposed of when they are no longer required?\n\nFor example, I've read that a one-time-use private key is created when I generate a bitcoin block.  When I spend these coins and I've signed them to someone else, I shouldn't need that private key anymore.  The same thing goes for a key created for taking a payment-by-IP.  Keeping keys around after they are no longer necessary may make a user vulnerable to later having their wallet seized and used to prove that they originated a transaction.\n\n2) Reusable keys (those created inside the GUI) should be able to be similarly deleted when they are no longer required.  This is a bit more dangerous, because once you delete the key you won't be able to get payments sent to that key, so the user really needs to understand what's going on in this case.  Keys with coins stored under them obviously shouldn't be deleted. \n\n3) We really need to make it possible to track coin bundle's lineage to enable the user to know their risk regarding spending specific coins.  I think it should be possible, within the GUI, to see all the public keys associated with each coin bundle.  It would also be nice to be able to tag keys that are associated with you with comments to aid you in determining which coins to send to someone.  That way you could realize that another bitcoin user has seen you use a specific key, and to restrict other coins that are also associated with that key to a similar purpose and not something else that would link the two identities.\n\n4) In addition to making it possible to track a coin bundle's lineage, we also need to be able to choose which coin bundles to include in a payment.\n\nThe important thing here is that we need to make the information that is possible to acquire through digital forensics to be easily accessible by the end user.  Only by making this information accessible to the end user will people be able to make good security decisions regarding the spending of bitcoins in sensitive environments.\n\nOne more thing that is important: Once these features are available, exchangers need to have clear data retention policies.  For example, if I was an exchanger, I might keep track of the public keys of the people that I am doing active trades with.  I'd probably retain this information until I had traded out the coins I had acquired through a trade, but would dispose of this information once the coins had left my possession.  I would also have a policy to not share that information with third parties unless required to by a court order.  If I was trading with an exchanger, I would want to know what their policies were and how they differed from my expectations. "]],"u":"https://bitcointalk.org/index.php?topic=154.msg1234#msg1234"},{"f":"Xunie","d":1274821971,"b":[["t","The points you mentioned are of high concern to me (and should be to the rest of the community.)\nYour suggestion of making the information that can found with/through digital forensics available to the user seems very good in securing Bitcoin.\nMaybe build a \"paranoid mode\" switch in Bitcoin that will immediately show all that info to the user!\nAlso what seems like a good idea is to show that switch in a \"first run dialog\", but some people find that annoying. (I would too a business environment!)\nMaybe distribute a \"Home\" and \"Business\" binary that has the \"first run dialog\" and one without it, ofcourse in that order.\n\nBut, as this data is available, and people will trust Bitcoin (sometimes blindly), we'll have to warn users about pitfalls.\nHave proper documentation documenting everything, even for the \"paranoid users\".\nUsers will have to learn how to make safe transactions, etc...\n\nIf someone screws up and gets screwed over by the justice system because he trusted Bitcoin blindly, he'll speak about it and Bitcoin will get a bad name.\n\nMy conclusion: the Bitcoin community needs to watch out for the losers dumb users lusers!"]],"u":"https://bitcointalk.org/index.php?topic=154.msg1238#msg1238"},{"f":"D҉ataWraith","d":1274822945,"b":[["t","It's good that someone is thinking along the lines of how security/anonymity could be compromised.\n\nYes, you know both sender and recipient of a payment. The recipient's key is always included, and from there you can trace the coin back to the previous recipient, i.e. the current sender.\n\nMy 2฿ worth of thoughts:\n\nIdeally the Bitcoin wallet should be encrypted, and future versions will implement that. Now, leaving malware out of the picture (which would probably just send all bitcoins to the hacker in question instead of tracing transactions back), when both your computer is confiscated and you are forced to reveal the password, you're probably already in big trouble... you'd have to already have screwed up other than by using bitcoin in an unsafe manner. Personally I don't worry about this, but it is good that somebody does.\n\nAs an aside: Bitcoin can be used over the TOR network, so one can hide one's IP address. There are also the web-based wallet services, which might make it harder to trace a transaction that went through them. On the other hand, they could do some tracing of their own... The deciding factor here is which coins are chosen for which transactions.\n\nAs for coin lineage, yeah, that might be a problem. Currently it is a best practice to give out a different address to every sender, and only give it to them. An outside observer you can't know if the next recipient (or rather crypographic key) the coin is sent to is one of your aliases or someone else entirely. Bitcoin Currency Exchanges (or any high-volume user) might be a problem here, but otherwise one probably doesn't have enough data to infer much about the transfers, it just becomes untractable if every person has a lot of different addresses. One additional point here is that old transactions expire after a while, and the space is reclaimed -- that wouldn't stop a serious attacker, but it's helping a little."]],"u":"https://bitcointalk.org/index.php?topic=154.msg1240#msg1240"},{"f":"Xunie","d":1274835004,"b":[["t","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. (We wanna minimize \"lost\" Bitcoins, right?)\n\nThis yields a couple of questions:\n\n• Is this technologically possible? (Probably.)\n\n• Is this bad to force it upon users? (Probably.)\n\n• Should we implement such a feature? (I don't know, I wouldn't unless we don't have a choice, better half a defense than none!)\n\nSo, are there any alternatives to combat \"coin lineage\"?"]],"u":"https://bitcointalk.org/index.php?topic=154.msg1242#msg1242"},{"f":"theymos","d":1274845190,"b":[["t","BitCoin could automatically send random coins to a new address at random times. This would make knowing a coin's lineage useless to an attacker, since any of these new addresses could be actual people."]],"u":"https://bitcointalk.org/index.php?topic=154.msg1244#msg1244"},{"f":"satoshi","d":1274899864,"b":[["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.","Quote from: Xunie on May 26, 2010, 12:50:04 AM"],["t","This is on my list.  I will soon make the \"Your Bitcoin Address:\" window automatically change whenever you receive anything to the address displayed.\n\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.\n\nVersions on SVN since 0.2.4 already have a \"New...\" button next to the address bar to encourage changing it manually too.\n\n@theymos: If nothing else, we can fall back on that solution in the future."]],"u":"https://bitcointalk.org/index.php?topic=154.msg1254#msg1254","s":1,"n":108,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/108/"}]},{"id":"p59","k":"p","s":"bitcointalk","t":"JSON-RPC programming tips using labels","u":"https://bitcointalk.org/index.php?topic=157","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/59/","m":[{"f":"satoshi","d":1274898445,"b":[["t","I added label related functions to help with managing multiple addresses per user.  New or renamed functions are:\n getreceivedbyaddress -- amount received on a single address\n getreceivedbylabel -- amount received by all addresses with this label\n listreceivedbyaddress -- list addresses and amounts they've received\n listreceivedbylabel -- list labels and amounts they've received\n setlabel -- misc label functions for completeness\n getlabel\n getaddressesbylabel\n\nFor consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress.  The old names are still there so as not to break existing code, but they're deprecated.\n\nThe idea is that if you give the username whenever you call getnewaddress, you can get the user's total received across all their addresses using the \"bylabel\" functions.  You can freely change their address without worrying about tracking all their old addresses.\n\nA good way to automate changing the user's receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:\n\n// Get a new address whenever the current one has received anything\nif (strAddr == \"\" || getreceivedbyaddress(strAddr) > 0)\n   strAddr = getnewaddress(strUsername); // Label the address with username\nDisplay(strAddr); // Display their current receiving address\n\n// Get total received by all the user's addresses\ngetreceivedbylabel(strUsername, 0) // unconfirmed\ngetreceivedbylabel(strUsername, 1) // available balance\n\nIf you're just getting one particular user's balance, such as in response to a page request by that user, use getreceivedbylabel, but if you're scanning over all users, it's better to use listreceivedbylabel to get the complete list and scan against the result.  Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).\n\nYou should only really need to scan all users if you're polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it.  It's not necessary to poll very frequently.  If you require 1 confirmation, that'll take an average of 10 minutes anyway, so there's no point in polling more often than every few minutes.\n\nIf you're selling digital goods and services, where you don't lose much if someone gets a free access, and it can't be resold for profit, I think you're fine to accept 0 confirmations.\n\nIt's mostly only if you were selling gold or currency that you'd need multiple confirmations."]],"u":"https://bitcointalk.org/index.php?topic=157.msg1252#msg1252","s":1,"n":107,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/107/"}]},{"id":"p60","k":"p","s":"bitcointalk","t":"Hostnames instead of IP Addresses","u":"https://bitcointalk.org/index.php?topic=158","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/60/","m":[{"f":"SirArthur","d":1275107932,"b":[["t","At least the Windows client seams unable to resolve hostnames - or doesn't even try, pops up an \"Invalid Address\" right away.\n\nThis is a huge setback taken most people have dynamic IP Addresses. Therefore, instead of \"123.123.123.123\" only it should be added the hability to send also to \"someone-accepting-bitcoins.somedomain.sometld\"."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1284#msg1284"},{"f":"Xunie","d":1275151284,"b":[["t","Or it should just look the hostname up before it dismisses it as an invalid address.\nThis has probably just slipped the mind of the developer."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1292#msg1292"},{"f":"laszlo","d":1275390062,"b":[["t","There are security implications with sending payments to a 'hostname' instead of an internet address.  TCP is difficult to forge, however DNS is trivial.  It is not a good idea to send payments to a hostname.  Whether it is an oversight or intentional, it probably should not be used for anything where fraud is a concern.\n\nHere's something I quickly googled up for anyone interested: http://adventuresinsecurity.com/Papers/DNS_Cache_Poisoning.pdf\n\nIt is not even really an attack, it's just how it works..  This is why once people figured out that DNS was unreliable, things like .rhosts for rsh went out of style and ssh uses public keys instead.  It still does some DNS checking to see if the key changed, which could indicate that the DNS has been used to divert your connection to another host.\n\nIt is very easy for me to make your computer think that someone-accepting-bitcoins.somedomain.sometld is MY computer, especially if I know you will be sending payment to it.. however if somedomain.sometld is some popular well known service like an exchange, I can just go trying to poison every bitcoin user's cache randomly and see how many I get.  I know every node's network address so I can figure out who their provider is, thus I can easily narrow down which recursors they're likely to be using, so it makes attacking it a lot nicer rather than blindly messing with a bunch of random resolvers that may or may not have any effect.\n\nMany internet DNS servers will just accept any random data you send them, though there have been attempts to patch these things and work around some of the really trivial attacks.  In the end though, it is the DNS protocol that's at fault and it is not easily patchable without replacing it.  There are things in the works to make the protocol more secure and such, but until it's adopted by the entire internet, there will always be places to mess with it.\n\nIt is not even a good idea to send payment to an internet address in my opinion, because the way it is implemented in bitcoin right now, you don't know if you connected to the right node.  There is no pre-shared password or public key to verify manually.  While it is not feasible to take over an existing TCP connection, it is possible to use NAT to divert it.  In this case the attacker would have to have control of a router along the way to your destination, but in the case of Tor anyone can run an exit node and just accept all the bitcoin payments.. it's really easy to do that because they're all on port 8333 so I can just DNAT every connection to 8333 to my own bitcoin host.\n\nJust don't use hostnames or internet addresses - use bitcoin addresses."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1317#msg1317"},{"f":"SirArthur","d":1275392251,"b":[["t","Here we go again...\n\nYES, you can be phished, hijacked, whatever... but, again, it has to rely on informed options rather than behaviors of \"I decided this is more secure to you\". "]],"u":"https://bitcointalk.org/index.php?topic=158.msg1319#msg1319"},{"f":"laszlo","d":1275394643,"b":[["t","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.\n\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.\n\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.\n\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.\n\nLaszlo"]],"u":"https://bitcointalk.org/index.php?topic=158.msg1320#msg1320"},{"f":"satoshi","d":1275502695,"b":[["t","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.\n\nThe future plan for sending to an IP is to make it a bitcoin address plus IP, like:\n\n1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4\nor\n1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.com\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1322#msg1322","s":1,"n":114,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/114/"},{"f":"theymos","d":1275533779,"b":[["t","How about $ ? It's distinctive, allowed in URLs, and related to money. You could also surround the authentication address in parentheses to emphasize that coins should not be sent to that address directly.\n\nI really like that authentication method."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1330#msg1330"},{"f":"Gavin Andresen","d":1275575396,"b":[["t","Seems like $ would be inviting confusion, since it's followed by numbers that can look kind-of like a dollar amount:\n19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3$64.20.45.38\n\nmeans send $64.20 to my bitcoin address ?\n\nHyphen or underscore would be less confusing, but I think period would work really nicely:\n\n19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.64.20.45.38\n19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com\n\nThe advantage of that last one is it is a valid URL;  if a user pasted that into Firefox's URL bar or searched for it in Google the website owner could display a helpful web page explaining how to pay."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1332#msg1332"},{"f":"laszlo","d":1275585563,"b":[["t","Maybe you just use a regular old URL or URN.. Kind of like namespaces in XML.\n\nURN:\nurn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78\n\nURL (not for using with a web browser, but it's unique):\nhttp://bitcoin.org/12.34.56.78/19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3"]],"u":"https://bitcointalk.org/index.php?topic=158.msg1333#msg1333"},{"f":"theymos","d":1275586478,"b":[["q","19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3.skypaint.com","Quote from: gavinandresen"],["t","That's ambiguous. How do we know whether to send coins securely to skypaint.com or insecurely to the IP address that the entire thing resolves to?\n\nHaving an informational page at the subdomain would be pretty awesome, though. Maybe it's worth implementing around the ambiguity."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1334#msg1334"},{"f":"SirArthur","d":1275616492,"b":[["t","The idea of send by DCC is to simplify.\n\nIt's not like put 1000 USD over a rock, the attacks are \"theoretically easy\" but on practical not, unless your ISP attacks you... but if it does so, why not attack your bank account instead? Except maybe for cable access where your neighbor can sniff you.\n\nThis bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78 is about as practical as nothing. What would be the simplification-add of such? Try to say to someone over the phone your BC address on such manner.\n\nLet's do one thing, right: PUT TOR ASIDE. One thing is using BC for anonymous payments / OTHER is to make non-anonymous payments.\nIf you're up to do anonymous payments, that's already sorted: Use BC address and that's it.\n\nIt's then a matter of choices, if for security reasons you feel more confortable with it disabled, do it like: Disabled by default / Enable if you want and know what you're doing.\n\nSomeone could hijack my site and show another BC address\n-Someone could hijack your site and show another PayPal email also. Defacings aren't however easy to do, you don't see sites defaced everyday.\n\nSomeone could hijack DNS to resolve to something else\n-Someone could hijack your bank's login and make you pass over your password to it... again DNS hijack/spoof isn't also that easy to do. Theoretically (again) it is, but that would be if you were using some bogus Nameserver. If you use your ISP defaults it would be rather complicated. And if someone invaded your PC to make it change DNS's, then that same one would open your BC Client and send all your BC's to his address.\n\nSo, in the end, my proposal is:\n\nSplit the \"project idea\" in two different (way different) branches:\n\n1 - Anonymous payments - Using BC Address exclusivelly\n2 - Non-anonymous (regular) payments - Using BC Addresses OR DCC.\n\nIt makes no sense at all to use Tor arguments over branch 2."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1342#msg1342"},{"f":"laszlo","d":1275619521,"b":[["t","Bank sites and such use end to end encryption which makes intercepting more difficult and there is usually two way authentication.  The website authenticates itself to you by showing you your personally selected image/phrase, thus you recognize that this is the site you wanted to visit, and then you authenticate to the website so they recognize you as the customer you claim to be.  It's not perfect but it's like putting a pad lock on a box full of money to keep honest people honest.  Sometimes they use a bigger/thicker pad lock so the effort/gain ratio makes it not really worth trying to break it.\n\nI agree with you in a way about security, if it's too inconvenient then it's not very useful... though encryption and authentication are generally good enough to deter trivial things and they provide some reassurance.\n\nIt is certainly convenient to be able to send to a paypal email address, but even there you get two way authentication.  PayPal will display the name of the person you're sending to, before you commit to how much you're sending.  PayPal is very popular and is riddled with fraud.. if Bitcoin was accepted on Ebay and the IP address based sending was used as it is today, it would never get there because people would just intercept it along the way, TOR or not.\n\nIf you've used ssh you know that uses two way authentication as well - you verify the server's key visually before you present your own authentication credentials.  This technique is problematic in a way because if it's the first time you're connecting you don't know what it should be.. you have to call up the person operating the server and ask them to read you the key.  I think the idea of putting it into the URL or other address notation is that you declare what you expect it to be and the local client will tell you if the peer presents something different.  I suppose you could go the ssh route, just let someone accept whatever is presented.. though right now the key is dynamically generated, it could be changed so that it would present some key that changes once a day or something.. then you could show it on the web site that's expecting the payment, but then why wouldn't you just show the bitcoin address itself and send that way.\n\nI guess I don't really understand your point with simplification.. if you have to copy/paste an address already, what does it matter if it's an internet address, a DNS address or a bitcoin address?"]],"u":"https://bitcointalk.org/index.php?topic=158.msg1343#msg1343"},{"f":"SirArthur","d":1275622018,"b":[["t","Put things this way; if you manage (on a more or less distant future, don't know) to run sort of a shop on surface web* with BC, you may want:\n\n» Your customers to be identifiable - to know who is paying what and handle refunds\n» Your customers to leave notes along with the payment.\n» Your customers to have a friendly address to pay to (not an IP, not an unreadable hash) - unless you run thenerdsshop.com there is.\n» Your customers to not be nagged.\n\nFor this would be obviously interesting a TLS/SSL feature. Imagine this operation:\n\nClient -> send BC 50 to bcpay.mysite.com\nbcpay.mysite.com -> send a certificate with the store's data, client's get a popup with this server's information to confirm\n\neg:\nYou're about to make a payment to the following Bitcoin client:\n\nSITE NAME: mystore.com\nCOMMON NAME: Payments Gateway\nCA VERIFIED BY: BitcoinSSL\n\nClient -> Confirm ? payment is sent: payment is cancelled.\n\n* Tor users: Let's call it a surface web shop shipping goods to your house, so you wouldn't go there anyway. What would be the point of hide your IP while give your home address?"]],"u":"https://bitcointalk.org/index.php?topic=158.msg1345#msg1345"},{"f":"lachesis","d":1276266835,"b":[["t","I don't see why these two ideas are mutually exclusive, although I'd assume implementing SSL/TLS is not trivial. We do already link to the OpenSSL library, so I don't know.\n\nI personally would prefer a urn scheme to handle a bitcoin address."],["q","urn:bitcoin.org:19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3@12.34.56.78","Quote from: Lazslo"],["t","That would be perfect, although I would prefer to use the hostname on the right side.\n\nOf course, I'm the kind of guy who might shop at thenerdsshop.com Smiley\n\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.\n\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"],["c","<link rel=\"bitcoin.address\" href=\"19vcWM6EEbQHVdN2W8NXv9ySgsPjbZ6gU3\">\n<link rel=\"bitcoin.server\" href=\"12.34.56.78\">"],["t","Or some other form and try to send securely to that."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1482#msg1482"},{"f":"satoshi","d":1276545224,"b":[["t","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.\n\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.\n\nThe user would send to domain.com (or www.domain.com <http://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.\n\nThe SSL also makes it safe for TOR users.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=158.msg1582#msg1582","s":1,"n":118,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/118/"}]},{"id":"p61","k":"p","s":"bitcointalk","t":"Can't Build r80 from SVN","u":"https://bitcointalk.org/index.php?topic=163","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/61/","m":[{"f":"lachesis","d":1275699814,"b":[["t","I can't build r80 from the SVN with -O2 in the makefile. I'm running Ubuntu 10.04 LTS 64-bit on an Intel Core 2. If I remove -O2 (switch back to -O0), it builds fine.\n\nThe problem seems to be line 15 of net.h. My googling suggests that statement-expressions, some non-standard, GCC-only extension to C++, are not allowed outside of functions at that level of optimization. htons is implemented as a statement-expression for linux. I managed to get it to build by replacing the htos(8333) with 0x8D20, which is 8333 in network byte order. This compiles and runs fine on my Intel processor, but probably wouldn't work on a big endian processor like a PowerPC.\n\nIs anybody else experiencing this bug?\n\nAlso, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1358#msg1358"},{"f":"laszlo","d":1275707568,"b":[["t","You did the right thing.. none of it works on big endian anyway."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1360#msg1360"},{"f":"D҉ataWraith","d":1275755771,"b":[["q","Is anybody else experiencing this bug?\n\nAlso, I'm somewhat disappointed. -O2 didn't help me generate hashes any faster. Perhaps I'll try -O3.","Quote from: lachesis on June 05, 2010, 01:03:34 AM"],["t","Yeah, I had the same problem.\n\nBtW: If you look at the makefile, sha.{h,cpp} are already compiled -O3; using a higher optimization level for the remainder of the program is probably not going to help much."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1374#msg1374"},{"f":"laszlo","d":1275762733,"b":[["t","-O2 is generally the preferred optimization for gcc, -O3 can produce larger code which is slower, but you should experiment around with it.. it also seems to depend on the time of day or the phases of the moon for me at least, some days I'm getting a lot more hashes per second."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1375#msg1375"},{"f":"Xunie","d":1275764724,"b":[["t","Please note that revision 77 is buildable (by default) and 78 isn't I believe.\n\nAnd can you next time wait for your answer in IRC?\nI mean, you asked your question twice, we're just not in the room 24/7! Wink"]],"u":"https://bitcointalk.org/index.php?topic=163.msg1378#msg1378"},{"f":"lachesis","d":1275766854,"b":[["t","I'm not in the room 24/7 either. I decided to go off IRC and to the forums so I wouldn't need to wait around all day.\n\nI need to learn some more C++. There are a lot of things that would improve bitcoin like encrypted wallet files, built-in performance monitoring, RPC extension, etc. Is there any system for submitting patches for inclusion in the SVN and/or default builds?\n\nI don't mean to come accross as confrontational. I love Bitcoin and just want to help improve it. "]],"u":"https://bitcointalk.org/index.php?topic=163.msg1380#msg1380"},{"f":"laszlo","d":1275850531,"b":[["t","Some notes on how to build the linux client.  I used a 64 bit system but the process is almost identical for i386 linux.\n\nhttp://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdf"]],"u":"https://bitcointalk.org/index.php?topic=163.msg1387#msg1387"},{"f":"lachesis","d":1275865063,"b":[["q","Some notes on how to build the linux client.  I used a 64 bit system but the process is almost identical for i386 linux.","Quote from: laszlo on June 06, 2010, 06:55:31 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1388#msg1388"},{"f":"satoshi","d":1276555214,"b":[["t","Sorry, I didn't test compile on linux the last few revisions.\n\nReverted makefile.unix."]],"u":"https://bitcointalk.org/index.php?topic=163.msg1590#msg1590","s":1,"n":121,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/121/"}]},{"id":"p62","k":"p","s":"bitcointalk","t":"What is the incentive to collect transactions?","u":"https://bitcointalk.org/index.php?topic=165","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/62/","m":[{"f":"theymos","d":1275755169,"b":[["t","Adding transactions to the block you're working on will slow down your generation rate. What prevents the majority of generating nodes from ignoring broadcasted transactions and making the network unreliable?"]],"u":"https://bitcointalk.org/index.php?topic=165.msg1373#msg1373"},{"f":"lachesis","d":1275764359,"b":[["t","I don't know if there are any technological safeguards to prevent this, but there is a social one: if you drop transactions, others might drop yours. "]],"u":"https://bitcointalk.org/index.php?topic=165.msg1376#msg1376"},{"f":"sirius","d":1275765758,"b":[["t","Bitcoin supports transaction fees paid to the node that records a transaction into the block chain. If too many nodes start dropping transactions, you can pay a fee when you want to increase the likeliness of your transaction being recorded in the next block."]],"u":"https://bitcointalk.org/index.php?topic=165.msg1379#msg1379"},{"f":"laszlo","d":1275766937,"b":[["t","So would it be smarter to only process transactions which profit you?  That way if you want to send money you need to include a courier fee or nobody will confirm it.  That seems reasonable to me, where you can add a fee yourself to each transaction, and people can configure a threshold of how much of a fee they expect before accepting a transaction."]],"u":"https://bitcointalk.org/index.php?topic=165.msg1381#msg1381"},{"f":"theymos","d":1275767740,"b":[["t","That's a clever (and very free-market) solution. How does BitCoin currently deal with transactions that aren't published in a block for a long time? Is there any risk of them being lost?"]],"u":"https://bitcointalk.org/index.php?topic=165.msg1382#msg1382"},{"f":"QuantumMechanic","d":1275768129,"b":[["t","Are there any estimates on the average transaction fee once users' incentive to support the network via bitcoin generation is mostly dried up?  How does this scale with the number of users, the size of network, and the total transaction rate?"]],"u":"https://bitcointalk.org/index.php?topic=165.msg1383#msg1383"},{"f":"satoshi","d":1276645289,"b":[["q","Adding transactions to the block you're working on will slow down your generation rate","Quote from: theymos on June 05, 2010, 04:26:09 PM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=165.msg1595#msg1595","s":1,"n":122,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/122/"}]},{"id":"p63","k":"p","s":"bitcointalk","t":"Building BitCoin Client completely Headless","u":"https://bitcointalk.org/index.php?topic=171","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/63/","m":[{"f":"Cdecker","d":1276015915,"b":[["t","Hi all,\n\nI'm currently trying to get the openSuse Build Service to build bitcoin binaries for all the major distros, but wxWidgets is giving me a headache, as the development branch 2.9.0 is in not a single repository, and I'm having huge problems building it myself.\n\nSo I was wondering whether it is possible at all to compile everything without any depencies on wxWidgets?\n\nOnce wxWidgets 2.9.0 starts appearing in the default repos I'll create packages for the GUI version too, but a CLI version is better than nothing for the moment.\n\nRegards,\nChris\n\nP.S.: If you're interested at peeking, please take a look here: https://build.opensuse.org/project/show?project=home%3Acdecker%3Abitcoin"]],"u":"https://bitcointalk.org/index.php?topic=171.msg1412#msg1412"},{"f":"laszlo","d":1276016326,"b":[["t","http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdf\n\nIf you follow these instructions and build 'bitcoind' it's all linked statically to wxWidgets, boost, openssl and libdb.. for me it looks like this:"],["c","$ ldd bitcoind\n        linux-vdso.so.1 =>  (0x00007fff31dff000)\n        libdl.so.2 => /lib/libdl.so.2 (0x00007ff1a0a78000)\n        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff1a0768000)\n        libm.so.6 => /lib/libm.so.6 (0x00007ff1a04e4000)\n        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ff1a02cd000)\n        libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff1a00b1000)\n        libc.so.6 => /lib/libc.so.6 (0x00007ff19fd41000)\n        /lib64/ld-linux-x86-64.so.2 (0x00007ff1a0c7c000)"]],"u":"https://bitcointalk.org/index.php?topic=171.msg1414#msg1414"},{"f":"jago25_98","d":1277583075,"b":[["t","I need headless cli to run on my server (don't own my own computer, just a root shell & a borrowed laptop from work).\n\nHow to compile? I recommend including a cli binary. FAQ?\n\nGood work by the way, thanks\n\nupdate: checked out thr trunk by svn, tried a make after installing g++, no joy:"],["c","usr/include/c++/4.3/bits/stl_vector.h:150:   instantiated from âvoid std::_Vector_base<_Tp, _Alloc>::_M_deallocate(_Tp*, size_t) [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]â\n/usr/include/c++/4.3/bits/stl_vector.h:136:   instantiated from âstd::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]â\n/usr/include/c++/4.3/bits/stl_vector.h:235:   instantiated from âstd::vector<_Tp, _Alloc>::vector(size_t, const _Tp&, const _Alloc&) [with _Tp = unsigned char, _Alloc = secure_allocator<unsigned char>]â\nkey.h:105:   instantiated from here\nserialize.h:684: error: âmemsetâ was not declared in this scope\nmake: *** [headers.h.gch] Error 1"],["t","...amongst other errors (don't know what I'm doing with multiplatform..."]],"u":"https://bitcointalk.org/index.php?topic=171.msg1810#msg1810"},{"f":"lachesis","d":1277585118,"b":[["t","Jago, do you have all the proper dependencies installed?"]],"u":"https://bitcointalk.org/index.php?topic=171.msg1811#msg1811"},{"f":"satoshi","d":1277586366,"b":[["t","The linux release candidate in the \"1.3 almost ready\" thread contains prebuilt bitcoind."]],"u":"https://bitcointalk.org/index.php?topic=171.msg1815#msg1815","s":1,"n":155,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/155/"}]},{"id":"p64","k":"p","s":"bitcointalk","t":"Bitcoin mobile.","u":"https://bitcointalk.org/index.php?topic=177","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/64/","m":[{"f":"Anonymous","d":1276135944,"b":[["t","Will it be possible to get bitcoin working on a mobile phone?As the computing power of mobiles increases at what point will it be practicable?It would be nice to carry a portable version of my bitcoin wallet around with me.Is there an app for that? Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=177.msg1441#msg1441"},{"f":"laszlo","d":1276170465,"b":[["t","I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1449#msg1449"},{"f":"sirius","d":1276171580,"b":[["q","I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing.","Quote from: laszlo on June 10, 2010, 11:47:45 AM"],["t","QR codes have been proposed as a solution here <http://bitcointalk.org/index.php?topic=55.msg378#msg378>."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1450#msg1450"},{"f":"Anonymous","d":1276173611,"b":[["q","> Quote from: laszlo on June 10, 2010, 11:47:45 AM\n> I'm working on something like that, for iPhone, but not really for generating, more for spending.. the problem is it's really hard to type in a bitcoin address on that little thing.\n\nQR codes have been proposed as a solution here <http://bitcointalk.org/index.php?topic=55.msg378#msg378>.","Quote from: sirius-m on June 10, 2010, 12:06:20 PM"],["t","nice!"]],"u":"https://bitcointalk.org/index.php?topic=177.msg1451#msg1451"},{"f":"sirius","d":1276177876,"b":[["t","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. But maybe a mobile wallet would be better in a sense."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1452#msg1452"},{"f":"lachesis","d":1276179677,"b":[["t","Another option is an mobile-optimized, https-secured web interface on your local computer. That's already possible with something like LigHTTPd and PHP or Python and JSON-RPC. Not quite as good as running Bitcoin on your phone, but better than vekja.net for trustworthiness."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1453#msg1453"},{"f":"Anonymous","d":1276301966,"b":[["t","Could you build an iphone app that uses bitcoin?"]],"u":"https://bitcointalk.org/index.php?topic=177.msg1507#msg1507"},{"f":"lachesis","d":1276301988,"b":[["t","Sure, but Apple would likely not accept it."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1508#msg1508"},{"f":"laszlo","d":1276304502,"b":[["t","What do you imagine the iPhone app doing?  Just looking for some ideas on how it should look and what it should do.."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1509#msg1509"},{"f":"Anonymous","d":1276305735,"b":[["q","What do you imagine the iPhone app doing?  Just looking for some ideas on how it should look and what it should do..","Quote from: laszlo on June 12, 2010, 01:01:42 AM"],["t","It could be useful for many things because your phone is usually carried everywhere unlike a desktop/laptop.\nI imagine it would be able to carry your wallet db\nPhone banking of some description.\nA list of bitcoin sites you could browse.\nA push notification for bitcoins received/sent.\nExchange on the go.\n\nIf you had an untraceable el cheapo burner phone you might need to purchase\nprepaid phone cards using bitcoin- for the paranoid lol\n\nI guess the list would grow as the marketplace expanded and more merchants came on board."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1510#msg1510"},{"f":"jago25_98","d":1277582219,"b":[["t","I think this idea deserves more recognition.\n\nA phone is much more accessible and widely available than a computer. There are many, many people for whom they only got a phone.\n\nEven some kind of SMS / gateway / key exchange would be something... being able to send a payment by sms to a gateway server with an unsupported phone to a supported phone, for example, or to a trusted third party who can handle the transaction for us.\nBy rolling passcode perhaps.\n\nThat would fantastic, and possibly not too much of a major overhaul needed?\n\nInspired?"]],"u":"https://bitcointalk.org/index.php?topic=177.msg1809#msg1809"},{"f":"satoshi","d":1277585906,"b":[["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.","Quote from: sirius-m on June 10, 2010, 01:51:16 PM"],["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=177.msg1814#msg1814","s":1,"n":154,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/154/"}]},{"id":"p65","k":"p","s":"bitcointalk","t":"Technical clarifications","u":"https://bitcointalk.org/index.php?topic=179","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/65/","m":[{"f":"nixoid","d":1276202293,"b":[["t","Hi people. I'm interested in decentralized currency and going to either participate in development of this one or develop my own version. Before making a decision i want to clarify  few technical aspects, which is not clear from documentation. Partially this is just because english is not my native language, but anyway Smiley.\n\n0) Is it necessary to run a node if i want to have a wallet? Is it necessarily attached to some exact node or i can keep my wallet on flash drive for example and use it with any node? Where and in which form my account balance is stored?\n1) Do i need to download whole network transactions log to be able to validate received coins?\n2) How user protected from potential situation when some node is hacked(or modified) and using his id (public key) to send money from his account? It looks possible when everything is sychronyzed between everybody.\n3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)\n4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.\n5) 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).\n6) Do i correctly understand that after some point in time nobody will have ability to generate new coins? we'll just use fixed amount of existing ones.\n\nThanks for you answers."]],"u":"https://bitcointalk.org/index.php?topic=179.msg1461#msg1461"},{"f":"lachesis","d":1276219428,"b":[["t","Hello Nixoid. I'll answer what I can. Everyone else, feel free to jump in and help, or to correct me if I have something wrong!\n\n0) Yes and no. When people speak of a node here, they usually mean a generating node. You can have a wallet without generating coins, but you must have the software installed and running to make and receive transactions. You can, however, move your wallet between computers / accounts as long as you only keep one version of it. Otherwise, Bitcoin might try to spend the same coins twice. Your use case (on a flash drive) would be fine.\n1) You do need the whole transaction log to validate transactions. At the moment it comes to something like 25MB.\n2) I'm not sure about this one.\n3) This one either, sorry.\n4) At the moment, there is no transaction fee (I think). There is just support for one in the source code. At some point in the future, the transaction fee will be used to replace \"mining\" bitcoins as an incentive to run a node. Also, a transaction fee might be used to insure that other nodes accept your blocks.\n5) I'm not sure what sirius's plans are, but I would like to decentralize this very much. I think IRC is one of Bitcoin's Achilles heels at the moment.\n6) The rate of generation asymptotically approaches zero. About every 4 years, the number of coins created by each new block is halved. In roughly 10-11 years, each new block will generate 6.25 coins for the miner (instead of 50 today). At some point, transaction fees will be implemented to replace generation as the incentive to supply your bandwidth acting as a node. The idea is that the fee will be < 0.5%."]],"u":"https://bitcointalk.org/index.php?topic=179.msg1471#msg1471"},{"f":"Gavin Andresen","d":1276220051,"b":[["t","I'll try to answer what I can:"],["q","0) Is it necessary to run a node if i want to have a wallet? Is it necessarily attached to some exact node or i can keep my wallet on flash drive for example and use it with any node? Where and in which form my account balance is stored?","Quote from: nixoid on June 10, 2010, 08:38:13 PM"],["t","You either have to run a node or trust somebody else (like MyBitcoin.com) to keep a wallet for you.\n\nYour account balance is stored in a Berkeley DB file called 'wallet.dat' (what directory depends on your operating system; on my Mac it is ~/Library/Application Support/Bitcoin/wallet.dat, on linux it is ~/.bitcoin/wallet.dat, not sure about PCs).\n\nThe only application that can read wallet.dat is the bitcoin code, and the database structure isn't documented anywhere besides the bitcoin C++ source code."],["q","1) Do i need to download whole network transactions log to be able to validate received coins?","Quote"],["t","Theoretically, no, but the code to do lightweight validation hasn't been written."],["q","2) How user protected from potential situation when some node is hacked(or modified) and using his id (public key) to send money from his account? It looks possible when everything is sychronyzed between everybody.","Quote"],["t","Satoshi is planning on encrypting the wallet database, so you'd need to enter a password to read it.  (and they need to get your private keys to generate transactions-- those are what are stored in the wallet.dat)"],["q","3) Which data exactly passed between 2 nodes during transaction? (or just show me place in source code where to look)\n4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.","Quote"],["t","Dunno."],["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).","Quote"],["t","There's another thread about this in these forums; maybe we should start a \"Satoshi's TODO list\" thread and get folks to volunteer to help out."],["q","6) Do i correctly understand that after some point in time nobody will have ability to generate new coins? we'll just use fixed amount of existing ones.","Quote"],["t","Fewer and fewer coins will be created over the next N years (where N is-- what, 20?).  That's a feature, not a bug...\n\nRE: developing your own version: are you thinking of creating a second bitcoin implementation that is compatible with the existing C++ one  (good idea, in my opinion)?  Or creating a similar-but-not-the-same system (bad idea, in my opinion)?"]],"u":"https://bitcointalk.org/index.php?topic=179.msg1472#msg1472"},{"f":"QuantumMechanic","d":1276308675,"b":[["q","4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.","Quote"],["t","I second that one.  My fear is that the transaction fee won't scale nicely.  Hopefully this is unfounded."]],"u":"https://bitcointalk.org/index.php?topic=179.msg1511#msg1511"},{"f":"sirius","d":1276424059,"b":[["q","4) Can somebody please write more details about transaction fee: why is it needed, how and in which cases it's used and so on.","Quote from: nixoid on June 10, 2010, 08:38:13 PM"],["t","Transaction fee is needed to give an incentive to generate blocks after many years from now, when the block value has grown low. Also, if many nodes stop recording transactions into the blocks they generate (because of the small generation speed benefit gained), you can apply transaction fee as an incentive.\n\nThere will probably always be nodes that include your transactions into their blocks for free, but you might have to wait for a few blocks if many nodes don't."]],"u":"https://bitcointalk.org/index.php?topic=179.msg1540#msg1540"},{"f":"satoshi","d":1276554115,"b":[["t","3) Nothing, if sending by bitcoin address\n5) It is decentralised.  After you have connected to the network the first time, you no longer need IRC. "]],"u":"https://bitcointalk.org/index.php?topic=179.msg1588#msg1588","s":1,"n":120,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/120/"}]},{"id":"p66","k":"p","s":"bitcointalk","t":"Get 5 free bitcoins from freebitcoins.appspot.com","u":"https://bitcointalk.org/index.php?topic=183","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/66/","m":[{"f":"Gavin Andresen","d":1276277925,"b":[["t","For my first Bitcoin coding project, I decided to do something that sounds really dumb:  I created a web site that gives away Bitcoins.   It is at: https://freebitcoins.appspot.com/\n\nFive ฿ per customer, first come first served, I've stocked it with ฿1,100 to start.  I'll add more once I'm sure it is working properly.\n\nWhy?  Because I want the Bitcoin project to succeed, and I think it is more likely to be a success if people can get a handful of coins to try it out.  It can be frustrating to wait until your node generates some coins (and that will get more frustrating in the future), and buying Bitcoins is still a little bit clunky.\n\nPlease try it out and get some free coins, even if you already have more Bitcoins than you know what to do with.  You can get some and then donate them right back; the address is: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1488#msg1488"},{"f":"laszlo","d":1276279025,"b":[["t","Awesome!"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1489#msg1489"},{"f":"lachesis","d":1276279897,"b":[["t","I really like that. Do you think it would be good to post when the number of bitcoins left is below 200-300? That way people like me could donate to it to help keep this going."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1490#msg1490"},{"f":"lachesis","d":1276280979,"b":[["q","Couldn't someone just keep making new bitcoin addresses and drain your system?\n\nYou should at least toss recaptcha on there.","Quote from: davidonpda on June 11, 2010, 06:24:32 PM"],["t","It only gives 5 coins / IP / day. I dunno if it also checks addresses.\n\nBut it's true, a good captcha wouldn't be a bad idea. "]],"u":"https://bitcointalk.org/index.php?topic=183.msg1495#msg1495"},{"f":"lachesis","d":1276284052,"b":[["t","Yeah, using only the IP is somewhat unsecure, but it's better than nothing.\n\nI wonder if it's possible to generate coins on app engine..."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1498#msg1498"},{"f":"Gavin Andresen","d":1276284435,"b":[["t","Showing the number of Bitcoins available is on my TODO list.  I just checked and the balance is up to 1,135 (thanks to whoever donated!).\n\nAnd right now it is 5 bitcoins per IP address (not bitcoin address).  Not per-day-- just 5.  I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.\n\nRE: captchas:  yeah, I was gonna start out with a captcha, but I wanted it to be as simple and non-threatening as possible.  I don't think anybody who has access to hundreds or thousands of working public IP addresses would go to the effort of writing a bitcoin-harvesting robot, though I suppose somebody with a botnet might take a crack at it.  To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address)."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1500#msg1500"},{"f":"lachesis","d":1276284763,"b":[["q","Showing the number of Bitcoins available is on my TODO list.  I just checked and the balance is up to 1,135 (thanks to whoever donated!).","Quote from: gavinandresen on June 11, 2010, 07:27:15 PM"],["t","I got 5 then felt bad so sent you 50 back Cheesy"],["q","And right now it is 5 bitcoins per IP address (not bitcoin address).  Not per-day-- just 5.  I want to start out conservatively, I will loosen it to 5 per (day?/week?/month?) if people start having lots of trouble because they get a dynamic IP address from their ISP that already got some.","Quote"],["t","My mistake. I don't see that being a big problem. Perhaps have it reset every week? I doubt you'll be hard-pressed for coins, at least for now."],["q","To make that tougher I could make it 5 bitcoins per IP AND 5 bitcoins per bitcoin address (so they couldn't have all the bots in the botnet using the same BC address).","Quote"],["t","That actually wouldn't help much. It's completely trivial to generate a new address per transaction (with JSON-RPC). If I were coding a botnet, that's how I'd do it. Adding a CAPTCHA might be wise if you notice problems, but for now I doubt you have much to lose by skipping it.\n\nJust out of curiosity, how did you build that on the App Engine? Could I possibly see your source? I might set something similar up on my local server. As I understood it, you can't make any sort of outbound request from app engine, though. So how do you send the coins?"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1501#msg1501"},{"f":"HostFat","d":1276287083,"b":[["t","Will you share the source code of your service? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1505#msg1505"},{"f":"Gavin Andresen","d":1276313554,"b":[["q","Will you share the source code of your service? Smiley","Quote from: Joozero on June 11, 2010, 08:11:23 PM"],["t","I'd be happy to share the interesting bits, but the architecture is... um, unique.  I'll start a thread on the Development forum describing how I built it."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1512#msg1512"},{"f":"wobber","d":1276419632,"b":[["t","gavinandersen\n\nI've been able to drawn 50 BTC in minutes using Tor. Please add some address filter too, so the same address can't be used twice. I'll also provide a Tor blacklist if you'd like.\nPS: I've paid back those BTCs.\n\nIt's out job to disarm thieves so this currency won't be subjected to the same atrocities as in real world.\nThis currency shall not be used for one to be rich and in control and others poor and under control."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1533#msg1533"},{"f":"laszlo","d":1276420067,"b":[["t","He's giving it away, it's an honor system, so don't take more than you need Smiley"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1535#msg1535"},{"f":"wobber","d":1276420793,"b":[["t","Of course. I didn't. But that doesn't mean others won't too."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1539#msg1539"},{"f":"Gavin Andresen","d":1276441550,"b":[["q","I've been able to drawn 50 BTC in minutes using Tor. Please add some address filter too, so the same address can't be used twice. I'll also provide a Tor blacklist if you'd like.\nPS: I've paid back those BTCs.","Quote from: wobber on June 13, 2010, 09:00:32 AM"],["t","How many public Tor exit nodes are there these days?  You've essentially blacklisted 10 of them already  Smiley\n\nI am going to add a one-donation-per-bitcoin address rule to make it a teeny-tiny bit harder to cheat.  I don't want to blacklist anybody coming from Tor, though-- I think a lot of people using Tor will also be interested in Bitcoin.\n\nI'll implement a CAPTCHA when (if?) the current service starts running low on coins (there are 1,570 bitcoins in the faucet right now!)."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1541#msg1541"},{"f":"wobber","d":1276444396,"b":[["t","Gavinandersen\nAbout 1500-1700 exit nodes on Tor. Yea, people using Bitcoin might use Tor, but not for your service. My suggestion is to ban open proxies."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1544#msg1544"},{"f":"wobber","d":1276446354,"b":[["t","Gavinandersen, you gave me 13.37 (leet) BTC?"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1547#msg1547"},{"f":"lachesis","d":1276465507,"b":[["t","Gavin, you should set DEBUG = False in your Django settings next time. I hit some kind of exception page and it gave me your secret and the URI of your JSON gateway.\n\nI'll send your bitcoins back to you if you'd like. Cheesy I'm emailing you."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1554#msg1554"},{"f":"Gavin Andresen","d":1276478600,"b":[["t","Thanks, lachesis-- ฿50 to you for finding that bug!\n\nI've changed the key and turned off debugging; I'll tighten up its security a little more tomorrow when I'm more awake.\n\nAnd wobber: no, I didn't send you leet ฿"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1556#msg1556"},{"f":"lachesis","d":1276479938,"b":[["t","Thanks Gavin. Glad to help."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1558#msg1558"},{"f":"Gavin Andresen","d":1276537724,"b":[["t","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.\n\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).\n\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!"]],"u":"https://bitcointalk.org/index.php?topic=183.msg1577#msg1577"},{"f":"satoshi","d":1276902514,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=183.msg1620#msg1620","s":1,"n":129,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/129/","qt":["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.\n\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."],"qc":["general"]}]},{"id":"p67","k":"p","s":"bitcointalk","t":"new binary release?","u":"https://bitcointalk.org/index.php?topic=184","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/67/","m":[{"f":"Anonymous","d":1276280381,"b":[["t","dsag"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1492#msg1492","sj":"sfg"},{"f":"lachesis","d":1276280666,"b":[["t","That's true. It is getting to be time for a new release. Maybe Laszlo's performance patch will make it into the svn too?"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1493#msg1493"},{"f":"laszlo","d":1276326608,"b":[["t","Please note that I'm not the Bitcoin author - if you don't trust me then don't use these.  I have written instructions that should get you started if you want to build your own (look around at my other posts).\n\nSome unofficial builds that I created:\n\nMac OS X, Linux (64 bit) and Win32 builds available\n\nhttp://heliacal.net/~solar/bitcoin/builds/\n\nThis includes a tiny patch I added to show how many hashes per second are being processed.  A picture of the hash counter is attached.\n\nIf you want the patch so you can build it yourself it is available here:\nhttp://heliacal.net/~solar/bitcoin/bitcoin-svn-81-perfcounter-2010-06-12.patch"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1515#msg1515"},{"f":"HostFat","d":1276364255,"b":[["t","Thank you very much! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1522#msg1522"},{"f":"HostFat","d":1276731934,"b":[["t","I'm trying to generate coin with your windows build, and it seems that it doesn't work at all.\nIt was working with the official exe.\n\nIs there a bug somewhere on official code?"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1602#msg1602"},{"f":"laszlo","d":1276732354,"b":[["t","Joozero, what is the problem with it?  I use that binary myself and it works for me."]],"u":"https://bitcointalk.org/index.php?topic=184.msg1603#msg1603"},{"f":"HostFat","d":1276736387,"b":[["t","I doesn't generate coins anymore.\nAnyway it could be a problem with windows 7 x64, even if the latest one was working.\n\nI know that there is a lot of math and we have to be luck, it is just strange Smiley\n\nI'll wait some more ..."]],"u":"https://bitcointalk.org/index.php?topic=184.msg1604#msg1604"},{"f":"laszlo","d":1276737736,"b":[["t","Joozero I'm sorry if it doesn't work for you..  I noticed that the performance with the windows client seems slower than the other two I built.. I'm not sure if this is because of a mistake I made or something I overlooked in the code but I will take another look and let you know if I find anything.  Maybe there is something else wrong with it besides just the performance.."]],"u":"https://bitcointalk.org/index.php?topic=184.msg1605#msg1605"},{"f":"ender_x","d":1276786067,"b":[["t","Thanks laszlo..\nAlso any chance of a 32-bit build?"]],"u":"https://bitcointalk.org/index.php?topic=184.msg1607#msg1607"},{"f":"laszlo","d":1276790596,"b":[["t","32 bit linux?  Yea I can do that."]],"u":"https://bitcointalk.org/index.php?topic=184.msg1608#msg1608"},{"f":"satoshi","d":1276794476,"b":[["t","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!)."]],"u":"https://bitcointalk.org/index.php?topic=184.msg1609#msg1609","s":1,"n":125,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/125/"}]},{"id":"p68","k":"p","s":"bitcointalk","t":"Dealing with SHA-256 Collisions","u":"https://bitcointalk.org/index.php?topic=191","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/68/","m":[{"f":"lachesis","d":1276477271,"b":[["t","A mathematician friend of mine pointed out that there are very few if any hash protocols that have survived for 10 years or more. What would Bitcoin's solution be if SHA256 were to be cracked tomorrow?"]],"u":"https://bitcointalk.org/index.php?topic=191.msg1555#msg1555"},{"f":"theymos","d":1276482897,"b":[["t","I don't think that broken cryptography could ever be the end of BitCoin if it becomes popular. Since the block chain can be forked without losing too much data, modifications to all aspects of BitCoin are possible. If SHA-256 was broken, a new version of BitCoin would be released that would switch to a stronger hash function for addresses. Changing the hash function used for blocks might not be necessary if the weakness still required some non-trivial amount of computation. The new version would ignore SHA-256 blocks after a certain point in time, but most old transactions would survive.\n\nIn case the weakening of SHA-256 is gradual instead of sudden (much more likely, IMO), BitCoin could stretch the process of switching to a different hash algorithm over a long time. First accept SHA-512 (or whatever) in addition to SHA-256, then use SHA-512 by default, and finally stop accepting SHA-256 for new blocks."]],"u":"https://bitcointalk.org/index.php?topic=191.msg1559#msg1559"},{"f":"Xunie","d":1276489841,"b":[["q","In case the weakening of SHA-256 is gradual instead of sudden (much more likely, IMO), BitCoin could stretch the process of switching to a different hash algorithm over a long time. First accept SHA-512 (or whatever) in addition to SHA-256, then use SHA-512 by default, and finally stop accepting SHA-256 for new blocks.","Quote from: theymos on June 14, 2010, 02:34:57 AM"],["t","Wouldn't the users lose their coins?"]],"u":"https://bitcointalk.org/index.php?topic=191.msg1566#msg1566"},{"f":"lachesis","d":1276489874,"b":[["t","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)?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=191.msg1567#msg1567"},{"f":"theymos","d":1276495798,"b":[["q","Wouldn't all the old transactions then be compromised (because they could be trivially recomputed)?","Quote from: lachesis"],["t","After thinking about this some more, I've realized that breaking the hash function used in blocks would be more disastrous than I had originally thought. But it should still be possible to change the hash function \"on-the-fly\" by including secure hashes of each real block in the old chain with the new BitCoin release. Some mechanism of doing this (hopefully more elegant) would also have to be used for a gradual hash change."],["q","Wouldn't the users lose their coins?","Quote from: Xunie"],["t","Everyone's balance is publicly available, so it should always be possible to preserve this data, no matter what changes are made to BitCoin."]],"u":"https://bitcointalk.org/index.php?topic=191.msg1568#msg1568"},{"f":"satoshi","d":1276547990,"b":[["t","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.\n\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.\n\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. "]],"u":"https://bitcointalk.org/index.php?topic=191.msg1585#msg1585","s":1,"n":119,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/119/","qt":["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.","If 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."],"qc":["encryption"]}]},{"id":"p69","k":"p","s":"bitcointalk","t":"Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG","u":"https://bitcointalk.org/index.php?topic=195","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/69/","m":[{"f":"Gavin Andresen","d":1276774711,"b":[["t","So I'm writing a little tool that dissects the Bitcoin wallet.dat, mainly because I want to understand better exactly how Bitcoin works.\n\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']\n\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.\n\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?).\n\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?\n\nAnd is flexibility in the types of coins created the reason it is coded this way?"]],"u":"https://bitcointalk.org/index.php?topic=195.msg1606#msg1606"},{"f":"satoshi","d":1276800368,"b":[["t","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.\n\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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=195.msg1611#msg1611","s":1,"n":126,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/","qt":["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.","The 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."],"qc":["bitcoin-design","transactions"]},{"f":"laszlo","d":1276800631,"b":[["t","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 Smiley"]],"u":"https://bitcointalk.org/index.php?topic=195.msg1612#msg1612"},{"f":"Gavin Andresen","d":1276804694,"b":[["q","I 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.","Quote from: satoshi on June 17, 2010, 06:46:08 PM"],["t","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.\n\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.\n\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..."]],"u":"https://bitcointalk.org/index.php?topic=195.msg1613#msg1613"},{"f":"satoshi","d":1276877834,"b":[["t","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.\n\nI know, most developers don't like their software forked, but I have real technical reasons in this case."],["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.\n\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...","Quote from: gavinandresen on June 17, 2010, 07:58:14 PM"],["t","That's one of the reasons for transaction fees.  There are other things we can do if necessary."],["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 Smiley","Quote from: laszlo on June 17, 2010, 06:50:31 PM"],["t","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.\n\nFortunately, so far all the issues raised have been things I previously considered and planned for."]],"u":"https://bitcointalk.org/index.php?topic=195.msg1617#msg1617","s":1,"n":127,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/127/","qt":["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.\n\nFortunately, so far all the issues raised have been things I previously considered and planned for."],"qc":["bitcoin-design"]}]},{"id":"p70","k":"p","s":"bitcointalk","t":"How fast do the fastest computers generate bitcoins?","u":"https://bitcointalk.org/index.php?topic=197","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/70/","m":[{"f":"paperfree","d":1276960641,"b":[["t","I only have a 1Ghz netbook running bitcoin at the moment, so I'm curious what kind of bitcoin generation rates the faster computers get.  100/week, 1000/week, 10000/week?  How big of an advantage is there to having a faster computer?"]],"u":"https://bitcointalk.org/index.php?topic=197.msg1624#msg1624"},{"f":"molybdenum","d":1277031753,"b":[["t","I get, on average, 100 a day with my P4@3200, I'd expect there to be only a small MIPS/MHz drop between P4 and celeron, so I'd guess vaugely at 50 somewhere between every day, and every day and a half. That's just a wild guess though, and difficulty only seems to be going up..."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1626#msg1626"},{"f":"laszlo","d":1277050280,"b":[["t","It will always benefit you to have the fastest computer, or have more computers than anyone else.  The hits per day you get will go down statistically over time as the difficulty rises, but you will still get a larger share than everyone else if you control the biggest pool of resources.\n\nThis is all based on the theory that statistics mean something though..  The guy with the 1Ghz computer could 'get lucky' and generate a thousand a day while the guy with the compute cluster gets none.  I think this 'get lucky' theory is what gambling is based on."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1628#msg1628"},{"f":"lachesis","d":1277055568,"b":[["t","You should try one of Laszlo's builds of Bitcoin. They show the number of hashes / second that you're computing. Post that number, and you/we can calculate how often you will find a block (on average, statistical caveats apply as Laszlo suggested)."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1630#msg1630"},{"f":"spndr7","d":1277094523,"b":[["t","my CPU amd turion 2 cores rated at 1.6 Ghz generates 50 BC in 2 days........."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1632#msg1632"},{"f":"paperfree","d":1277173183,"b":[["t","100/day seems pretty good... Does internet connection speed matter?  Also, does it matter how long your computer has been continuously connected?"]],"u":"https://bitcointalk.org/index.php?topic=197.msg1651#msg1651"},{"f":"Vasiliev","d":1277174580,"b":[["q","100/day seems pretty good... Does internet connection speed matter?  Also, does it matter how long your computer has been continuously connected?","Quote from: Zurbonium on June 22, 2010, 02:19:43 AM"],["t","Nope\nand you can only generate when you have all blocks, so you won't generate for the first minutes of starting Bitcoin. Doesn't matter past that."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1652#msg1652"},{"f":"satoshi","d":1277181326,"b":[["t","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.\n\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.\n\nThe latest SVN version has a khash/s display.  Around 400 khash/s per processor is typical."]],"u":"https://bitcointalk.org/index.php?topic=197.msg1656#msg1656","s":1,"n":135,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/135/"}]},{"id":"p71","k":"p","s":"bitcointalk","t":"Dying bitcoins","u":"https://bitcointalk.org/index.php?topic=198","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/71/","m":[{"f":"virtualcoin","d":1277126555,"b":[["t","Hello,\n\nif somebody's loosing his wallet (e.g. due to disk crash) he's not able to get back his coins, is he?\nSo every time a person looses coins, they're lost forever? So the bitcoin network will slowly shrink over time? (Because there will always be people who loose wallets!)\n\nTIA\nvirtualcoin\n\nedit: Forgot to mention the coins of users that are try out bitcoin and then never use it again."]],"u":"https://bitcointalk.org/index.php?topic=198.msg1638#msg1638"},{"f":"laszlo","d":1277128469,"b":[["t","They are lost for good.  Think of it like someone losing their wallet in the ocean.  It seems like it would be a problem but it's really not that significant.  People lose their gold jewelry all the time but it doesn't make much of a difference to the value of gold.\n\nI 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.."]],"u":"https://bitcointalk.org/index.php?topic=198.msg1640#msg1640"},{"f":"virtualcoin","d":1277130811,"b":[["q","They are lost for good.  Think of it like someone losing their wallet in the ocean.  It seems like it would be a problem but it's really not that significant.  People lose their gold jewelry all the time but it doesn't make much of a difference to the value of gold.","Quote from: laszlo on June 21, 2010, 01:54:29 PM"],["t","But loosing 1 bitcoin in the ocean of a maximum of 21.000.000 coins seems significant to me, so not comparable to gold and jewelry.\nSo only 21000 losses of 1000 coins can happen. That's not much!"]],"u":"https://bitcointalk.org/index.php?topic=198.msg1641#msg1641"},{"f":"Gavin Andresen","d":1277132504,"b":[["q","But loosing 1 bitcoin in the ocean of a maximum of 21.000.000 coins seems significant to me, so not comparable to gold and jewelry.\nSo only 21000 losses of 1000 coins can happen. That's not much!","Quote from: virtualcoin on June 21, 2010, 02:33:31 PM"],["t","But remember that each bitcoins can be divided into 100 million pieces, as needed.\n\nAnd the more valuable they become, the more careful people will be not to lose them."]],"u":"https://bitcointalk.org/index.php?topic=198.msg1642#msg1642"},{"f":"virtualcoin","d":1277135683,"b":[["t","So how am I able to transfer less than BC0.01 without getting the message \"error in amount\" from the bitcoin program?"]],"u":"https://bitcointalk.org/index.php?topic=198.msg1644#msg1644"},{"f":"laszlo","d":1277137980,"b":[["t","The current user interface doesn't support smaller than 0.01 increments but it is possible to support it in a future revision."]],"u":"https://bitcointalk.org/index.php?topic=198.msg1645#msg1645"},{"f":"satoshi","d":1277142506,"b":[["t","Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone."],["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..","Quote from: laszlo on June 21, 2010, 01:54:29 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=198.msg1647#msg1647","s":1,"n":131,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/131/","qt":["Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone."],"qc":["bitcoin-economics"]}]},{"id":"p72","k":"p","s":"bitcointalk","t":"0.3 almost ready -- please test the Mac version!","u":"https://bitcointalk.org/index.php?topic=199","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/72/","m":[{"f":"satoshi","d":1277179313,"b":[["t","I finished everything on my list to do for version 0.3.  The code on SVN is about ready to release.\n\nTesting at this point is much appreciated."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1654#msg1654","s":1,"n":134,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/134/"},{"f":"HostFat","d":1277179605,"b":[["t","I'm just here Cheesy\n\nWindows 7 x64\n4 GB RAM\nIntel i7 860 "]],"u":"https://bitcointalk.org/index.php?topic=199.msg1655#msg1655","sj":"Re: 0.3 almost ready"},{"f":"lachesis","d":1277187602,"b":[["t","Very nice! There have definitely been some major improvements, including the hashmeter, RPC support, and a command-line daemon. It would be nice if the listtransactions RPC method were finished before the next release, though. Also, some code should be added to the JSON-RPC methods to list out dHashesPerSec.\n\nGreat work Satoshi!"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1658#msg1658","sj":"Re: 0.3 almost ready"},{"f":"Xunie","d":1277191736,"b":[["t","Whoohoo! Can't wait!\n\nNote, is there somewhere I can get a devel build?\nMaybe we can setup nightly builds or something..."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1659#msg1659","sj":"Re: 0.3 almost ready"},{"f":"teppy","d":1277216124,"b":[["t","Should we try for some publicity? Slashdot is good if we can get it.\n\nI've had a number of submissions accepted, though always by one editor that no longer works there. Anyone else with a Slashdot connection?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1662#msg1662","sj":"Re: 0.3 almost ready"},{"f":"sirius","d":1277216431,"b":[["q","Should we try for some publicity? Slashdot is good if we can get it.\n\nI've had a number of submissions accepted, though always by one editor that no longer works there. Anyone else with a Slashdot connection?","Quote from: teppy on June 22, 2010, 02:15:24 PM"],["t","We should try to get publicity, and focus the campaign on the time right after the release to get the maximum impact: simultaneously advertising on forums, irc, Youtube, Facebook, Google Ads and other places. Slashdot with its millions of tech-savvy readers would be awesome, perhaps the best imaginable! I just hope the server can stand getting \"slashdotted\" Tongue Maybe it should be upscaled beforehand just in case."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1664#msg1664","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277226127,"b":[["q","It would be nice if the listtransactions RPC method were finished before the next release, though.","Quote from: lachesis on June 22, 2010, 06:20:02 AM"],["t","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.\n\nWe shouldn't delay forever until every possible feature is done.  There's always going to be one more thing to do."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1670#msg1670","s":1,"n":138,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/138/","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277228228,"b":[["t","Here's RC1 for windows for testing:\n(removed, see RC2 below)\n\nPlease only download this if you're going to test and report back whether everything seems fine or not.  Make sure to look through the files in \"c:\\program files\\bitcoin\""]],"u":"https://bitcointalk.org/index.php?topic=199.msg1671#msg1671","s":1,"n":139,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/139/","sj":"Re: 0.3 almost ready"},{"f":"Gavin Andresen","d":1277229536,"b":[["q","I finished everything on my list to do for version 0.3.  The code on SVN is about ready to release.\nTesting at this point is much appreciated.","Quote from: satoshi on June 22, 2010, 04:01:53 AM"],["t","I just finished creating a clean Amazon EC2 debian 5.0 machine image with everything I needed to compile bitcoind, and it compiled (using a variation of Laszlo's makefile.unix) and is running fine (just finished downloading the block chain).  I'll let you know if it misbehaves.\n\nI had trouble compiling the gtk version, but I think that's because I did something wrong compiling wxWidgets.  I don't need no stinkin' graphics (and am not a wxWidgets expert), so I'm not going to bother trying to fix that."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1672#msg1672","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277233689,"b":[["q","EXCEPTION: 22DbRunRecoveryException\nDBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery\nC:\\Program Files\\Bitcoin\\bitcoin.exe in OnInit()","Quote"],["t","I have the same problem :|"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1674#msg1674","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277233901,"b":[["q","EXCEPTION: 22DbRunRecoveryException\nDBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery\nC:\\Program Files\\Bitcoin\\bitcoin.exe in OnInit()","Quote from: davidonpda on June 22, 2010, 06:23:26 PM"],["t","What operating system?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1675#msg1675","s":1,"n":140,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/140/","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277234079,"b":[["t","Windows 7 x64 ENG\n4 GB RAM\nIntel i7 860\n\nI was using the v0.2.10 build by laszlo before yours."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1676#msg1676","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277234713,"b":[["t","davidonpda, were you also running laszlo's build previously?\n\nCheck if the \"%appdata%\" directory exists, and \"%appdata%\\bitcoin\"\n\nTry:\n rename \"%appdata%\\bitcoin\" bitcoin2\n\ndoes it work then?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1677#msg1677","s":1,"n":141,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/141/","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277235204,"b":[["q","Check if the \"%appdata%\" directory exists, and \"%appdata%\\bitcoin\"","Quote from: satoshi on June 22, 2010, 07:25:13 PM"],["t","Both are existing Smiley"],["q","Try:\n rename \"%appdata%\\bitcoin\" bitcoin2\n\ndoes it work then?","Quote from: satoshi on June 22, 2010, 07:25:13 PM"],["t","Yes it works.\n\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 Smiley\n\nEDIT:\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 ..."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1678#msg1678","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277235983,"b":[["t","You figured it out faster than I could post a reply.  Smiley\n\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.\n\nWhen you copied the directory except log.0000000002, that's the best solution.  You should be good now.\n\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.\n\nPlease keep running v0.3 if at all possible, don't go back to v0.2.10.\n\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)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1679#msg1679","s":1,"n":142,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/142/","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277236190,"b":[["t","yes, I'm just using 0.30 by now.\nThank you! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1680#msg1680","sj":"Re: 0.3 almost ready"},{"f":"D҉ataWraith","d":1277240518,"b":[["t","Runs fine under WINE. *rhymes*\n\nIt automatically switched the language to German, too. Now that I can see the translation in the client itself, I noticed a few things to improve, and will post a new .po file within the next two or so days."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1683#msg1683","sj":"Re: 0.3 almost ready"},{"f":"lachesis","d":1277244047,"b":[["t","Yeah, 0.3.0 seems to have a performance increase over svn r84 with Laszlo's performance patch."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1685#msg1685","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277245419,"b":[["t","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.\n\n30khash increase to what total rate?  (to figure the % increase)"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1686#msg1686","s":1,"n":143,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/143/","sj":"Re: 0.3 almost ready"},{"f":"Vasiliev","d":1277248050,"b":[["t","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.\n\nedit: Keeping the \"Run Bitcoin\" option checked in the installer seems to run it with admin privileges on the first launch. (in Win7)"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1687#msg1687","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277401205,"b":[["t","Here's RC1 for linux for testing:\n(link removed, see below)\n\nIt contains both 32-bit and 64-bit binaries.\n\nRecent changes:\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1748#msg1748","s":1,"n":144,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/144/","sj":"Re: 0.3 almost ready"},{"f":"virtualcoin","d":1277412564,"b":[["t","Nice. :-)\n\n64-bit version works fine on Ubuntu 10.04, of course it's (much) faster than through WINE emulation (and because it's 64-bit!?)\n\n4 cores: 2850 khash/s\n3 cores: 2130 khash/s\n2 cores: 1420 khash/s\n1 core: 700 khash/s\n\nWINE (32-bit):\n\n4 cores - 2300 khash/s\n3 cores - 1740 khash/s\n2 cores - 1150 khash/s\n1 core - 580 khash/s\n\nThank you - looks pretty nice, too.\n\nhttp://i50.tinypic.com/2ih1h0p.jpg\n\nedit: What's the difference between \"Sent/Received\" and \"All transactions\"?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1750#msg1750","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277417974,"b":[["t","will it change something if you release a x64 bit version for Windows?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1756#msg1756","sj":"Re: 0.3 almost ready"},{"f":"Vasiliev","d":1277421963,"b":[["t","Ubuntu 9.04 x86:\n\nvlad@vlad:~/bitcoin/bin/32$ ./bitcoind\n./bitcoind: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)\n\nAnybody know what Bitcoin needs?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1758#msg1758","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277432261,"b":[["t","I don't know.  Maybe someone with more Linux experience knows how to install the library it needs.\n\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?\n\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.\n\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.\n\nI'm also curious if it's a little faster on linux than windows.\n\nDo you think I should make the directories:\n/bin32/\n/bin64/\ninstead of\n/bin/32/\n/bin/64/"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1760#msg1760","s":1,"n":145,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/145/","sj":"Re: 0.3 almost ready"},{"f":"HostFat","d":1277441248,"b":[["t","Windows 7 x64\n4 GB RAM\nIntel i7 860\n\n4 cores ( 8 virtuals ): 2200 khash/s\n\nIt's lower than Ubuntu :|"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1763#msg1763","sj":"Re: 0.3 almost ready"},{"f":"theymos","d":1277450334,"b":[["t","Linux on an overclocked Pentium D:\n- 1 core: 565 khash/s, 1.01 kW h/day\n- 2 cores: 1100 khash/s, 1.78 kW h/day\n\nThe new version seems to give me an improvement of 20-30 khash/s (with two cores) over SVN 80 with laszlo's patch.\n\nDoes anyone know what I have to change in the makefile so that I don't have to add LD_LIBRARY_PATH pointing to the dependency libraries when executing BitCoin? I already have -I and -L pointing to the single, correct location. (This isn't caused by the new version; I've always had this problem.)"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1765#msg1765","sj":"Re: 0.3 almost ready"},{"f":"virtualcoin","d":1277461794,"b":[["q","The 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.","Quote from: satoshi on June 25, 2010, 02:17:41 AM"],["t","But look here:\n\n32-bit Linux version on Ubuntu 10.04\n\n4 cores: 2500 khash/s\n3 cores: 1900 khash/s\n2 cores: 1260 khash/s\n1 core: 630 khash/s\n\n64-bit Linux version on Ubuntu 10.04 (new measure)\n\n4 cores: 2880 khash/s\n3 cores: 2150 khash/s\n2 cores: 1450 khash/s\n1 core: 720 khash/s\n\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\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.\n\n/edit\n\n32-bit Win version on Windows 7 64-bit\n\n4 cores: 2310 khash/s\n3 cores: 1740 khash/s\n2 cores: 1160 khash/s\n1 core: 580 khash/s"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1766#msg1766","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277475006,"b":[["t","Thanks virtualcoin, that's a perfect comparison.\n\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).\n\nThe 15% speedup from 32-bit to 64-bit Linux is more of a mystery.  The code is completely 32-bit.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1769#msg1769","s":1,"n":146,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/146/","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277512329,"b":[["t","Lets try using Laszlo's irc.lfnet.org instead of freenode.  Here's RC2, that's the only change in it:\n\n(see below for download links)"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1787#msg1787","s":1,"n":149,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/149/","sj":"Re: 0.3 almost ready"},{"f":"NewLibertyStandard","d":1277515175,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1788#msg1788","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277565010,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1800#msg1800","s":1,"n":151,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/151/","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1277580065,"b":[["t","Changed the version number to 1.3 and removed \"Beta\".\n\n(links removed, see below)\n\nUses irc.lfnet.org."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1806#msg1806","s":1,"n":153,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/153/","sj":"Re: 1.3 almost ready"},{"f":"laszlo","d":1277649928,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1832#msg1832","sj":"Re: 1.3 almost ready"},{"f":"satoshi","d":1277652613,"b":[["t","MinGW still only has good old stable 3.4.5.  There's not much reason for them to update it.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1834#msg1834","s":1,"n":159,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/159/","sj":"Re: 1.3 almost ready"},{"f":"dkaparis","d":1277676145,"b":[["q","MinGW still only has good old stable 3.4.5.  There's not much reason for them to update it.\n\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?","Quote from: satoshi on June 27, 2010, 03:30:13 PM"],["t","Maybe best to look at the 4.4.3 compiled disassembly as well and see if there are any differences.\n\nOn a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it.\n\nDimitri"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1842#msg1842","sj":"Re: 1.3 almost ready"},{"f":"satoshi","d":1278103037,"b":[["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.","Quote from: dkaparis on June 27, 2010, 10:02:25 PM"],["t","It is, but generating is more than twice as slow."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1926#msg1926","s":1,"n":162,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/162/","sj":"Re: 1.3 almost ready"},{"f":"satoshi","d":1278107865,"b":[["t","(reverted to rc2)\n\nLinks removed, 0.3 is now released, so go to http://www.bitcoin.org to download it."]],"u":"https://bitcointalk.org/index.php?topic=199.msg1927#msg1927","s":1,"n":163,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/163/","sj":"Re: 0.3 almost ready"},{"f":"laszlo","d":1278272372,"b":[["t","Mac OS version - requires Intel processor and 10.5 (10.4 not supported)\n\nhttp://heliacal.net/~solar/bitcoin/builds/MacOSX-Intel-0.3/bitcoin-0.3.0.zip"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1945#msg1945","sj":"Re: 0.3 almost ready"},{"f":"satoshi","d":1278280348,"b":[["t","Laszlo's build is going to be our first Mac release so please test it!"]],"u":"https://bitcointalk.org/index.php?topic=199.msg1947#msg1947","s":1,"n":166,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/166/"},{"f":"BitLex","d":1278438778,"b":[["t","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.  Cool"]],"u":"https://bitcointalk.org/index.php?topic=199.msg2002#msg2002"},{"f":"satoshi","d":1278445398,"b":[["t","0.3 released\nhttp://bitcointalk.org/index.php?topic=238.msg2004#msg2004"]],"u":"https://bitcointalk.org/index.php?topic=199.msg2006#msg2006","s":1,"n":169,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/169/"}]},{"id":"p73","k":"p","s":"bitcointalk","t":"Major Meltdown","u":"https://bitcointalk.org/index.php?topic=202","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/73/","m":[{"f":"llama","d":1277278924,"b":[["t","What if a major flaw is discovered in BC's cryptographic soundness?  Is there any way to prevent the complete dissolution of the system and of everybody's wealth?\n\nPerhaps one way to do it would be to create a voluntary registry of non-anonymous addresses, to be shared and verified publicly.  Then, if a major flaw arose (maybe someone solved the factoring problem Wink ), then there would still be a record of everybody's wealth that could be used in a new system (supposing everybody could agree on the latest time that no fraudulent transactions could have taken place).  Of course, people who chose to stay anonymous (and therefore did not include their address in the registry) would see their wealth disappear, but alas that risk would prove the price of anonymity."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1692#msg1692"},{"f":"dwdollar","d":1277302739,"b":[["q","What if a major flaw is discovered in BC's cryptographic soundness?  Is there any way to prevent the complete dissolution of the system and of everybody's wealth?\n\nPerhaps one way to do it would be to create a voluntary registry of non-anonymous addresses, to be shared and verified publicly.  Then, if a major flaw arose (maybe someone solved the factoring problem Wink ), then there would still be a record of everybody's wealth that could be used in a new system (supposing everybody could agree on the latest time that no fraudulent transactions could have taken place).  Of course, people who chose to stay anonymous (and therefore did not include their address in the registry) would see their wealth disappear, but alas that risk would prove the price of anonymity.","Quote from: amall on June 23, 2010, 07:42:04 AM"],["t","That is an interesting idea.  But, how would the wealth be transfered to a new system and what would be the exchange rate?  Perhaps this could be combined with an insurance plan that had a predetermined and guaranteed payout written in the policy?"]],"u":"https://bitcointalk.org/index.php?topic=202.msg1707#msg1707"},{"f":"llama","d":1277307689,"b":[["q","But, how would the wealth be transfered to a new system and what would be the exchange rate?","Quote from: dwdollar on June 23, 2010, 02:18:59 PM"],["t","Wealth would not have to be transferred per say.  Rather, a new, cryptographically sound system would be adopted, and previous owners would be given new currency in proportion to their old balance of BC.  The exchange rate would be determined solely by the market's usage of the new currency. \n\nImagine a verified public registry that voluntarily ties BC addresses to email addresses (by signing your email address with your private key for the BC address).  If BC failed, the new system would take a certain historical block from BC at a fraudless time.  Then, supposing again that 21 million units of new currency were being generated, and that 80% of the old BC currency had been registered, then each time a node generates a block for the new currency they would get to keep 20% of some number of new currency while every registered address would receive some tiny share of the other 80% in proportion to their registered BC at their registered email address.  When all new currency generation is done, the owners of the 80% of registered BC money will have 80% of the new money, while the lost 20% is reissued.\n\nI would bet that if BC had seen widespread adoption, and if many people had registered their addresses, then the new currency would be readily accepted because so many people would be getting it for free and in their \"fair\" amount."],["q","Perhaps this could be combined with an insurance plan that had a predetermined and guaranteed payout written in the policy?","Quote from: dwdollar on June 23, 2010, 02:18:59 PM"],["t","That's another interesting idea.  Basically, some individual could choose to setup their own insurance company for BC where people pay a certain percentage of their protected BC amount.  This company would then keep a registry similar to that above, but only for its clients (It's necessary to verify that clients have the BC amount they claim). Instead of issuing new currency in case of catastrophic failure, they could simply issue USD's.  Again, the biggest challenge would be setting clear terms for when payout would occur and which block would be treated as the truth.  Perhaps they could pay out from the last block issued before a mathematical proof of the system's unsoundness was offered?"]],"u":"https://bitcointalk.org/index.php?topic=202.msg1719#msg1719"},{"f":"Max Stirner","d":1277391967,"b":[["t","It is strange that is has taken such a long time to create a digital fiat currency. And who\nsays that Bitcoin is the one and only digital currency that will exist in the future?\nRight now, if there is a flaw in the bitcoin algorithm the people dealing with it will lose their trust\nin the currency and the bitcoins will lose their value. If there are several digital currencies in the future\nyou will just sell your bitcoins and buy more secure (or more useful)  digital coins instead. I think that there will be a tendency to swap from one digital money system to another, once people see an advantage of a new system. Like an evolutionary process.\nI find it funny that some people still cling to the idea that there has to be some kind of \"agency\" that regulates the economy.  I mean when you don't want your old money anymore you just .. eh .. sell it?\nYou are not forced by anyone to use bitcoins, right? And nobody can stop you from using another digital\ncurrency.  So the best way to keep your wealth is to invest in different assets - as always in life."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1747#msg1747","sj":"The evolution of digital currencies"},{"f":"llama","d":1277427400,"b":[["t","Max,\n\nYour comments make total sense, as long as there is time to switch over to the new currency when a threat looms.  This is pretty reasonable.  For example, people might start to find some small flaws with SHA-256, and so people would have time to buy into the new currency before the whole system unravels.\n\nHowever, supposing somebody found a major flaw while BC was in widespread usage, that person could commit a lot of fraud without people even realizing immediately.  In this case, it might be valuable to have some kind of registry, because people might want to buy into a new currency that does include some distribution in proportion to formerly registered wealth (game theoretically, only the wealthier registered 50% would prefer this currency, but that's the topic of another discussion).\n\nNow, it seems like a pretty good solution would be for everyone to hold a diversity of digital currencies, which are backed by a diversity of cryptographic methods.  However, this solution has many costs of its own, since the marketplace would need to support many currencies.  Among other things, it would be absolutely necessary to have many competing, cheap exchanges."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1759#msg1759"},{"f":"Anonymous","d":1277443844,"b":[["q","Max,\n\nYour comments make total sense, as long as there is time to switch over to the new currency when a threat looms.  This is pretty reasonable.  For example, people might start to find some small flaws with SHA-256, and so people would have time to buy into the new currency before the whole system unravels.\n\nHowever, supposing somebody found a major flaw while BC was in widespread usage, that person could commit a lot of fraud without people even realizing immediately.  In this case, it might be valuable to have some kind of registry, because people might want to buy into a new currency that does include some distribution in proportion to formerly registered wealth (game theoretically, only the wealthier registered 50% would prefer this currency, but that's the topic of another discussion).\n\nNow, it seems like a pretty good solution would be for everyone to hold a diversity of digital currencies, which are backed by a diversity of cryptographic methods.  However, this solution has many costs of its own, since the marketplace would need to support many currencies.  Among other things, it would be absolutely necessary to have many competing, cheap exchanges.","Quote from: amall on June 25, 2010, 12:56:40 AM"],["t","Any monetary system with a central registering authority is headed for failure imo."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1764#msg1764"},{"f":"llama","d":1277471860,"b":[["t","No not a centralized registry.  There's no \"agency\" controlling it.  It's just something that users would agree to, just like every other rule of BC.  Deentralized and public, just like BC does transactions."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1768#msg1768"},{"f":"Max Stirner","d":1277662971,"b":[["t","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.\n\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.\n\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. "]],"u":"https://bitcointalk.org/index.php?topic=202.msg1837#msg1837"},{"f":"satoshi","d":1277665569,"b":[["t","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"],["q","If 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.\n\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.","Quote from: satoshi on June 14, 2010, 08:39:50 PM"]],"u":"https://bitcointalk.org/index.php?topic=202.msg1838#msg1838","s":1,"n":160,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/160/"},{"f":"llama","d":1278022907,"b":[["t","Satoshi,\n\nThat would indeed be a solution if SHA was broken (certainly the more likely meltdown), because we could still recognize valid money owners by their signature (their private key would still be secure).\n\nHowever, 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."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1920#msg1920"},{"f":"Gavin Andresen","d":1278030113,"b":[["t","If you're worried about elliptic curve cryptography being broken, then don't store any significant wealth in Bitcoin.   Just like if you're worried about your (real, physical) wallet being stolen don't hold more cash than you need to get through a couple of days of purchases.\n\nBy the way: I think an economical method for separating gold atoms from seawater will be found before elliptic curve cryptography is broken (and I think both are unlikely in the next 25 years)."]],"u":"https://bitcointalk.org/index.php?topic=202.msg1922#msg1922"},{"f":"satoshi","d":1278768977,"b":[["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.","Quote from: llama on July 01, 2010, 10:21:47 PM"],["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=202.msg2133#msg2133","s":1,"n":177,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/177/"}]},{"id":"p74","k":"p","s":"bitcointalk","t":"Bitcoin Faucet changes","u":"https://bitcointalk.org/index.php?topic=206","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/74/","m":[{"f":"Gavin Andresen","d":1277303026,"b":[["t","So I've been watching the IP addresses of people getting 5 free bitcoins from the Bitcoin Faucet ( https://freebitcoins.appspot.com/ ).\n\nAnd I see some... uh, interesting patterns.  Like these successful requests for coins:"],["c","79.117.152.158 - - [21/Jun/2010:12:17:02 -0700] \"POST / HTTP/1.1\" 200 1234\n79.117.159.197 - - [21/Jun/2010:12:16:24 -0700] \"POST / HTTP/1.1\" 200 1234\n79.117.135.236 - - [21/Jun/2010:12:10:23 -0700] \"POST / HTTP/1.1\" 200 1234\n79.117.163.238 - - [21/Jun/2010:12:08:50 -0700] \"POST / HTTP/1.1\" 200 1234\n79.117.155.23 - - [21/Jun/2010:12:08:07 -0700] \"POST / HTTP/1.1\" 200 1234"],["t","My apologies if there actually are a bunch of new bitcoin users using IP addresses in the 79.117 range...  but I'm guessing somebody there is getting more than their fair share of free bitcoins.\n\nThere are several suspicious requests from the 192.38.95.* address block, too.\n\nSo I've made some changes to the Faucet.  You won't notice them unless you try to cheat; if you do try to cheat, you'll have to solve a CAPTCHA to get coins.\n\nIf that doesn't discourage cheating, I'll modify the code so that if it think you're trying to cheat it requires a CAPTCHA and only gives out a bitcoin nickel (0.05 bitcoins)..."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1711#msg1711"},{"f":"Xunie","d":1277376661,"b":[["t","Lol, bitnickel!\n\nAnyhow, I was expecting this.\nAnd what about those using proxies?\nI don't wanna be an #@!%!#% here, but ehh... I think the \"5 BTC for FREE!\" thing, is kinda... flawed..."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1744#msg1744"},{"f":"Gavin Andresen","d":1277403456,"b":[["q","I don't wanna be an #@!%!#% here, but ehh... I think the \"5 BTC for FREE!\" thing, is kinda... flawed...","Quote from: Xunie on June 24, 2010, 10:51:01 AM"],["t","\"flawed\" ??\n\nI've been telling people it is a half-baked, I've-lost-my-friggin-mind idea!\n\nSo far, I count it as a big success-- I've learned a lot that will help me with my next Bitcoin-related project, I've made a bunch of people a teeny-tiny bit happier, and I've personally invested just under $1.00 worth of bitcoins over the last two weeks.\n\nI did throw in the towel today and turned on reCAPTCHA for everybody getting bitcoins (it looks like somebody DID bother to write a robot to harvest coins through proxies).  It was fun trying to come up with new, creative ways of detecting cheating, but I have more important things to work on."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1749#msg1749"},{"f":"sirius","d":1277415459,"b":[["q","http://www.decaptcher.com/\n\nIt costs someone $2 per 1000 captchas. So, they could suck out 5000 bitcoins for $2. lol. Smiley\n\nBut, that should help stop most people Smiley","Quote from: davidonpda on June 24, 2010, 09:19:22 PM"],["t","I guess that's why the forum still gets those annoying spam user registrations despite the captcha."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1754#msg1754"},{"f":"virtualcoin","d":1277417250,"b":[["t","Gavin, why don't you just block all served Bitcoin addresses?\nWould it be easy to generate them automatically?"]],"u":"https://bitcointalk.org/index.php?topic=206.msg1755#msg1755"},{"f":"Gavin Andresen","d":1277421225,"b":[["q","Gavin, why don't you just block all served Bitcoin addresses?\nWould it be easy to generate them automatically?","Quote from: virtualcoin on June 24, 2010, 10:07:30 PM"],["t","It is easy to generate them automatically (it is easy to write code that asks the Bitcoin program to generate and return a new address)."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1757#msg1757"},{"f":"llama","d":1277439948,"b":[["t","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. \n\nI love it  Grin"]],"u":"https://bitcointalk.org/index.php?topic=206.msg1761#msg1761"},{"f":"satoshi","d":1277588392,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=206.msg1816#msg1816","s":1,"n":156,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/156/"}]},{"id":"p75","k":"p","s":"bitcointalk","t":"Bitcoin clients getting k-lined from the IRC bootstrapping channel","u":"https://bitcointalk.org/index.php?topic=215","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/75/","m":[{"f":"Xunie","d":1277497216,"b":[["t","At 21:11 dutch time (CEST), around 10 minutes ago from when I made this post, the Bitcoin clients are getting k-lined.\n\n(note, times are CEST.)"],["c","--- SNIP ---\n[21:11:36] * u4euc453wZ599zQ has quit (K-Lined)\n[21:11:37] * u4mZRTtQwC6NskZ has quit (K-Lined)\n[21:11:37] * x398030675 has quit (K-Lined)\n[21:11:37] * u4m5AmvGVaM8MNU has quit (K-Lined)\n[21:11:37] * x92119461 has quit (K-Lined)\n[21:11:38] * u4iQ9mpGopGTd6D has quit (K-Lined)\n[21:11:39] * u4iqow5D1WqBmPH has quit (K-Lined)\n[21:11:39] * u4qsjyU6VRAtfRD has quit (K-Lined)\n--- SNIP ---"],["t","Anyhow, this leaves the bitcoin network unable to operate.\nI see some clients getting back slowly.\nBut this worries me.\nI suggest we apply what ever other bootstrapping mechanism we have right now, and release 0.3 ASAP.\n\nSomeone in #freenode suggested this:"],["c","<gwillen> Xunie: as a potential user of bitcoin, I would suggest that if your project is going to connect to IRC in the background, you should document that fact somewhere. I'm suddenly much more wary of using it now that I know that it does this."],["t","This does make Bitcoin seem a bit... malicious to say the least..."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1774#msg1774"},{"f":"The Madhatter","d":1277497799,"b":[["t","Whoops! My bad. I was testing something and it went haywire. Tongue\n\nShould see the k-lines lift shortly. Heh."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1775#msg1775"},{"f":"Xunie","d":1277498035,"b":[["t","It's a relief to hear this.\nAnd what were you exactly testing?\n\nLike, how can it affect the whole network?\nIf this is a bug that can bring down the whole network, it's pretty serious, heh."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1776#msg1776"},{"f":"dwdollar","d":1277498504,"b":[["t","I'm banned."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1777#msg1777"},{"f":"dwdollar","d":1277498888,"b":[["t","I'm connected now."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1778#msg1778"},{"f":"satoshi","d":1277500515,"b":[["t","We need more details about what happened MadHatter.\n\nBoth 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1779#msg1779","s":1,"n":147,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/147/"},{"f":"The Madhatter","d":1277508797,"b":[["t","I was mucking around with the source code on a large research cluster that I have access to. For some reason the nodes were connecting and disconnecting from Freenode quite rapidly witch resulted in most of my nodes getting k-lined. Freenode started going nuts and blocking my nodes as fast as I was creating connections.\n\nNot too sure if other people were k-line'd as well because of this?? However, the timing was \"bang on\".\n\nI had discovered the bug around the same time this k-line problem was reported. I ended up forcing the source to seed IPs from some Bitcoin clients that I run on a different network."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1783#msg1783"},{"f":"Vasiliev","d":1277509725,"b":[["q","This does make Bitcoin seem a bit... malicious to say the least...","Quote from: Xunie on June 25, 2010, 08:20:16 PM"],["t","Bootstrapping to the network is malicious?"]],"u":"https://bitcointalk.org/index.php?topic=215.msg1784#msg1784"},{"f":"laszlo","d":1277525531,"b":[["t","Whether it's right or wrong, when people who know what IRC is hear that IRC is involved in something, they immediately think malice..  This is not without foundation as a lot of antisocial behavior takes places on IRC channels.  The other thought is botnets which use IRC to bootstrap, control or communicate.  A program which connects to IRC is by definition called a 'bot' and to IRC people that means something bad, especially if it's not an IRC bot program specifically.\n\nWhat Satoshi did here is use IRC simply as a matchmaking service but I could see how someone could draw the wrong conclusion when they see a channel with hundreds of randomly named bots idling in it.  Perhaps you could put these people's minds at ease if there was some pop up asking them if it's ok to bootstrap from IRC.. because if they just write it off as a trojan or botnet they may never bother to find out how it really works."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1789#msg1789"},{"f":"laszlo","d":1277525630,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=215.msg1790#msg1790"},{"f":"satoshi","d":1277562486,"b":[["t","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.\n\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"]],"u":"https://bitcointalk.org/index.php?topic=215.msg1797#msg1797","s":1,"n":150,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/150/"}]},{"id":"p76","k":"p","s":"bitcointalk","t":"Beta?","u":"https://bitcointalk.org/index.php?topic=217","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/76/","m":[{"f":"satoshi","d":1277571763,"b":[["t","Is it about time we lose the Beta?  I would make this release version 1.3."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1803#msg1803","s":1,"n":152,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/152/"},{"f":"virtualcoin","d":1277593441,"b":[["t","I'm not sure, but I think it's unusual to jump from version 0.3 to 1.3. ^^ Maybe 1.0?\nBut on the other hand: who cares?"]],"u":"https://bitcointalk.org/index.php?topic=217.msg1818#msg1818"},{"f":"NewLibertyStandard","d":1277601042,"b":[["t","My vote is for 1.0. It'll probably help us get slashdotted."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1823#msg1823"},{"f":"lachesis","d":1277602411,"b":[["t","+1 NLS. Version 1.0 sounds better than 1.3."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1824#msg1824"},{"f":"satoshi","d":1277642630,"b":[["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=217.msg1827#msg1827","s":1,"n":157,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/157/"},{"f":"lachesis","d":1277646438,"b":[["t","True, and it is your project. 1.3 it is!"]],"u":"https://bitcointalk.org/index.php?topic=217.msg1829#msg1829"},{"f":"NewLibertyStandard","d":1277714202,"b":[["q","Proprietary software developers often start at version 1 for the first release of a program and increment the major version number with each rewrite. This can mean that a program can reach version 3 within a few months of development, before it is considered stable or reliable.\n\nIn contrast to this, the free-software community tends to use version 1.0 as a major milestone, indicating that the software is \"complete\", that it has all major features, and is considered reliable enough for general release.","Quote from: Wikipedia"],["t","Quote Source <http://en.wikipedia.org/wiki/Software_versioning#Version_1.0_as_a_milestone>\n\nThe above description is how I and most geeks view version 1.0 software. Slashdot readers and editors will understand that 1.0 means that we're ready for business. Getting on Slashdot is the best advertising opportunity we'll probably get for a very long time, so to willfully pass it up seems unwise to me."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1847#msg1847"},{"f":"D҉ataWraith","d":1277727471,"b":[["t","I agree with lachesis and NLS. Version 1.0 is better for publicity, and is commonly taken to mean \"we're out of beta now, but don't expect everything to be perfect.\""]],"u":"https://bitcointalk.org/index.php?topic=217.msg1849#msg1849"},{"f":"teppy","d":1277750326,"b":[["t","I agree as well - \"version 1.0\" is ready-made for Slashdot."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1850#msg1850"},{"f":"Bitcoiner","d":1277752813,"b":[["t","1.0 is a nice version number to get started off with, and indicates that the software is ready for prime time. A jump from 0.2 to 1.3 would be a little strange."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1851#msg1851"},{"f":"The Madhatter","d":1277759235,"b":[["t","I also agree with v1.0 for the same reasons posted above. Publicity would also be nice. Wink"]],"u":"https://bitcointalk.org/index.php?topic=217.msg1853#msg1853"},{"f":"dkaparis","d":1277771818,"b":[["t","FWIW I'd vote for 1.0 too.\n\nAs NLS and D҉ataWraith have pointed, there are certain perceptions associated with a 1.0 release and they are mostly reasonable. Trying to cheat these perceptions in such way is unwise in my opinion. Much better to release 1.0 now and do another minor release or two shortly afterwards."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1857#msg1857"},{"f":"Bitcoiner","d":1277856289,"b":[["q","FWIW I'd vote for 1.0 too.\n\nAs NLS and D҉ataWraith have pointed, there are certain perceptions associated with a 1.0 release and they are mostly reasonable. Trying to cheat these perceptions in such way is unwise in my opinion. Much better to release 1.0 now and do another minor release or two shortly afterwards.","Quote from: dkaparis on June 29, 2010, 12:36:58 AM"],["t","And if not 1.0, there's nothing wrong with 0.3. Tor is only at 0.2 and is a popular anonymity network. It's all about networking and how you present the application. Tor has user-friendly client software and a user-friendly website. Is Bitcoin really even 1.0 software? I would argue that it is still missing a lot of polish and features. 0.3 is fine; just improve the marketing, the user-friendliness and look & feel of the website, and usage will keep increasing."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1880#msg1880"},{"f":"Xunie","d":1277861827,"b":[["t","I vote for \"1.0\" and not \"1.3\" or something, bleh!\n(I also advice we use a major, minor and patch level version number, \"0.0.00\".)\nI've used bitcoin-1.3.0.rc3-linux[1] and found it to be mature enough to be called \"1.0\" in my opinion.\n(It was already called 1.3 there, but I guess we cal all agree it's the next release, thus right now can be called both 1.3 and 0.3.)\n\n[1] http://www.bitcoin.org/download/bitcoin-1.3.0.rc3-linux.tar.gz"]],"u":"https://bitcointalk.org/index.php?topic=217.msg1882#msg1882"},{"f":"NewLibertyStandard","d":1277864189,"b":[["t","I think version 0.3 would be a better choice if Bitcoin wasn't making financial transactions on Windows. A significant number of people, particularly Windows users, don't trust software below version 1.1 or 1.2, but going from version 0.2 to 1.3 will backfire when those users find out we skipped the first three 1.x versions."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1884#msg1884"},{"f":"laszlo","d":1277865927,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1885#msg1885"},{"f":"satoshi","d":1278108221,"b":[["t","OK, back to 0.3 then.\n\nPlease download RC4 and check it over as soon as possible.  I'd like to release it soon.\n\nhttp://bitcointalk.org/index.php?topic=199.msg1927#msg1927\n\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."]],"u":"https://bitcointalk.org/index.php?topic=217.msg1928#msg1928","s":1,"n":164,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/164/"}]},{"id":"p77","k":"p","s":"bitcointalk","t":"IPv6, headless client, and more","u":"https://bitcointalk.org/index.php?topic=218","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/77/","m":[{"f":"HarryS","d":1277594271,"b":[["t","Hello, I heard about this project around freenode, and I really like the idea.\n\nI am wondering if there is a chance you could develop a fully headless version, but with controlling options? Maybe something similar to ncurses work, like rtorrent? So we can make and share bitcoins on headless computers, while still having the ease and control of te GUI interface?\n\nAnother suggestion that would be nice would be an update module, if you are running an old version (don't know if there is already, didn't look around much).\n\nBoot strapping to a different type of medium, as well as IRC, would be an improvement as well. Maybe something similar to Bittorrent trackers? Some ISPs block IRC, and some people dislike the thought of IRC.\n\nLastly, IPv6 support would be pretty awesome, if possible. Then people would worry less about the IRC bootstrapping, I'd think.\n\nI am also running bitcond 1.3 (RC?) that satoshi just posted. How do I use it though? There aren't many docs on using bitcoind... it just said \"starting bitcoin server\", and my IP appears in the #bitcoin room on irc.lfnet.org. How would I figure out my bitcoin address, how many coins I have, send to other people, etc?\n\nI am no C programmer, so I would not be able to implant any of these suggestions, but I would hope that it could be possible Smiley\n\nThanks in advance!"]],"u":"https://bitcointalk.org/index.php?topic=218.msg1820#msg1820"},{"f":"Gavin Andresen","d":1277596467,"b":[["q","I am also running bitcond 1.3 (RC?) that satoshi just posted. How do I use it though? There aren't many docs on using bitcoind... it just said \"starting bitcoin server\", and my IP appears in the #bitcoin room on irc.lfnet.org. How would I figure out my bitcoin address, how many coins I have, send to other people, etc?","Quote from: HarryS on June 26, 2010, 11:17:51 PM"],["t","You can talk to the running bitcoind either by:\n 1. sending JSON-RPC calls; see http://www.bitcoin.org/wiki/doku.php?id=api for more details.\n 2. re-running bitcoind and giving it extra arguments; it will figure out that there's already a bitcoind running and will pass along the commands.\n\nFor example, running \"bitcoind help\" gives you the list of commands it understands:"],["c","bitcoind help\ngetaddressesbylabel <label>\nlistreceivedbyaddress [minconf=1] [includeempty=false]\ngetreceivedbyaddress <bitcoinaddress> [minconf=1]\ngetbalance\ngetblockcount\ngetblocknumber\ngetconnectioncount\ngetdifficulty\ngetgenerate\ngetinfo\ngetlabel <bitcoinaddress>\ngetnewaddress [label]\ngetreceivedbyaddress <bitcoinaddress> [minconf=1]\ngetreceivedbylabel <label> [minconf=1]\nhelp\nlistreceivedbyaddress [minconf=1] [includeempty=false]\nlistreceivedbylabel [minconf=1] [includeempty=false]\nlisttransactions [count=10] [includegenerated=false]\nsendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]\nsetgenerate <generate> [genproclimit]\nsetlabel <bitcoinaddress> <label>\nstop"],["t","To figure out what your bitcoin address is, run:\nbitcoind getaddressesbylabel \"\"\n(your default address has the empty string as its label)."],["c"," bitcoind getaddressesbylabel \"Your Address\" "],["t","To figure out how many coins you have, run:"],["c"," bitcoind getbalance "],["t","or"],["c"," bitcoind getinfo "],["t","Regarding running headless:  the non-daemon bitcoin will run via remote (e.g. ssh forwarded) X-windows, if you install the necessary X11-client stuff on your server."]],"u":"https://bitcointalk.org/index.php?topic=218.msg1822#msg1822"},{"f":"HarryS","d":1277603017,"b":[["t","Ah, nice, thanks for that.\n\nWhen I run,"],["q","./bitcoind getaddressesbylabel \"\"\n[\n]","Quote"],["t","Is it normal for it to give nothing, or what?\n\ngetinfo gives me"],["q","./bitcoind getinfo\n{\n    \"balance\" : 0.000000000000000,\n    \"blocks\" : 62899,\n    \"connections\" : 39,\n    \"proxy\" : \"\",\n    \"generate\" : false,\n    \"genproclimit\" : -1,\n    \"difficulty\" : 19.40479632838217\n}","Quote"]],"u":"https://bitcointalk.org/index.php?topic=218.msg1825#msg1825"},{"f":"Gavin Andresen","d":1277603707,"b":[["q","When I run,\n\n> Quote\n> ./bitcoind getaddressesbylabel \"\"\n> [\n> ]\nIs it normal for it to give nothing, or what?","Quote from: HarryS on June 27, 2010, 01:43:37 AM"],["t","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:  "],["c","./bitcoind getaddressesbylabel \"Your Address\""],["t"," should work.\n\nOr just generate a new address, either with or without a label:"],["c","./bitcoind getnewaddress"]],"u":"https://bitcointalk.org/index.php?topic=218.msg1826#msg1826"},{"f":"satoshi","d":1277643758,"b":[["t","Welcome, Harry.\n\nI hadn't thought about starting out using bitcoind without using bitcoin first.  I guess for now, this thread serves as the tutorial. \n\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."]],"u":"https://bitcointalk.org/index.php?topic=218.msg1828#msg1828","s":1,"n":158,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/158/"}]},{"id":"p78","k":"p","s":"bitcointalk","t":"Feature Request: Limiting Connections","u":"https://bitcointalk.org/index.php?topic=223","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/78/","m":[{"f":"lachesis","d":1277772112,"b":[["t","I'd like to see an option (with an RPC interface as well) to limit the number of connections that a Bitcoin client accepts. My home client is connected to 70 different nodes and my poor wimpy router just can't keep up. It's starting to slow my network down, to the point where I'll need to force Bitcoin to ignore connection requests (with -connect=<a node>) if this keeps up.\n\nA connection limiting option would be a great alternative."]],"u":"https://bitcointalk.org/index.php?topic=223.msg1859#msg1859"},{"f":"Vasiliev","d":1277774391,"b":[["t","Unforward port 8333 Tongue\nIt'll limit it to 15 and still work fine."]],"u":"https://bitcointalk.org/index.php?topic=223.msg1864#msg1864"},{"f":"lachesis","d":1277776367,"b":[["t","Alright. Thanks.\n\nWould still be a nice feature. I don't mind people connecting to me to bootstrap or something, and I'd probably leave it at 40 rather than 15."]],"u":"https://bitcointalk.org/index.php?topic=223.msg1865#msg1865"},{"f":"BitcoinFX","d":1277862844,"b":[["t","Might I 2nd this request as a 'standard' GUI feature.\n\nI've recently tested bitcoin through various socks proxies / providers and the ability to limit connections below 10 would be really useful.   "]],"u":"https://bitcointalk.org/index.php?topic=223.msg1883#msg1883"},{"f":"satoshi","d":1278098496,"b":[["t","Thanks for the feedback on this.\n\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.\n\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.\n\nI will implement a feature to stop accepting inbound connections once you hit a certain number.\n\nWhich version are you running?\n\nAnyone know how many connections typical P2P software like BitTorrent can get up to?"]],"u":"https://bitcointalk.org/index.php?topic=223.msg1924#msg1924","s":1,"n":161,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/161/"},{"f":"laszlo","d":1278099204,"b":[["t","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.\n\nTorrent clients generally have options for configuring a global maximum number of connections, maximum inbound and maximum outbound connections.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=223.msg1925#msg1925"},{"f":"satoshi","d":1278109220,"b":[["t","I reduced max outbound connections from 15 to 8 in RC4.\n\n15 was way more than we needed for redundancy.  8 is still plenty of redundancy.\n\nAs the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get.\n\nIf anyone wants more than 8 connections, they can open port 8333 on their firewall."]],"u":"https://bitcointalk.org/index.php?topic=223.msg1929#msg1929","s":1,"n":165,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/165/"}]},{"id":"p79","k":"p","s":"bitcointalk","t":"Slashdot Submission for 1.0","u":"https://bitcointalk.org/index.php?topic=234","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/79/","m":[{"f":"teppy","d":1278346072,"b":[["t","Unless anyone else knows a Slashdot editor, I'd be willing to submit this when 1.0 is released. (More people submitting their own versions will improve the chances of hitting the front page.)\n\n(Technology Section)\nHeadline: Bitcoin releases Version 0.3\nTag: Encryption\nBody: How's this for a disruptive technology? Bitcoin is a peer-to-peer network based digital currency with no central bank, and no transaction fees. Using a proof-of-work concept, nodes burn CPU cycles searching for bundles of coins, broadcasting their findings to the network. Analysis of energy usage indicates that the market value of Bitcoins is already above the value of the energy needed to generate them, indicating healthy demand. The community is hopeful the currency will remain outside the reach of any government.\n\nComments?\n\n[Edited the \"energy backed\" language.]\n[Eliminated the 21M number, as db suggested. Mentioning subdividing would be too wordy.]\n[Incorporated some of amall's suggestions, including eliminating the passive voice in the final sentence.]\n[Integrated satoshi's suggestions, eliminating the word \"anonymous\", mention of Hashcash, and the \"developers expect\" taunt.]\n[Changed the closing sentence to dwdollar's \"...community is hopeful...\" language. Satoshi, are you OK with that?]"]],"u":"https://bitcointalk.org/index.php?topic=234.msg1967#msg1967"},{"f":"llama","d":1278349508,"b":[["t","I wouldn't call bitcoin \"energy backed\".  There has been ample discussion on this and varying opinions, but I think most people would say that the bitcoin's value determines the amount of energy required to generate them, and not the other way around.\n\nIn the short run, the energy cost of generation may ensure a baseline value, but in the long run the value will be solely based on human behavior.\n\nThanks for pushing for a slashdot feature, bitcoin could really use some publicity to help it grow."]],"u":"https://bitcointalk.org/index.php?topic=234.msg1968#msg1968"},{"f":"Timo Y","d":1278350462,"b":[["q","Unless anyone else knows a Slashdot editor, I'd be willing to submit this when 1.0 is released. (More people submitting their own versions will improve the chances of hitting the front page.)\n\n(Technology Section)\nHeadline: Bitcoin releases Version 1.0\nBody: How's this for a disruptive technology? Bitcoin is a buyer-anonymous, seller-anonymous cryptocurrency with no central bank, and no transaction fees. Using a concept similar to Hashcash, clients burn CPU cycles attempting to discover some of the 21,000,000 Bitcoins that will eventually be found. It is expected that over time, the market value of Bitcoins will reach parity with the energy needed to generate them, resulting in an energy-backed currency outside the reach of any government.\n\nComments?","Quote from: teppy on July 05, 2010, 04:07:52 PM"],["t","1) I like the first two sentences.\n\n2) Not sure whether I would include the \"similar to Hashcash\" phrase. I doubt that the majority of slashdot users has ever heard of Hashcash.\n\n3) I have a problem with the \"energy-backed\" claim. It's misleading. Just because you need to invest energy to generate Bitcoins doesn't make them energy-backed. They would only be energy-backed if there was some sort of guarantee that they could be traded back into energy. Which there isn't. The generation of Bitcoins is irreversible. If the software was hardcoded so that you could buy other users' CPU cycles with Bitcoins, then maybe we could call them energy-backed."]],"u":"https://bitcointalk.org/index.php?topic=234.msg1969#msg1969"},{"f":"db","d":1278356316,"b":[["t","Mentioning the 21 000 000 bitcoins but not that they can be divided in 100 000 000 pieces each is confusing. It doesn't sound like a practical currency."]],"u":"https://bitcointalk.org/index.php?topic=234.msg1972#msg1972"},{"f":"llama","d":1278357896,"b":[["t","Good revisions so far.\n\nMore suggestions:\n\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.\n\n2) \"...clients burn CPU cycles...\" --> \"...nodes burn CPU cycles...\"\n\n3)  Throw in \"decentralized\" and \"proof-of-work based\" somewhere\n\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? \n\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.\n\nFeel free to take all, none, or somewhere in between.  We're critical because we care  Wink"]],"u":"https://bitcointalk.org/index.php?topic=234.msg1973#msg1973"},{"f":"satoshi","d":1278365474,"b":[["t","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.\n\nI really appreciate the effort, but there are a lot of problems.\n\nWe don't want to lead with \"anonymous\".  (I've been meaning to edit the homepage)\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=234.msg1976#msg1976","s":1,"n":167,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/167/","qt":["Writing a description for this thing for general audiences is bloody hard.  There's nothing to relate it to."],"qc":["general"]}]},{"id":"p80","k":"p","s":"bitcointalk","t":"Bitcoin 0.3 released!","u":"https://bitcointalk.org/index.php?topic=238","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/80/","m":[{"f":"satoshi","d":1278441155,"b":[["t","Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.  Escape the arbitrary inflation risk of centrally managed currencies!  Bitcoin's total circulation is limited to 21 million coins.  The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Transaction filter tabs\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero)\n\nGet it at http://www.bitcoin.org or read the forum to find out more."]],"u":"https://bitcointalk.org/index.php?topic=238.msg2004#msg2004","s":1,"n":168,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/168/","qt":["Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.  Escape the arbitrary inflation risk of centrally managed currencies!  Bitcoin's total circulation is limited to 21 million coins.  The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time."],"qc":["releases"]}]},{"id":"p81","k":"p","s":"bitcointalk","t":"Security","u":"https://bitcointalk.org/index.php?topic=240","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/81/","m":[{"f":"Bitcoiner","d":1278514380,"b":[["t","Has there been a concerted effort to attack, subvert, or break Bitcoin? One way to test that it is secure from attack would be to actually try to undermine it, by double-spending coins, creating fake coins, posting false transactions, etc... and if flaws are found, better that they are found now than later, when the bitcoin economy is potentially larger and there is more to lose."]],"u":"https://bitcointalk.org/index.php?topic=240.msg2022#msg2022"},{"f":"Gavin Andresen","d":1278699087,"b":[["t","It's a bad idea to try to break the \"in-production\" bitcoin network.\n\nIf anybody is starting serious work on either extending Bitcoin or developing compatible implementations or trying to break it by creating bad transactions, I think creating a \"parallel universe\" test network with its own block chain, data directory, etc makes sense.\n\nSatoshi:  would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel?  Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.\n "]],"u":"https://bitcointalk.org/index.php?topic=240.msg2104#msg2104"},{"f":"llama","d":1278706407,"b":[["q","Satoshi:  would you be open to a --testnetwork (or something) flag to bitcoin that swapped to an alternate genesis block, data directory, listen port and IRC channel?  Maybe with a really short average block generation time, too (like once per minute instead of once per 10 minutes) so everything happens ten times a fast to make testing quicker.\n ","Quote from: gavinandresen on July 09, 2010, 06:11:27 PM"],["t","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.\n\nGreat idea Gavin!"]],"u":"https://bitcointalk.org/index.php?topic=240.msg2105#msg2105"},{"f":"satoshi","d":1278766682,"b":[["t","I'll start thinking about how to do this.\n\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.\n\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.\n\nvoid ThreadIRCSeed(void* parg)\n{\n    if (mapArgs.count(\"-connect\"))\n        return;"]],"u":"https://bitcointalk.org/index.php?topic=240.msg2132#msg2132","s":1,"n":176,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/176/"}]},{"id":"p82","k":"p","s":"bitcointalk","t":"Anonymity","u":"https://bitcointalk.org/index.php?topic=241","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/82/","m":[{"f":"theymos","d":1278521684,"b":[["t","The current BitCoin implementation is certainly better than using a credit card, but I wouldn't use it in environments requiring strong anonymity without a lot of changes.\n\nThe history of a coin is publicly available. Anyone can see the flow of BitCoins from address to address.\n\n <http://static/img707.imageshack.us/i/unknownaddress.png/>\n\nThis becomes a problem when certain points in the \"transaction chain\" become known to the attacker. In the image below, the attacker controls both the source of Mr. Doe's BitCoins and the destination. Since Doe bought his coins using non-anonymous methods, he is easily identified. His identity is tied to an address in the transaction chain.\n\n <http://static/img682.imageshack.us/i/known.png/>\n\nA more likely scenario is for your BitCoin balance to come from transactions made over insecure channels (email, this forum, etc.). If you're particularly careless, the destination can just Google all of the addresses in the transaction chain. Maybe he'll find that one of them is in your forum signature here.\n\nI've thought of two ways to make this harder. The first is to randomly send your coins to new addresses that you've generated just for this purpose. The coins are still part of your balance, but it's impossible for an outsider to prove that you sent the coins to yourself instead of a real person. However, the transaction chain still has your identity in it. In a real investigation, you would be targeted for close examination because you either know (directly or indirectly) the real person who is under investigation, or you are that person.\n\n <http://static/img692.imageshack.us/i/simplemix.png/>\n\nThe second way is for an external service to take the coins of many different people, mix them up, and send similar amounts back to those peoples' addresses. If the mixer keeps no logs of who gets which coins, any investigation must stop here.\n\n <http://static/img293.imageshack.us/i/external.png/>\n\nFor maximum security, BitCoin should have the capability to automatically send coins through several external mixers. Assuming at least one of them doesn't keep logs (and all of them actually return your coins), this should keep you completely safe.\n\nThere's a problem with safely coordinating all of this. You want all of your coins to be mixed at least once, but keeping track of this in a database will ruin your plausible deniability. Probably you'd have to initially keep track, but then delete the database after all the coins have been made safe.\n\nUnrelated to the chain issues above, BitCoin is vulnerable to network analysis. If an attacker can watch all of your incoming and outgoing traffic, he can easily see which transactions are yours. If the connection is unencrypted (as it is now), he can see when you broadcast a transaction that you didn't receive.\n\nEven when encrypted (through Tor or a built-in mechanism), it's not impossible for an attacker to see which transactions are yours if he can see both ends of one of your connections to the BitCoin network.\n\nYour transactions can be identified through Tor like this:\n1. The attacker fills the BitCoin network with IP addresses that he controls.\n2. When one of these \"evil nodes\" receives a packet, the attacker sees if it was received close to the time when he saw you send a packet. If this happens a few times, the attacker knows who you are and can see your transmissions to the network.\n3. When you send a transaction, the attacker knows it's yours if you send it without receiving a packet in a while.\n\nTo fix this, BitCoin should implement encryption, padding (to prevent any size-based identification), dummy packets, and randomization in sending times. Some plausible deniability could also be added if BitCoin could export and import transactions to/from a file (importing would broadcast the transaction to the network, while exporting would not). Then you could transmit this file in other ways (a flash drive, for example).\n\nI also see two structural problems not related to anonymity:\n- If the network is segmented at the network layer (because the PoTUS executed his \"Internet kill switch\", for example), the block chain will be forked. This would be really bad.\n- It's very easy for an attacker with lots of IP addresses to fill the network with cancer nodes. I'm not sure how badly BitCoin could be affected by this."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2025#msg2025"},{"f":"Gavin Andresen","d":1278525456,"b":[["t","Whatever mechanism is chosen, it had better not significantly slow down the network or client unless strong anonymity is required/requested.\n\nI've tried I2P and Tor, and, for me, super-strong privacy isn't worth the performance cost.\n\nAlso, regarding forking the block chain by a network split:\n\nIt's only \"really bad\" if I can get away with double-spending some coins before the network merges again.\nIf I'm buying valuable stuff, then the merchants will likely require 6 confirmations before releasing the goods, so I'd have to be able to keep the network split for an hour or more.\n\nMerchants will likely have very-well-connected, long-running nodes.  For example, the Bitcoin Faucet has 66 connections right now.  If I wanted to try to implement a \"fork the block chain attack\" I'd have to somehow manage to insert my \"cancer nodes\" in between two merchants that I want to rip off (I'll end up ripping off one of the two, because eventually one of the two double-spend transactions will \"win\").\n\nI don't know enough about network analysis to figure out how many cancer nodes you'd need to have a significant chance of getting in between two merchants with 60+ connections in a network of (say) 1,000 non-cancerous nodes, but I bet it is a very large number."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2026#msg2026"},{"f":"theymos","d":1278527721,"b":[["t","Everything I mentioned could be user-configurable, and most of it wouldn't slow down actual transactions. Even if you had all of these security features disabled, just having them implemented would give you plausible deniability in certain cases.\n\nBlock generation would be slowed in the case of a network split, so executing a double-spend would be even more difficult. I was thinking more of a problem like the Cogent-Level3 peering dispute, where there is no path between two ISPs for a long while. In this case, lots of transactions would be lost when the network is recombined and one of the chain's branches is discarded."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2029#msg2029"},{"f":"Gavin Andresen","d":1278528116,"b":[["t","Would the transactions on the other block chain be lost?\n\nI thought they'd just be re-integrated into the new-best-chain (if they were valid), just starting with '1 confirmation' again..."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2030#msg2030"},{"f":"theymos","d":1278528784,"b":[["t","I don't know how this is currently handled. It might already be fixed. I haven't looked at the source."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2031#msg2031"},{"f":"llama","d":1278530885,"b":[["t","Anonymity is not a feature that most users need."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2034#msg2034"},{"f":"NewLibertyStandard","d":1278534366,"b":[["t","*Strong"],["q","Anonymity is not a feature that most users need.","Quote from: amallama on July 07, 2010, 07:28:05 PM"]],"u":"https://bitcointalk.org/index.php?topic=241.msg2038#msg2038"},{"f":"llama","d":1278543395,"b":[["q","*Strong\n\n> Quote from: amallama on July 07, 2010, 07:28:05 PM\n> Anonymity is not a feature that most users need.","Quote from: NewLibertyStandard on July 07, 2010, 08:26:06 PM"],["t","That's my Steve Jobsian statement of the day Wink\n\nI'm not saying that it's not something worth working on, but we shouldn't prioritize anonymity features ahead of basic functionality, ease-of-use, and driving adoption.  There can always be a special implementation (maybe a separate client even) down the road that takes care of all of the features for ensuring anonymity.   As Gavin implied, many anonymity features would come at cost to users who don't need them."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2042#msg2042"},{"f":"Bitcoiner","d":1278544849,"b":[["t","I don't know, I personally find it rather disconcerting if users in the chain can be identified. For example, it wouldn't be enough for me to simply get bitcoins at an exchange, send them to a random address, and then use them from that point on. Your identity would still be linked. However, given the public nature of the transactions, I'm not sure if there is any way around this.\n\nI agree with you though, the software needs to be usable with a well-designed UI, and it needs to be robust. Bitcoin needs a full security audit to see how robust it is to different kinds of attacks, and what is compromised."],["q","> Quote from: NewLibertyStandard on July 07, 2010, 08:26:06 PM\n> *Strong\n>\n>\n> > Quote from: amallama on July 07, 2010, 07:28:05 PM\n> > Anonymity is not a feature that most users need.\n\nThat's my Steve Jobsian statement of the day Wink\n\nI'm not saying that it's not something worth working on, but we shouldn't prioritize anonymity features ahead of basic functionality, ease-of-use, and driving adoption.  There can always be a special implementation (maybe a separate client even) down the road that takes care of all of the features for ensuring anonymity.   As Gavin implied, many anonymity features would come at cost to users who don't need them.","Quote from: amallama on July 07, 2010, 10:56:35 PM"]],"u":"https://bitcointalk.org/index.php?topic=241.msg2044#msg2044"},{"f":"Gavin Andresen","d":1278547868,"b":[["q","I don't know, I personally find it rather disconcerting if users in the chain can be identified. For example, it wouldn't be enough for me to simply get bitcoins at an exchange, send them to a random address, and then use them from that point on. Your identity would still be linked. However, given the public nature of the transactions, I'm not sure if there is any way around this.","Quote from: Bitcoiner on July 07, 2010, 11:20:49 PM"],["t","I'm sure somebody somewhere would/will be happy to sell you bitcoins anonymously; just put cash and a bitcoin receiving address in an envelope and mail it.  The exchange (who you'd have to trust to actually send you the coins) takes the cash and send coins to the address.  They have no idea who you are, and your identity isn't linked to the coins.\n\nWell, it isn't linked to the coins until you forget to turn on TOR or I2P before spending coins on something illegal.  Or you remain completely and utterly anonymous right up until you spend coins on something physical and have it shipped to your home address.  Or you arrange to have contraband \"dead dropped\" somewhere, and you get arrested when you go to pick it up.\n\nNone of which have anything to do with Bitcoins, and all of which seem to me to be more likely ways of getting into trouble than somebody managing to figure out that \"transaction for purchase of illegal stuff\" is linked to \"Gavin purchased a bunch of Bitcoins from Bobby's Discount Bitcoin Emporium\" last year."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2045#msg2045"},{"f":"NewLibertyStandard","d":1278552962,"b":[["t","+1 to Previous Post by gavinandresen\n\nBecause Bitcoin transactions are not forced through the regulated banking system, bitcoins can range from being not at all anonymous if I announce my transactions on twitter, to being completely anonymous so long as I purchase anonymously, obfuscate ownership by transferring to one or more intermediary addresses and then spend them anonymously. There's nothing wrong with adding that obfuscation optionally, but it's overkill to apply it to all transactions because not everyone needs that level of anonymity and no matter how anonymous you make it, it's never going to be anonymous to the folks who voluntarily reveal their identity."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2046#msg2046"},{"f":"Anonymous","d":1278553705,"b":[["t","90% of money has cocaine on it. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=241.msg2049#msg2049"},{"f":"Timo Y","d":1278593961,"b":[["t","Real life example\n\n1) I set up a fresh Bitcoin address/Bitcoin Client in a VPS hosted in Panama, connected via Tor.\n\n2) I purchase a 100 EUR paysafecard code at some newsagent in a big, densely populated city. I pay cash, and make sure the newsagent is 2 km away from my home.\n\n3) I advertise the sale of the paysafecard code on this forum, via Tor and a free public wifi hotspot,  using a fresh username.\n\n4) A buyer shows up. I send him my bitcoin address and the paysafecard code from a freshly set up webmail address, again via Tor and a free public wifi hotspot.\n\nUsing above precautions, it will be very difficult to link my physical identity to my bitcoin address. Not impossible, but difficult enough for my purposes. "]],"u":"https://bitcointalk.org/index.php?topic=241.msg2056#msg2056"},{"f":"llama","d":1278607021,"b":[["t","Not bad.\n\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.\n\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.\n\nBy the way, I like to imagine that this user is in China and is trying to buy a book about freedom Wink"]],"u":"https://bitcointalk.org/index.php?topic=241.msg2057#msg2057"},{"f":"satoshi","d":1278616320,"b":[["t","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.\n\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.\n\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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=241.msg2071#msg2071","s":1,"n":172,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/172/"}]},{"id":"p83","k":"p","s":"bitcointalk","t":"BTC Vulnerability? (Massive Attack against BTC system. Is it really?)","u":"https://bitcointalk.org/index.php?topic=242","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/83/","m":[{"f":"user","d":1278526528,"b":[["t","   Hi. (I'm sorry if I don't understand any concept).\n What you think if anyone intruder will buy up bitcoin currency and erase all binary data. This way can destroy bitcoin systems. Is btc network protected against that attack?"]],"u":"https://bitcointalk.org/index.php?topic=242.msg2028#msg2028"},{"f":"llama","d":1278530180,"b":[["t","That would be the same as an attacker buying all US dollars and burning them.  It's not an effective attack, because people only \"sell\" their dollars when they are getting something of equal or greater value anyway.\n\nSo, yes, it is possible that someone could buy up all or many Bitcoins and then \"destroy\" the private key so that nobody can ever use those bitcoins again, but it really isn't a problem because the attacker is the only one who will actually lose wealth!\n\nThe only scenario that would be at all likely would be if something like a stupid government didn't like bitcoins and thought it was a threat, so they would spend $30,000 or w/e to buy all bitcoins and \"destroy\" them.  That would be pretty stupid though, because another ecurrency just like bitcoin would pop right up!\n\nI suppose if a government actually wanted to hold off these ecurrencies, they should buy lots of the currency but not tell anyone.  However, instead of \"destroying\" it or never spending it, they should just manipulate the market a lot while it's young (buy a ton at once, then sell way undervalue, etc).  Then, not realizing the currency was being manipulated, people would just lose faith in these types of ecurrency...\n\nSorry that got rambly, I'm thinking out loud here."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2033#msg2033"},{"f":"NewLibertyStandard","d":1278531767,"b":[["t","Or they could buy them while they're inexpensive, artificially increase their value, causing people to invest, crash the market, causing lots of people to lose their money and then repeat. Although a concerted effort might be considered fraud."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2035#msg2035"},{"f":"user","d":1278536247,"b":[["t"," (Hypnotically) If I run any two (or more) unique e-currency exchanger I can displace btc e-currency from it circulation.\n I seems, \"truly\" system must include mechanisms that protect self from any fraud activity.\n And what do you think?\n\n2Developers and BTC-system designers: please, join to discussion"]],"u":"https://bitcointalk.org/index.php?topic=242.msg2039#msg2039"},{"f":"laszlo","d":1278536321,"b":[["t","My daughter ripped a dollar bill in half earlier when she got into her mom's wallet.. It's not really worth it for me to try to get a dollar bill replaced by the treasury so I just consider it destroyed - but it's not really going to affect my budget and certainly not the economy of the United States.  There are about 65000 blocks so over 3 million bitcoins have been in circulation.  Many of them have probably been destroyed by accident when someone lost a wallet file or whatever..\n\nIf you want to buy a bunch of bitcoins (or dollar bills) from me and destroy them let me know, I can give you a good exchange rate for bulk transactions like that Smiley\n\nFor dollar bills I would charge 1.03 to make it worth my while but I will have them sent by air mail or courier depending on the distance.\n\nI think if a government wanted to get rid of bitcoins they would just take us away in black helicopters - probably Satoshi first.."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2040#msg2040"},{"f":"laszlo","d":1278609925,"b":[["t","I don't think you understood my point.\n\nIt is a lot easier to arrest and lock up the prominent bitcoin users than to manipulate the market.  Like it was pointed out, a market is not just a single currency, it can be a lot of different types of currency and goods.  Trying to manipulate one end or the other would be difficult.  It is better to just get the people - fear of being arrested is much more effective than trying to shake up confidence in the currency.\n\nDestroying a large amount of currency just causes deflation and makes the remaining currency that much more desirable - imagine if you had a pallet of gold bars in your garage and nobody else did.\n\nMaybe you don't agree with my assessment of the situation but what you posted was far from constructive.\n\nIn response to your original post, I don't believe the situation you describe is a big risk."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2062#msg2062"},{"f":"user","d":1278615747,"b":[["q","I don't think you understood my point.","Quote from: laszlo on July 08, 2010, 05:25:25 PM"],["t","Ok, let's elaborate It.\n\nYou wrote:"],["q","It is a lot easier to arrest and lock up the prominent bitcoin users than to manipulate the market.","Quote from: laszlo on July 08, 2010, 05:25:25 PM"],["t","But I write earlier:"],["q"," What you think if anyone intruder will buy up bitcoin currency and erase all binary data. This way can destroy bitcoin systems. Is btc network protected against that attack?","Quote from: user on July 07, 2010, 06:15:28 PM"],["t","And If you try to lookup subject carefully you can find:"],["q","Massive Attack against BTC system.","Quote from: user"],["t","I don't discuss in another attack that you indicated (I understand you idea: attack to system through people).\n\nOk. Follow next."],["q","Maybe you don't agree with my assessment of the situation but what you posted was far from constructive.","Quote from: laszlo on July 08, 2010, 05:25:25 PM"],["t","The main idea why I begin this thread:"],["q"," I seems, \"truly\" system must include mechanisms that protect self from any fraud activity.","Quote from: user on July 07, 2010, 08:57:27 PM"],["q","In response to your original post, I don't believe the situation you describe is a big risk.","Quote from: laszlo on July 08, 2010, 05:25:25 PM"],["t","But I think that It will be better if in design-time developers build mechanisms that decrease potential of fraudulent ability. And you?\n\nPlease, explain me if I am wrong. I want to understand you reflections."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2070#msg2070"},{"f":"laszlo","d":1278618710,"b":[["t","You can't destroy them all, more will be generated constantly.  That 21 million number is not going to be reached in the foreseeable future.  As you know, the generation algorithm adjusts itself to slow the generation rate intentionally."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2073#msg2073"},{"f":"lachesis","d":1278623636,"b":[["t","It is unnecessary to protect against an attack in which an attacker buys all Bitcoins and deletes their wallet.\n\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.\n\nEssentially, no matter what happens there is always the nuclear option of \"starting over.\"\n\nThere are much more dangerous and likely attacks to be worried about."]],"u":"https://bitcointalk.org/index.php?topic=242.msg2074#msg2074"},{"f":"satoshi","d":1278646126,"b":[["t","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.\n\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]\"\n\nhttp://en.wikipedia.org/wiki/Cornering_the_market"]],"u":"https://bitcointalk.org/index.php?topic=242.msg2078#msg2078","s":1,"n":174,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/174/","qt":["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."],"qc":["economics"]}]},{"id":"p84","k":"p","s":"bitcointalk","t":"bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username","u":"https://bitcointalk.org/index.php?topic=246","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/84/","m":[{"f":"m0mchil","d":1278581596,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=246.msg2052#msg2052"},{"f":"satoshi","d":1278613459,"b":[["t","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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=246.msg2068#msg2068","s":1,"n":171,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/171/"},{"f":"satoshi","d":1278644495,"b":[["t","I think I see where the problem is.  Coincidentally, I recently coded a replacement for the function in question which should fix it.  It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison."]],"u":"https://bitcointalk.org/index.php?topic=246.msg2077#msg2077","s":1,"n":173,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/173/"},{"f":"satoshi","d":1278689825,"b":[["t","I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it.  This change is revision 102 of the SVN."]],"u":"https://bitcointalk.org/index.php?topic=246.msg2092#msg2092","s":1,"n":175,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/175/"}]},{"id":"p85","k":"p","s":"bitcointalk","t":"Scalability","u":"https://bitcointalk.org/index.php?topic=286","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/85/","m":[{"f":"jib","d":1278934577,"b":[["t","Am I correct in understanding that every node receives information about every transaction (as the technical paper says)? Doesn't that make bitcoin completely impractical for use as a currency on a large scale?"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2292#msg2292"},{"f":"laszlo","d":1278937704,"b":[["t","Why do you say that?  Pretty much every P2P system works by replicating the information across all the participating nodes, even 100G movie packs for BitTorrent - we're talking about less than a kilobyte of information for a transaction."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2300#msg2300"},{"f":"Gavin Andresen","d":1278939908,"b":[["t","By the time Bitcoins replace the Euro  Tongue I think most people will be running lightweight clients on wireless smartcards in their (physical) wallet that don't pay attention to every single transaction.\n\nBut that's WAAAY down the road.  And who knows, by then maybe we'll all have a hundred-gigabits of bandwidth in our pants."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2303#msg2303"},{"f":"Anonymous","d":1278940878,"b":[["q","hundred-gigabits of bandwidth in our pants.","Quote"],["t"," Lips sealed"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2307#msg2307"},{"f":"jib","d":1278941285,"b":[["t","Every other P2P system is replicating the information across a small group of participating nodes who are all interested in that content. On average each BitTorrent user downloads the movie once and uploads it once and that's it. And if you can't or don't want to download that 100G movie pack (like the vast majority of internet users) you can still use BitTorrent for smaller things.\n\nBitcoin, on the other hand, gives the whole world (assuming the whole world uses it) a live feed of the whole world's financial transactions all the time, and doesn't stop.\n\nSay it becomes a popular payment method like Paypal or Alipay, which each process a few million transactions a day. That few million multiplied by \"less than a kilobyte\" makes at least a few hundred MB per day. That's more than the average person's internet usage. In some places it's more than the average person's available internet quota. And then that has to be distributed to millions of nodes, putting a significant load on some networks, not just individuals' connections.\n\nI guess it's not quite as bad as I initially thought, but it's still enough to make it impractical for many people to run their own bitcoin clients in a world where bitcoin is popular. The likely scenario (assuming no change to how Bitcoin works) is that most people use big payment providers instead and those providers use Bitcoin between each other.\n\nAnd then one of those providers ends up dominating and has more CPUs than the rest combined, and the whole \"bitcoin is secure as long as the honest CPUs collectively outnumber any attacker\" thing becomes moot.\n\nMaybe."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2308#msg2308"},{"f":"TopSoil","d":1279026324,"b":[["t","This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?\n\nI see 3 scaling issues:\n1) Having every node need to know about all transactions that happened ever.\n2) Keeping the network connected\n3) Amount of coins scaling with increased economic activity.\n\n1) This seems like the biggest issue. Is the hope is that bandwidth and storage will keep pace with the number of transactions? Like the OP said paypal has millions of transactions a day. This will totally clog a lot of users bandwidth if they all have to be notified of each transaction.\nIs the plan to eventually have the chain drop off old blocks? or is there a way to split the chain into parts so only part of the network has to keep track of certain span of coins.\n\n2) What happens when there are a few million concurrent users? everyone connects to IRC still? (Granted this is fixable as the network grows since it seems outside of the whole block chain system)\n\n3) You have this clever method of slowly introducing coins by time but time isn't really the important thing. Shouldn't the amount of coins in circulation be proportional to the amount of users?  If you want to avoid inflation & deflation the number of coins shouldn't the number of coins be proportional to the number of users or number of transactions or some other metric that is closer to the size of the economy?\n(Also I was able to figure out how/why the 21 million number was chosen?)\n\n1 & 2 could be solved by using a distributed hash table:\nYou should really look at http://en.wikipedia.org/wiki/Kademlia\nI haven't looked lately to see if someone has come up with a better distributed storage system but it was by far the best solution a few years ago. (and I've implemented it before if you have questions)"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2546#msg2546"},{"f":"SomeoneD","d":1279047620,"b":[["t","As my first post, I would like to say I'm interested. Experimental Code is always running on this thing, having more won't cause any harm Smiley"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2620#msg2620"},{"f":"knightmb","d":1279049081,"b":[["q","This seems like a great idea but I also don't understand how it will scale? I'm assuming the goal of bitcoin is to be at least as big as paypal right?\n\nI see 3 scaling issues:\n1) Having every node need to know about all transactions that happened ever.\n2) Keeping the network connected\n3) Amount of coins scaling with increased economic activity.","Quote from: TopSoil on July 13, 2010, 01:05:24 PM"],["t","1) Actually, from what I read in the PDF, I don't think it's necessary. It only needs to know that a transfer of *this* coin from Owner A to Owner B was valid. It doesn't matter if 1 year ago, Owner C gave Owner A that coin.\n\n2) It's P2P, someone out there will be connected. I run a 24/7 Dedicated Server just for Bit Coin now on a Fiber connection. Not because I work with them, but because I see the need to donate the resources for the cause.\n\n3) Don't let the 21 million limit fool you. It's more like 21000000.00000000 limit because the coin is so divisible, but for sanity reasons, it would make sense not to be trading coin in the Quadrillion Bundles  Wink"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2625#msg2625"},{"f":"TopSoil","d":1279050181,"b":[["t","1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.\n\n2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.\n\n3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2627#msg2627"},{"f":"spaceshaker","d":1279051991,"b":[["q","3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?","Quote from: TopSoil on July 13, 2010, 07:43:01 PM"],["t","I think we need to be clear to separate inflation/deflation from supply/demand."],["q","So that means that the value of bitcoins will have to change over time which isn't ideal.","Quote from: TopSoil on July 13, 2010, 07:43:01 PM"],["t","What is the value of bitcoin? It has value only in that people perceive that it has value (the same as any fiat currency). Perceptions change all the time. If you want to see how this plays out look at the currency exchange market today. The value of bitcoin will float over time as supply and demand for it ebbs and flows. The important point is that the supply is fixed (once most of the coins are in circulation) and this serves to protect the value of bitcoin. Inflation erodes the value of currency and punishes savers; its a type of tax.\n\nPerhaps this thread would be more appropriate in the economics forum."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2633#msg2633"},{"f":"Bitcoiner","d":1279054915,"b":[["q","3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?","Quote from: TopSoil on July 13, 2010, 07:43:01 PM"],["t","A currency with a fixed supply has 0 inflation/deflation by definition.\n\nYou are probably referring to price inflation/deflation, which is a seperate phenomenon and is unimportant as long as there is no monetary inflation/deflation. Even if you wanted to, there is no meaningful way to do it. Just look at how fudged the CPI numbers are."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2643#msg2643"},{"f":"Strofcon","d":1279055675,"b":[["t","I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.\n\nNow the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2647#msg2647"},{"f":"Bitcoiner","d":1279055797,"b":[["q","I don't know that it's valid to say there is a fixed supply of bitcoins, because as has been discussed elsewhere in the forums, lost coins (lost/stolen wallets, hoarded coins on never-to-connect-again machines, etc) will not be recoverable in any way. So there's a cap on the number of coins that can be created over the lifetime of the currency, but the amount of bitcoins in circulation will not be fixed, as there will inevitably be lost coins as time goes on.\n\nNow the divisibility of the coins is, as I understand it, what helps to insulate the currency against crazy deflation... but the economic discussions usually elude me, so I'm not 100% positive on that.","Quote from: Strofcon on July 13, 2010, 09:14:35 PM"],["t","You have a point here; it would probably be good if there was a mechanism to regenerate lost coins, but I'm not sure how that could be implemented.\n\nAs Bitcoins become more valuable, people will increasingly take precautions. Therefore, the loss should decrease as time goes on. Losing 5000 BTCs worth $5 isn't such a big deal; losing 5000 BTCs worth $10,000 is!"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2649#msg2649"},{"f":"knightmb","d":1279055843,"b":[["q","1) Well even if you are right and the system can forget about old transactions, it still is broadcasting all current transactions to all nodes which doesn't scale. And nodes will need to keep collecting blocks forever which also doesn't scale.","Quote from: TopSoil on July 13, 2010, 07:43:01 PM"],["t","That is a good point, one I didn't think about.  So, let me think out loud here. There are a possible 21 million coins. Every time a block is generated by someone, they earn 50 coins. Right now, I see 66,618 blocks have been generated since the beginning. So that's 66618 x 50 = 3,330,900 coins so far. To reach 21 million, we need to reach 21,000,000 / 50 = 420,000 blocks. 66,618 blocks take up about 56 megabytes of hard disk space. So, perhaps 420,000 blocks (if every single coin is created) would take up about 420000 x 56 / 66618 = 353 megabytes of hard disk space.\n\nThe rest would be transaction history to make sure the owners are valid and older transactions are pruned after a while, so perhaps at full scale, this application could eat up as much as 1GB of hard disk space. So, someone correct me if I'm wrong, but even at full scale, the clients would need about 1GB of hard disk space to contain a fully generated coin network?"],["q","2) Yes I know it is p2p that is why you have to worry about how the network stays connected and not just assume everyone will be connected. There are issues like islanding that you have to worry about if you remove a central point like the irc channel is now. This issue is more minor because this problem has been solved before and you don't have to change the way the currency system works to fix it later. I only mention it because I think the solution to 1 will also help here.","Quote"],["t","From what I read in the release notes, the IRC is just a bootstrap, the new version can work around IRC failure as it has an alternative (but slower) ways to sync up the first time users to the network."],["q","3) I know the number is really 21million*10^8 or whatever. But that is still fixed and the size of the bitcoin economy (hopefully) isn't fixed. The idea is that it will grow right? So that means that the value of bitcoins will have to change over time which isn't ideal. A currency that has 0 inflation/deflation is the most ideal right?","Quote"],["t","Well, imagine if you will, the US and our national gross. It's somewhere in the multi-trillions last I heard. So, if everything had to be converted to dollars, that would be a trillion dollars in circulation (ignore how a complex system like a countries currency, this is way over simplifying).  No imagine all of that was to be transfered into Bit Coins? Well, there are only 21 million Bit Coins, so a 1 to 1 conversion is out of the question. Basically it would have to be scaled back to the decimal points (probably 4 places) to fit all of that in. That still leaves 4 more decimal places in which any economy working in the Quadrillion range is probably out of scope of any country in the world (or all countries combined really)\n\nSo, if you don't think of a 1 to 1 conversion for Bit Coins, because even I want to think of Bit Coins as dollars for example. But it isn't. It is it's own currency within itself whose value is only dependent on the people that use it and what value they give it. It's like that for any currency really, the only difference is, instead of the bank or government in XYZ country being the one who controls how it's created and distributed, WE *all* control how it's created and distributed.\n\nWe are *minting* the coin (through CPU cycles to generate the encryption hashes) and at the same time using it for trade and value. The only difference is, this isn't a USA currency or a Swedish currency, it's all completely electronic. The bank, the teller, the minting; is all of us at the same time. Basically, all of our clients have agreed upon certain rules to follow and as long as each client follows those rules, it can participate. Any client that doesn't (through hacking, cheating, etc.) is basically ignored by the rest. It's like playing a game of soccer where you have two teams competing and one guy just up and grabs the ball, runs down to the other side and throws the ball in. Dances up and down that he scored a point. Well, everyone else will just ignore him and his point, he wasn't playing by the set rules.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2650#msg2650"},{"f":"TopSoil","d":1279057053,"b":[["t","Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better: http://bitcointalk.org/index.php?topic=57.0\n\nknightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.\n\nCan someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2656#msg2656"},{"f":"spaceshaker","d":1279057539,"b":[["q","Can someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.","Quote from: TopSoil on July 13, 2010, 09:37:33 PM"],["t","I will second this. I am investigating whether this is a project I want to invest time and energy into (I am a professional C++ developer) as I see the potential for a revolutionary technology. However if the solution doesn't scale to millions and millions of transactions per-day (and a very large number of blocks) I fear this solution is destined to become more of an interesting research project rather than something that will have longevity and practical usefulness."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2659#msg2659"},{"f":"knightmb","d":1279058938,"b":[["q","Well The economic discussion probably belongs in a different thread so I'll leave it at that. Oh I went to make a new thread but this guy has made my point better: http://bitcointalk.org/index.php?topic=57.0\n\nknightmb: the number of coins per block is set to go down as time goes on so the number ends up being quite a bit larger than that. Also you have to include the transactions. There have been way less transactions during these first 67k blocks than there will be if millions of people start using the system.\n\nCan someone that works on the code please answer this question of how scaling will be dealt with? The most important thing right now seems to be making a good case for why this system will work to get sellers to adopt it. The pdf is too light on details.","Quote from: TopSoil on July 13, 2010, 09:37:33 PM"],["t","Thanks for pointing that out, I wasn't sure how that would scale over time, was just making some guess. Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.\n\nI'm curious myself to how much space it will take.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2663#msg2663"},{"f":"Insti","d":1279064043,"b":[["q","Given that the formula for coin generation should be known somewhere, can't someone just calculate how much disk space X amount of coins will take given XYZ transactions, etc.\nI'm curious myself to how much space it will take.  Smiley","Quote from: knightmb on July 13, 2010, 10:08:58 PM"],["t","From the pdf <http://\"http://www.bitcoin.org/sites/default/files/bitcoin.pdf>:\n\"A block header with no transactions would be about 80 bytes.\"\nand\n\"Once the latest transaction in a coin is buried under enough blocks, the spent transactions before\nit can be discarded to save disk space.\"\n\nso 80 x number of blocks + average transaction size * number of transactions.\n\nPractically, from my disk:\n77428 transactions in 66663 blocks is about 46,752,464 bytes.\nwhich works out to about 600 bytes per transaction (including block headers + database overheads)"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2678#msg2678"},{"f":"Gavin Andresen","d":1279068152,"b":[["q","77428 transactions in 66663 blocks is about 46,752,464 bytes.\nwhich works out to about 600 bytes per transaction (including block headers + database overheads)","Quote from: Insti on July 13, 2010, 11:34:03 PM"],["t","That sounds about right.\n\nSo a million transactions a day would be 600 million bytes.  600 megabytes a day, 18 GB a month.\n\nThat's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.\n\nA million transactions per day is a LOT!  For comparison, in 2006 there were about 60 million credit card transactions per day in the US <http://wiki.answers.com/Q/How_many_credit_card_transactions_per_year_in_the_US>.\n\nEventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be some fancy IPV6 multicast protocol or something).  And they'll implement a couple of gateway nodes (running on really fast connections) that shuttle transaction and block traffic from the current Bitcoin network into the super-efficient network.  And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.\n\nYou know, kind of like how we have those Big Routers in the Sky that handle Internet backbone traffic (or the ultra-fast DNS root servers).  The Internet didn't start out with astoundingly fast routers zinging packets around."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2696#msg2696"},{"f":"spaceshaker","d":1279072320,"b":[["q","And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.","Quote from: gavinandresen on July 14, 2010, 12:42:32 AM"],["t","Is this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.\n\nI am just thinking out loud here...\n\nAlthough the peer-to-peer model is certainly novel perhaps it seems to me to be somewhat utopian. Bear with me for a minute here (I am not trying to troll). Consider banks. Banks have a system whereby they can work together efficiently. I take take money out of a ATM from bank X even though I bank with bank Y. Banks loan money to each other. They are generally cooperative. Instead of every Tom, Dick & Harry having a Bitcoin client on his/her PC (or smartphone) participating in an open P2P network, perhaps there is a collection of Bitcoin \"banks\" who provide the service of hosting and \"peering\" the Bitcoin block chain. These are large enough organizations that they can afford the bandwidth and hardware needed to maintain an infinitely long block chain with a million (or more) transactions a day. These banks would still be peer-2-peer, and hopefully also completely open. Ideally anybody could participate in the peer-2-peer network, its just that the average person won't because of the barrier to entry. These banks still operate using the same fundamental technology we have to day. All of the beautiful facets of Bitcoin are preserved, except that the number of active participants is somewhat reduced. Anybody that _wanted_ to participate still could.\n\nThe problem remaining would be the typical \"last mile\" problem. How does Tom (or Dick or Harry) perform transactions? Well the issue becomes much more straight forward at this point. Now the trust only has to be between two parties (the \"bank\" and Tom). This really becomes more of a proxy issue. Now Tom has to send a transaction request through his \"bank\". It might even be possible to bake into Bitcoin a protocol for proxy transactions.\n\nAnyway...This is just my 2 cents. I would really like a tangible answer to this problem because it seems foundational to the success of this endeavor to me."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2714#msg2714"},{"f":"jib","d":1279072668,"b":[["t","I think a lightweight client would need to trust the fast node it talks to that sees every transaction."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2716#msg2716"},{"f":"TopSoil","d":1279073731,"b":[["q","That's not bad.  Actual network bandwidth will be higher (the way the network is connected you get the same transaction multiple times from your peers).  You won't be running an always-connected-network node on your iPhone, but any low-cost server will give you twenty times that bandwidth per month.  And 18GB isn't much disk space in these days of terabyte hard drives.","Quote"],["t","Not bad? huh? That seems totally broken to me.\nI'm less worried about storage space than the bandwidth and time it will take a new node to enter the network.\nLike you said the blocks are duplicated so a given node must download some multiple of the transactions a day. That is a tremendous amount of downloading.\nAlso any new node must download 216GB for each year the network has been this large!\n\nDoesn't the system also just completely break at some point when the rate of transactions is too high? I could be wrong since I'm not sure exactly how it is decided which transactions go into a particular block. Again the pdf is kind of lacking.\n\nAlso isn't there a problem when 2 computers both solve a block before they realize the other one has? This will become more and more likely as there are more nodes."],["q","Eventually, if Bitcoin survives and gets as popular as credit cards for paying for stuff I expect somebody will create a compatible version with a more efficient network structure (maybe by that time there will be ","Quote"],["t","But it seems like a lot of these things aren't just issues of network structure. They seem inherent in the cryptographic design so it wouldn't be that straight forward to replace. Plus why not address these issues now if only to instill faith that the system is well thought out rather than just wave hands and say \"computers will be faster\" or \"we'll tack on some better networking later\"\n\nAgain I think the general idea is great and I hope the developers have good answers for all these questions. I just want to understand it/make sure it has been thought through carefully enough. I sincerely hope that it actually can work. I'd love to never have to use paypal again."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2719#msg2719"},{"f":"Gavin Andresen","d":1279074045,"b":[["q","> Quote from: gavinandresen on July 14, 2010, 12:42:32 AM\n> And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.\n\nIs this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.","Quote from: spaceshaker on July 14, 2010, 01:52:00 AM"],["t","I'm imagining:\n\nA lightweight client would have a wallet with coins in it (public+private key pairs).\n\nAnd a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.\n\nThe lightweight client sends money by:\n  creating a transaction (signing coins with the private key)\n  sending the signed transaction securely to the ultra-fast server, which puts it on the network.\n  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)\n   (or getting a \"you already spent those coins\" error from the server)\n\nThe lightweight client receives money by:\n  Either polling the server every once in a while, asking \"Any payments to these BC addresses that I have in my wallet?\"\n   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees\n    a relevant transaction with N confirmations)\n  When transactions occur, the lightweight client updates its wallet (adds the coins).\n\nYou don't have to trust the server; it never has your private keys.\n\nWell, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2721#msg2721"},{"f":"knightmb","d":1279078611,"b":[["t","I think then now would be a good point to work out a separate \"server\" and \"client\" for the next release. Those want to run servers that sit on fast fiber connections and run 24/7 (like myself) can do this for the good of the service. Those that just want to send money from point A to point B can use the client which either function as a full blown node server (like it does now) or give the option to connect to \"trusted\" servers in the network and just have the server do the hard work and report back to the client when coins are transfered around properly.\n\nSince the network can be participated by both dedicated server farms and Joe Blow with his laptop, you still maintain the open network and crypto security that you need, but also offer another solution for those less technical and wanting an easy click and send interface that they have now, website payments, etc.\n\nI mean, I'm seeing stories about Bit Coin all over the web now, so the popularity is coming quickly and people are going to poke around the source code and program, then come here to make suggestions/complaints/worship/etc.\n\nMight as well get a head start.  Grin\n\nIt's win/win because people can run thin clients, people can run servers, and those that don't trust either can run their own client/server/p2p application themself, but it all benefits BitCoin one way or another.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2737#msg2737"},{"f":"Gavin Andresen","d":1279081369,"b":[["t","Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.\n\nThere's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:\nDon't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.\n\nI think Satoshi has done an amazingly fantastic job; over the last two days of Bitcoin being \"slashdotted\" I haven't heard of ANY problems with Bitcoin transactions getting lost, or of the network crashing due to the load, or any problem at all with the core functionality.\n\nYes, it's annoying to have to wait for the block chain to download (especially with the Microsoft Security Essentials weirdness), and yes it would be nice if all the pieces of Bitcoin functionality were already nicely separated and ready to be rearranged and extended in all the ways we all want to rearrange and extend it.  But I've been poking at the Bitcoin code for over a month now, and the more I learn the more impressed I become at the thought that's gone into it.\n\nThis quote seems appropriate:\n\"We reject: kings, presidents and voting.\nWe believe in: rough consensus and running code.\"  -- David D. Clark"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2745#msg2745"},{"f":"spaceshaker","d":1279107076,"b":[["q","Making it easier for merchants to accept bitcoins, and users to pay using them, aught to be priority number 1.","Quote from: gavinandresen on July 14, 2010, 04:22:49 AM"],["q","Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.","Quote from: gavinandresen on July 14, 2010, 04:22:49 AM"],["t","I agree with both points but they also seem to be somewhat mutually contradictory to me (this may be because of ignorance more than anything). Perhaps you can illuminate what steps you think need to be taken to \"make it easier for merchants to accept bitcoins and users to pay using them\". In my view, having a lightweight client, build on fairly open standards would facilitate making transactions easier. Ideally this lightweight client would/could be implemented in a number of languages/platforms."],["q","Don't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.","Quote from: gavinandresen on July 14, 2010, 04:22:49 AM"],["t","This is certainly good advice: \"beware of premature optimization\". I would like to point out though that optimization and system architecture are different beasts. Planning for scalability is a system architecture task. The whole \"Don't overengineer\" paradigm is more of an implementation & design principle and suggests that we should be agile in that we only implement what we need today. An agile perspective does not preclude thinking about and planning out the system architecture, at least testing assumptions mentally and ensuring that \"it could scale\" when the time comes for that ability to be added. I have been involved in a number of projects that failed not because the underlying technology was bad, but because scalability was never considered or tested up front. Everything worked perfectly until the system was put \"to the (scalability) test\". A lack of planning and foresight up-front was usually the cause."],["q","This quote seems appropriate:\n\"We reject: kings, presidents and voting.\nWe believe in: rough consensus and running code.\"  -- David D. Clark","Quote from: gavinandresen on July 14, 2010, 04:22:49 AM"],["t","I like this quote. There is certainly something to be said for having something that works. I tend to struggle with being a bit of a purist; I have to work at pragmatism. Having said this, you can say: \"we have great software. It has very few bugs and it hardly ever crashes\" and that all sounds well and good until the day it becomes untrue. Scalability issues can hit you quickly and silently, especially in this day-in-age.\n\nMy preference would be, for a project like this, would be to continue to have \"working software\" but also establish a well defined road-map of where we hope the software is going. This road map needs to discuss scalability and how we envision a system with a million transactions a day would work and looks, not just today but 20 years from now. A currency needs to be resilient. For people to assign value to Bitcoin they need to perceive that it has value and that it is safe. This means they need to be able to trust that the infrastructure & design is (and will be) perpetually reliable. Unfortunately I don't Bitcoin, if it is to be successful, as the luxury of being just another hacked together open source project (I'm not implying that it is hacky...I'm implying that the prevailing mindset and practice in open source tends to be a \"hack it together\" mind set)."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2800#msg2800"},{"f":"TopSoil","d":1279111191,"b":[["q","There's a great talk by the CTO of Facebook available on Youtube, and I think he gave the right advice on scaling:\nDon't worry much about it until just before it becomes a problem.  Don't overengineer, because you're likely to waste time doing something that turns out to be irrelevant.","Quote"],["t","He is also talking about a website. The scalability issues with websites are well known and solved and can be easily tacked on as you get bigger. So yeah you don't need to worry about them when you start. bitcoin is a whole new beast.\n\nHaving a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.\n\nIt seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs..."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2812#msg2812"},{"f":"spaceshaker","d":1279116365,"b":[["q","Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system. And I think isn't necessary if you design the system right in the first place.","Quote from: TopSoil on July 14, 2010, 12:39:51 PM"],["t","It depends on how it was implemented. I don't think having transaction clearing houses necessarily excludes p2p. It depends on how the network was implemented. Assuming things remained open, the transaction clearing houses could still be p2p. Anybody could join in and work to clear transactions. It's just that it wouldn't be required in order to send/receive transactions. It would actually be extremely beneficial if there were literally thousands of transaction clearing houses or if some regular users did participate in the full system to prevent the established clearing houses from conspiring together to cheat the system. That is one of the beauties of bitcoin IMO."],["q","It seems like the best thing would be to lay the system on top of a DHT like kademlia. Maybe you can do this later I'm not sure. Again the documentation is lacking so it is hard to tell if you can easily break the chain apart in order to stick it in a DHT later. I was hoping the devs would stop by and answer maybe they are too busy improving the docs...","Quote from: TopSoil on July 14, 2010, 12:39:51 PM"],["t","Although DHT is an interesting concept I don't know if it really solves the problem. Smartphones are a good use case:\n\n• You don't want to be acting as a peer on a p2p network with a smartphone. It hurts battery life and it could be costly in cellular data charges.\n\n• Smartphones don't have the processing power or storage capacity to either process blocks or store even parts of the block chain.\n\nThe future is not desktop PCs but is \"thin\" machines like smartphones, tablets and netbooks. These lightweight devices will vastly out-number PCs in the years to come. It isn't tenable to participate in p2p from a thin device, at least in the forseeable future. I think Gavin's ideas of a lightweight bitcoin client seem to address this issue."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2830#msg2830"},{"f":"D҉ataWraith","d":1279121164,"b":[["q","Having a collection of servers that act as transaction clearing houses for people would probably work but it seems to break the whole p2p idea of the system.","Quote from: TopSoil on July 14, 2010, 12:39:51 PM"],["t","Why? E-Mail and Jabber <http://en.wikipedia.org/wiki/XMPP> work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).\n\nEdit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a supernode that then searches for files on your behalf."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2846#msg2846"},{"f":"TopSoil","d":1279123158,"b":[["q","Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).","Quote"],["t","Sure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation? What happens if some attackers start running a cluster of supernodes? The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement."],["q","Edit: Even more closely related: Kazaa and Gnutella work the same way, too. You connect to a supernode that then searches for files on your behalf.","Quote"],["t","Yeah and I would argue neither of those systems are very well designed. Limewire replaced the gnutella routing with Kademlia actually.\n\nspaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices. "]],"u":"https://bitcointalk.org/index.php?topic=286.msg2859#msg2859"},{"f":"Jman","d":1279123573,"b":[["t","Having to download the entire chain also causes issues with new user acceptance.  I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain.  As time goes on this is only going to get worse.  While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.\n\nSay your neighbor wanted to buy something with bitcoins.  You tell him to install the program, then go to the exchange and buy some coins.  Sounds great, right?  How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks?  Do you think he would recommend it to his friends?  To gain more widespread acceptance, initial transactions would need to overcome this factor."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2862#msg2862"},{"f":"knightmb","d":1279125284,"b":[["q","Having to download the entire chain also causes issues with new user acceptance.  I installed bitcoin on an older box I have and it took about 4 hours to download the entire chain.  As time goes on this is only going to get worse.  While this is a minor annoyance for most people here with fast connections and servers, if bitcoin were to actually get wider acceptance outside the tech circle it would be a deal breaker.\n\nSay your neighbor wanted to buy something with bitcoins.  You tell him to install the program, then go to the exchange and buy some coins.  Sounds great, right?  How do you think he will feel about the transaction when he has to wait 8 hours after installing the program to get his bitcoins because he has to download a chain with 200,000 blocks?  Do you think he would recommend it to his friends?  To gain more widespread acceptance, initial transactions would need to overcome this factor.","Quote from: Jman on July 14, 2010, 04:06:13 PM"],["t","I agree, I've been looking into packaging \"blocks\" for download so that you can install the client, unzip a fresh stack of blocks and let the client finish off the rest to get people up and running faster. I'm experimenting with Windows and Linux clients (don't have a Mac that can run the Mac client, sorry folks)\n\nHopefully that will help with the issue.\n\nOf course, the trust factor comes in (should I download these from this guy instead of letting the network do it for me)\n\n Wink"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2872#msg2872"},{"f":"D҉ataWraith","d":1279125736,"b":[["q","> Quote\n> Why? E-Mail and Jabber work the same way. Everyone can run their own server, and many do, but most users prefer to use someone else's server(s).\nSure it can work that way but is that the ideal? Doesn't that make the network less robust and more vulnerable to attacks and manipulation?","Quote from: TopSoil on July 14, 2010, 03:59:18 PM"],["t","Not really. If you're worried, you can always run your very own server."],["q","What happens if some attackers start running a cluster of supernodes?","Quote"],["t","Nothing. Unless you happen to use one of those supernodes, which you don't have to, because you can run your own supernode. Or use a trusted one, much like people trust Google with their E-Mail."],["q","The main point is why rely on this more vulnerable architecture when you don't have to? It isn't easier to implement.","Quote"],["t","It isn't easier to implement? I'd like to see some proof here.\n\nCounterexample: The totally distributed E-Mail system <http://www.epostmail.org/> developed at Rice University is a hell of a lot more complex than running a (network of) semi-centralized mail server(s)."],["q","spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.","Quote"],["t","Um. That's exactly what a supernode server would do."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2875#msg2875"},{"f":"knightmb","d":1279127542,"b":[["t","I've had luck with testing of packaging blocks into a zip file and dumping them on a new Bit Coin to speed up the block download process. I'll leave the link in my signature and if anyone finds it useful or time saving, feel free to donate.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=286.msg2884#msg2884"},{"f":"spaceshaker","d":1279129452,"b":[["q","> Quote\n> spaceshaker: yes I agree there will have to be nodes that act as proxies for mobile devices.\n\nUm. That's exactly what a supernode server would do.","Quote from: D҉ataWraith on July 14, 2010, 04:42:16 PM"],["t","Um. Sure. I think I've gone full circle. I think Gavin said it best:"],["q","A lightweight client would have a wallet with coins in it (public+private key pairs).\n\nAnd a secure way of sending messages to, and getting messages from, any of the ultra-fast, always-connected heavyweight nodes.\n\nThe lightweight client sends money by:\n  creating a transaction (signing coins with the private key)\n  sending the signed transaction securely to the ultra-fast server, which puts it on the network.\n  receiving confirmation that the transaction was valid and sent, and updating its wallet (marks coins as spent)\n   (or getting a \"you already spent those coins\" error from the server)\n\nThe lightweight client receives money by:\n  Either polling the server every once in a while, asking \"Any payments to these BC addresses that I have in my wallet?\"\n   ... or asking the server to tell it whenever it sees a transaction to a list of BC addresses (or maybe when it sees\n    a relevant transaction with N confirmations)\n  When transactions occur, the lightweight client updates its wallet (adds the coins).\n\nYou don't have to trust the server; it never has your private keys.\n\nWell, you do have to trust that the server doesn't lie about whether your transactions are valid or not, but why would the server lie about that?","Quote from: gavinandresen on July 14, 2010, 02:20:45 AM"],["t","In this scenario, the Bitcoin client could remain largely the same as it is today, although the focus would be that it is used on the \"super-nodes\" or \"transaction servers\" or \"proxy servers\" (these systems would probably serve all three roles) or by anyone wishing to play in that game. If the Bitcoin client was augmented to use DHT then that may be improvement but there is still a need for a \"lightweight client\" as Gavin described above. It seem's Gavin's \"lightweight client\" concept obviates my scalability concerns somewhat."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2888#msg2888"},{"f":"BitLex","d":1279129950,"b":[["q","> Quote from: spaceshaker on July 14, 2010, 01:52:00 AM\n> > Quote from: gavinandresen on July 14, 2010, 12:42:32 AM\n> > And I expect most of us will be running lightweight clients that just keep our wallets, sign transactions, and send and receive transactions to the ultra-fast nodes that ARE looking at every transaction.\n>\n> Is this possible? What would this look like? From a technical perspective what does a \"lightweight client\" look like for you? My understanding is that the Bitcoin client needs the entire block chain in order to establish trust.\nI'm imagining:\n....","Quote from: gavinandresen on July 14, 2010, 02:20:45 AM"],["t","you don't even have to imagine , actually it's already possible to \"remote-control\" the node, so just create ur own little lightweight-client, that just sends and gets some info to/from your (highspeed-connected, hdd-packed) homeserver.\n\nsome kind of \"managed server-client-version\" already exists in MyBitcoin, you could run something like that on your own webhost and connect to it from wherever u are on whatever connection-speed.\n\nthe \"lightweight client\" doesnt have to be one, but connect to it and tell it what todo.\nwe can do that with JSON."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2891#msg2891"},{"f":"InterArmaEnimSil","d":1279135430,"b":[["t","I second the DHT idea for maintaining a client list - we can't have millions of people relying upon an IRC channel, etc.  As far as the scaling issue goes, the issue is not at all HDD space, its network bandwidth.  Everyone is forgetting, its not bytes_per_transaction*transactions, which is the number everyone is using.  That number, as everyone has said, is fully manageable.  No, the number we're interested in is bytes_per_transaction * transactions * number_of_clients * total_hops_beyond_first_between_all_clients_combined\n\nTHIS is the amount of bandwidth which the protocol for BTC consumes as the network scales.  We're not just talking about sending one copy of each transaction to each client - we're talking about multiple clients broadcasting potentially redundant data to one another, and doing it across numerous hops, meaning numerous rebroadcasts.  Much larger number, much more difficult to handle.  However, it is manageable, just not in the current incarnation of network handling in the client.\n\nPerhaps in the \"popular\" phase, BTC chains could be broken up by region, similar to the purviews of domain name authorities now - and there could be an alternative protocol for transactions across these regional boundaries?  This would help the raw numbers of the problem, and also cut down on latency and related issues.  Not that I think this is an excellent solution - but P2P flooding across all active clients is obviously out barring some massive breakthrough in quantum computing or whatnot."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2921#msg2921"},{"f":"satoshi","d":1279141852,"b":[["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=286.msg2947#msg2947","s":1,"n":188,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/","qt":["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.","I 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.","At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN."],"qc":["nodes","scalability"]}]},{"id":"p86","k":"p","s":"bitcointalk","t":"Flood attack 0.00000001 BC","u":"https://bitcointalk.org/index.php?topic=287","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/86/","m":[{"f":"Mionione","d":1278936264,"b":[["t","hi, what would happen if someone sends millions of 0.00000001 BC to millions of address please ?\n\n=> all of the networks peers must store all transactions ?\n=> are each 0.00000001 owner/hash stocked in blocks on all peers?\n\ni don't really understand how bitcoin handle fractions of bc"]],"u":"https://bitcointalk.org/index.php?topic=287.msg2293#msg2293"},{"f":"Gavin Andresen","d":1278936525,"b":[["t","From the source code:"],["c","main.h:        // To limit dust spam, require a 0.01 fee if any output is less than 0.01"]],"u":"https://bitcointalk.org/index.php?topic=287.msg2295#msg2295"},{"f":"llama","d":1278944626,"b":[["t","Hmm, I didn't realize that was in there, and I really don't like that approach.\n\nThat pretty much ruins the possibility of using bitcoin for true micropayments.  Wouldn't it be better for clients to just ignore a spammy IP?  Sure an attacker could get more, but he couldn't get millions."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2314#msg2314"},{"f":"Gavin Andresen","d":1278945954,"b":[["t","But how would you distinguish between a legitimate micropayment-processing IP and a spammy \"I want to make Bitcoin use so much bandwidth nobody is willing to run it any more\" IP?\n\nReally small micropayments seem to me to be a really hard problem, and I don't think Bitcoin should try to solve too many very hard problems all at once."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2319#msg2319"},{"f":"llama","d":1278946571,"b":[["t","Gavin,\n\nIt's simple.  You will need a fixed component transaction fee, but it will probably be much smaller than that.  The fixed component should reflect the true cost to the network of running the transaction.  So, the additional bandwidth, latency, etc that the transaction actually costs the network.\n\nChances are, this will be tiny.  I'd guess something like 0.00001 BC, even at the current exchange rate."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2322#msg2322"},{"f":"Mionione","d":1278947144,"b":[["t","if i send many 0.00000001 BC using a friend node that take no fee (or that send fee back to me).\n\nWill the friend node spead all the transactions over the network?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg2327#msg2327"},{"f":"Gavin Andresen","d":1278948151,"b":[["q","if i send many 0.00000001 BC using a friend node that take no fee (or that send fee back to me).\n\nWill the friend node spread all the transactions over the network?","Quote from: Mionione on July 12, 2010, 03:05:44 PM"],["t","The fee is paid to whoever generates the block that the transactions are in, and that's random.\n\nYour friend could run a node that refunds the fee, but unless your friend can convince a lot of other people to run nodes that do the same thing you're almost certainly going to end up paying the fee.\n\nRemember that all transactions (even payments from you to your friend) are broadcast across the payment network; they HAVE to be, because if they weren't you could spend the same coins twice without getting caught."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2328#msg2328"},{"f":"Mionione","d":1278949204,"b":[["t","so the fee must be the same for all nodes isn't it ?\n\ndo the nodes reject other nodes that doesn't apply the same fee?\n\nif not, there is no way to wait/find a node that apply a lower fee?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg2329#msg2329"},{"f":"laszlo","d":1278953459,"b":[["t","You can send a billion small transactions, it doesn't slow anything down, except the user interface because you end up with a ton of items in the list.  Just go ahead and try it, see for yourself.\n\nAll of the transactions are included by nodes that are attempting to generate the next block and only the header is hashed so it is not harder to generate a block that represents a million transactions than it is to generate a simple coinbase only.  This is what the confirmations are, blocks that include your transaction."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2342#msg2342"},{"f":"bencoder","d":1278972651,"b":[["t","I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.\n\nIf there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2399#msg2399"},{"f":"lachesis","d":1278972890,"b":[["t","I think a 0.01 BTC minimum send is fine for now. At the current exchange rate, that's 8/1000 of a penny USD, or 80 millionths of a dollar. Any micropayment smaller than that would not be made one at a time. If, for example, you wanted to charge 0.001BTC for something, you could just charge 0.01 and keep a balance.\n\nIf bitcoins become much more valuable, we can change this and push out a new version."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2400#msg2400"},{"f":"knightmb","d":1278973820,"b":[["q","I guess the worry here is that it's possible that bitcoins could end up being worth a lot more than they are today. For example, if 0.01 BTC works out to be the equivalent of $1 today, then that built-in 0.01 transaction fee is far too high.\n\nIf there is some way to make the transaction fee scale with the worth of the currency that would be best, but I can't think even conceptually how that could be possible. It's not like the currency has any idea how much it is worth in real terms.","Quote from: bencoder on July 12, 2010, 10:10:51 PM"],["t","Ideally, you raise the ceiling in this situation. Right now, there is a 21 million coin limit. So as the value goes up, so does the ceiling so to speak. Unless one person has 20 million bitcoins and the rest of the world has to trade with 1 million, there should be no reason go in the opposite direction for the value to value comparison. But I do understand exactly what you mean though because some world currency is traded like that where 1 unit of XYZ country equals 20,000 of another, so small decimal values have to be used.\n\nSince the transaction fee can't get below 0.01, the value should always be greater than the fee, otherwise, people are not making any financial sense. It would be like living in a city where it cost $10.00 to drink from a water fountain. The business model should fail in light of free, public water fountains outside, so who would bother to pay that much money when the alternative makes more financial sense.\n\nSame way with the 0.01 fee limit, people already expect it and won't value things beneath it as it wouldn't make financial sense.  If the lowest possible fee is 0.01, why would anyone sell anything for less than that? You would put yourself out of business quickly."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2407#msg2407"},{"f":"AndrewBuck","d":1279131941,"b":[["t","If I understand the workings of the system correctly, clients on the network are broadcast the details on the new transactions coming in.  If a given client is generating they take any transactions they have seen come into them, bundle them into a \"trial block\" (along with a new 50 BTC token for themselves) and then commence trying to find a nonce which hashes this block to something below the target value.\n\nSince blocks with more transactions in them will take longer to hash, the flood of small payments would  make the client work harder before it solves a block.  What if we change the transaction format from the current \"123 wants to send X coins to 456\", to be something like \"123 wants to send X coins to 456 and will pay Y coins to whomever solves the block containing this transaction\".\n\nThen each client sets their own minimum transaction fee (which defaults to 0).  If they receive new transaction from someone, they check that the fee is greater than or equal to their own minimum transaction fee.  If the fee is high enough they will add the transaction to the pool of transactions they are trying to find a solution for.  If not, they will just ignore the update (still forwarding it on to others though so the network still functions).  When they add the transaction they will really add it as 2 parts, the X coins from 123 to 456, and a second transaction of 123 to themself.\n\nThis allows for the creation of a \"processing market\" and allows the fee to be set by the market itself.  Some people will be willing to solve blocks for free and will include any transaction they are sent.  Other clients will set a very high fee and only try to solve the few that meet this fee.  In this way transactions with higher fees get \"priority\" processing since they will be included in more nodes calculations.  People who don't want to pay a transaction fee can still put packets out and they will eventually be solved but will take longer because some nodes won't work on them.\n\nThis allows the transaction fee to move up and down with the value of bitcoins and it also gives people an incentive to keep running the program after new blocks are not generating bitcoins (as they will be 20 years from now).\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=287.msg2904#msg2904"},{"f":"Insti","d":1279132291,"b":[["q","Since blocks with more transactions in them will take longer to hash, the flood of small payments would  make the client work harder before it solves a block.  ","Quote from: AndrewBuck on July 14, 2010, 06:25:41 PM"],["t","This is not quite right.  The block header that is being hashed is a constant size no matter how many transactions the block contains.\nSo blocks with more transactions in them should still take the same amount of time to hash.\n\nThe rest is correct and insightful though."]],"u":"https://bitcointalk.org/index.php?topic=287.msg2905#msg2905"},{"f":"mizerydearia","d":1279172467,"b":[["q","From the source code:\n\nmain.h:        // To limit dust spam, require a 0.01 fee if any output is less than 0.01","Quote from: gavinandresen on July 12, 2010, 12:08:45 PM"],["t","I added this little tidbit into my IRC bot:\n\nAccording to http://is.gd/dsqcH the world population is 6,855,986,675. If everyone had the same amount of bitcoins, everyone would have 0.00306302 bitcoins.  If 0.00000001 bitcoins were equivalent to US$0.01, then everyone would have equivalent of US$3,063.01645489 and the value of all bitcoins would be equivalent of US$21,000,000,000,000.00.\n\nHow would the BTC0.01 fee affect things considering above?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg3098#msg3098"},{"f":"lachesis","d":1279172901,"b":[["t","By the time everyone has Bitcoins, the fee will have been removed or adjusted."]],"u":"https://bitcointalk.org/index.php?topic=287.msg3100#msg3100"},{"f":"melvster","d":1279720664,"b":[["q","From the source code:\n\nmain.h:        // To limit dust spam, require a 0.01 fee if any output is less than 0.01","Quote from: gavinandresen on July 12, 2010, 12:08:45 PM"],["t","Would love to see this value at 0.001 rather than 0.01"]],"u":"https://bitcointalk.org/index.php?topic=287.msg4728#msg4728"},{"f":"BeeCee1","d":1279846588,"b":[["t","What would happen if someone modified their client to not offer to pay the fee, and also modified their client to not require the fee?\n\nHere's my best guess:\n* They generate a 0.00000001 BC payment (but don't include the fee)\n* This transaction goes to the clients peers\n* The peers don't include it in the block they are solving since fee not paid.\n* Do the peers still pass the transaction along to the rest of the network?\n* A block gets solved without the transaction in it\n* client notices its transaction wasn't in the block and re-broadcasts the transaction?\n* eventually client solves a block itself and that transaction is included in it so it goes out to the rest of the network"]],"u":"https://bitcointalk.org/index.php?topic=287.msg5168#msg5168"},{"f":"nenolod","d":1279861380,"b":[["q","That pretty much ruins the possibility of using bitcoin for true micropayments. ","Quote from: llama on July 12, 2010, 02:23:46 PM"],["t","I do not see how it does that.  1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments."]],"u":"https://bitcointalk.org/index.php?topic=287.msg5200#msg5200"},{"f":"Red","d":1279862639,"b":[["t","Does paying the \"fee\" require the use of the \"pay to anyone\" signature I read about in another thread?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg5203#msg5203"},{"f":"throughput","d":1279892381,"b":[["t","Hi."],["q","> Quote from: llama on July 12, 2010, 02:23:46 PM\n> That pretty much ruins the possibility of using bitcoin for true micropayments. \n\nI do not see how it does that.  1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.","Quote from: nenolod on July 23, 2010, 05:03:00 AM"],["t","Micropayment is less that 0.01 $, I suppose.\nHaving an (economically) effective implementation of micropayment system will affect the way current economics works.\nFor example, it may make the media producer's business unprofitable in some areas, I suppose.\n\nSo, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.\nBut that system still does not exists Sad"]],"u":"https://bitcointalk.org/index.php?topic=287.msg5270#msg5270"},{"f":"melvster","d":1279895532,"b":[["q","Hi.\n\n> Quote from: nenolod on July 23, 2010, 05:03:00 AM\n> > Quote from: llama on July 12, 2010, 02:23:46 PM\n> > That pretty much ruins the possibility of using bitcoin for true micropayments. \n>\n> I do not see how it does that.  1 BTC will likely always be smaller than USD/EUR/etc, thus meaning that it can be used for micropayments.\n\nMicropayment is less that 0.01 $, I suppose.\nHaving an (economically) effective implementation of micropayment system will affect the way current economics works.\nFor example, it may make the media producer's business unprofitable in some areas, I suppose.\n\nSo, the economics may be interested in payments with less that 0.001 $ volume and with more than millions transaction per day numbers.\nBut that system still does not exists Sad","Quote from: throughput on July 23, 2010, 01:39:41 PM"],["t","You can do it if you have a system of micropayments with the CASH OUT in bitcoins.  That way most transactions will not go through the bitcoin system."]],"u":"https://bitcointalk.org/index.php?topic=287.msg5279#msg5279"},{"f":"llama","d":1280898895,"b":[["t","I think it's very important that the transaction fee reflect no more than the true cost that the transaction causes the network.\n\nMicropayments can be useful even if they're very very tiny.  Imagine a lightbulb that sends a little ping bitcoin charge for every millisecond it's turned on.  There are countless applications for tiny tiny payments."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7437#msg7437"},{"f":"bytemaster","d":1280902976,"b":[["t","Well, right now nothing stops someone from creating a system where:\n\nA sends  1.00000001 to B\nB sends  1.00000000 back to A\n\nNet result is a micro-payment and no processing fee.  I am creating a system that does something very similar to the above.   The reality is that any \"micro-payment\" system should probably be handled outside the BTC block and have the payments \"summed up\" before being sent. \n\nI think the processing fee design is brilliant.  Every node can pick and choose which transactions it wants to include and thus the \"time until included\" is directly proportional to the number of nodes who accept your \"offer\".  Worst case you have to wait until your lonely PC can create a block which at the moment could be weeks!\n\nIn fact, I think it would be reasonable to offer to pay the nodes that propagate your transaction if there was some way to \"enforce it\" and prevent rouge clients from collecting fees but not doing work. "]],"u":"https://bitcointalk.org/index.php?topic=287.msg7443#msg7443"},{"f":"Gavin Andresen","d":1280923138,"b":[["q","Well, right now nothing stops someone from creating a system where:\n\nA sends  1.00000001 to B\nB sends  1.00000000 back to A\n\nNet result is a micro-payment and no processing fee.","Quote from: bytemaster on August 04, 2010, 06:22:56 AM"],["t","... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001)."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7454#msg7454"},{"f":"Insti","d":1280924220,"b":[["q","... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).","Quote from: gavinandresen on August 04, 2010, 11:58:58 AM"],["t","Surely this is not correct?\n\nThe 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7456#msg7456"},{"f":"Gavin Andresen","d":1280926559,"b":[["q","The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.","Quote from: Insti on August 04, 2010, 12:17:00 PM"],["t","The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":"],["c","main.h:\nforeach(const CTxOut& txout, vout)\n  if (txout.nValue < CENT)\n    nMinFee = CENT;"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7459#msg7459"},{"f":"Insti","d":1280927058,"b":[["q","The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":","Quote from: gavinandresen on August 04, 2010, 12:55:59 PM"],["t","Since there is no way to tell which is the 'change' transaction.\nThat's kinda cool.\n (and somewhat horrible at the same time.)"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7460#msg7460"},{"f":"bytemaster","d":1280929235,"b":[["q","> Quote from: Insti on August 04, 2010, 12:17:00 PM\n> The 1 BTC transaction is a transaction with 1 input and 2 outputs, but it's still only 1 transaction.\nThe rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":\n\nmain.h:\nforeach(const CTxOut& txout, vout)\n  if (txout.nValue < CENT)\n    nMinFee = CENT;","Quote from: gavinandresen on August 04, 2010, 12:55:59 PM"],["t","Wow, ok this needs to go or it becomes impossible to do micropayment systems.    For example, I am trying to build an automated system you \"pay per packet\" sent across a P2P network.  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.   I suppose that I would have to release the P2P program with its own BTC client that does not have this rule.  It would take longer for transactions to post, but in theory if all clients are mining then you would still have a good chance of getting the payment in."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7468#msg7468"},{"f":"Insti","d":1280933911,"b":[["t","What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?\nIt seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.\n\nI'm not aware that the network is straining under the weight of the existing transaction volume.\nAnyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7498#msg7498"},{"f":"knightmb","d":1280934122,"b":[["q","What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?\nIt seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.\n\nI'm not aware that the network is straining under the weight of the existing transaction volume.\nAnyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.","Quote from: Insti on August 04, 2010, 02:58:31 PM"],["t","There are builds that remove this limit, mainly for testing right now, I think that's why it's disabled until it can be tweaked a little more."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7500#msg7500"},{"f":"theymos","d":1280936636,"b":[["q","What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?\nIt seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.\n\nI'm not aware that the network is straining under the weight of the existing transaction volume.\nAnyone wishing to send a lot of transactions can already do this by sending x BTC to themselves a lot.","Quote from: Insti on August 04, 2010, 02:58:31 PM"],["t","Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.\n\nA better solution would be to deprioritize transactions below 0.01 and completely drop them if there are more than 10,000 (or whatever) in the queue. Then these transactions would be slower and less reliable than other transactions, but they would work and not interfere with \"real\" transactions."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7516#msg7516"},{"f":"bytemaster","d":1280937249,"b":[["t","priority is all contingent upon how many nodes accept them.  Thus if only 1% of the nodes accept a transaction fee of 0.000001 btc then you will have a 1% chance of being included in the next block.  If all nodes accept transaction fees of 1BTC then you have near 100% chance of being in the next block. "]],"u":"https://bitcointalk.org/index.php?topic=287.msg7518#msg7518"},{"f":"Insti","d":1280938315,"b":[["q","> Quote from: Insti on August 04, 2010, 02:58:31 PM\n> What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?\nSomeone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.","Quote from: theymos on August 04, 2010, 03:43:56 PM"],["t","Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7521#msg7521"},{"f":"satoshi","d":1280939136,"b":[["q","It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.","Quote from: Insti on August 04, 2010, 02:58:31 PM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7524#msg7524","s":1,"n":317,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/317/","qt":["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."],"qc":["micropayments"]},{"f":"Insti","d":1280939604,"b":[["q","> Quote from: Insti on August 04, 2010, 02:58:31 PM\n> It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.\nBitcoin isn't practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, certainly 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.\n\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.","Quote from: satoshi on August 04, 2010, 04:25:36 PM"],["t","Why not?\nI don't see how size would make a difference.\nIs it just due to the number of transactions that the system is able to handle?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7525#msg7525"},{"f":"Insti","d":1280942573,"b":[["q","User sends you 1.005 bc's, you send them back 1. Is a fee charged in that scenario? Because the change coming back to you would be .005?","Quote from: davidonpda on August 04, 2010, 05:03:23 PM"],["t","Yes, this was covered above."],["q","The rule is \"if any TxOut (output) has a value of less than 0.01 bitcoins, charge a 0.01 fee\":\n\nmain.h:\nforeach(const CTxOut& txout, vout)\n  if (txout.nValue < CENT)\n    nMinFee = CENT;","Quote from: gavinandresen on August 04, 2010, 12:55:59 PM"],["t","In your scenario there are two outputs, 1 is 1 BTC and the other is 0.005 BTC.\n0.005 < 0.01 therefore a fee applies to the transaction."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7537#msg7537"},{"f":"FreeMoney","d":1280950232,"b":[["t","Can the fee rules be arbitrarily complicated? And is the size limit hard wired or completely up to the node?\n\nDoes including more slow down your hashing rate?  "]],"u":"https://bitcointalk.org/index.php?topic=287.msg7569#msg7569"},{"f":"lfm","d":1281019952,"b":[["q","> Quote from: Insti on August 04, 2010, 04:11:55 PM\n> > Quote from: theymos on August 04, 2010, 03:43:56 PM\n> > > Quote from: Insti on August 04, 2010, 02:58:31 PM\n> > > What exactly is this 'dust spam' that this 0.01BTC transaction fee \"solving\"?\n> > Someone with only one Bitcoin could send 100,000,000 transactions, which might overload the network. This isn't a good solution, though -- the vulnerability will still exist when the limit is lowered because someone will certainly be saving a bunch of Bitcoins.\n>\n> Someone with one Bitcoin can already send 100,000,000 transactions, by repeatedly sending the coin to themselves. How is it any different if the value of the transaction is 1 or 0.00000001 ?\n\nI'd like to repeat that question. Why could someone with 1 bc, not just send it back and forth between accounts a billion times? No fees would be charged.","Quote from: davidonpda on August 04, 2010, 05:02:14 PM"],["t","Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.\n\nOnly if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7674#msg7674"},{"f":"lfm","d":1281020391,"b":[["q","> Quote from: bytemaster on August 04, 2010, 06:22:56 AM\n> Well, right now nothing stops someone from creating a system where:\n>\n> A sends  1.00000001 to B\n> B sends  1.00000000 back to A\n>\n> Net result is a micro-payment and no processing fee.\n\n... unless B started with zero bitcoins.  Then B is stuck; she can't send 1.0 back, because doing that would cause a 0.00000001 bitcoin 'change' transaction, which would trigger the 0.01BTC fee, which they can't pay (because they only have 1.0000000001).","Quote from: gavinandresen on August 04, 2010, 11:58:58 AM"],["t","ok if a and b both start out with 1 BTC and agree to transfer 0.0001 using two inputs and two outputs on a single transaction can change a to 0.9999 and b to 1.0001. The rest of the network it would seem would accept the transaction.\n\nThe only stumbling block is whoever creates the transaction needs the private keys for both inputs which would come from different wallets normally. The one who creates the transaction could cheat."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7675#msg7675"},{"f":"lachesis","d":1281021070,"b":[["q","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.\n\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.","Quote from: satoshi on August 04, 2010, 04:25:36 PM"],["t","Why isn't it practical? I agree that a good micropayment system would avoid generating thousands of transactions (e.g. one per packet), but that doesn't mean that bytemaster's change idea is wrong:"],["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.","Quote from: bytemaster"],["t","That seems like a great use case. Furthermore, as llama said, the fixed component of a transaction fee should always represent the real cost of including that transaction in a block. So, are there any more intelligent and less painful ways of implementing anti-dust spam systems?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7677#msg7677"},{"f":"bytemaster","d":1281022759,"b":[["t","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.  \n\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.\n\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.  \n\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.\n\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.  \n\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.  \n\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.\n\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.  \n\n  "]],"u":"https://bitcointalk.org/index.php?topic=287.msg7684#msg7684"},{"f":"satoshi","d":1281024201,"b":[["t","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.\n\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.)\n\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.\n\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."],["q","Does including more slow down your hashing rate?  ","Quote from: FreeMoney on August 04, 2010, 07:30:32 PM"],["t","No, not at all."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7687#msg7687","s":1,"n":318,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/318/","qt":["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."],"qc":["micropayments"]},{"f":"satoshi","d":1281025820,"b":[["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.","Quote from: bytemaster"],["t","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.\n\nOr you could pay per day.  The first time you access the site on a given day, you pay for 24 hours of access.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7694#msg7694","s":1,"n":319,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/319/"},{"f":"Anonymous","d":1281026273,"b":[["q","Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.\n\nOnly if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.","Quote from: lfm on August 05, 2010, 02:52:32 PM"],["t","Improved attack would be : start with 1BTC then transfer 0.999999999BTC, then 0.999999998BTC, ...\nIt results 1 million accounts (minus 10000) with 0.000000001BTC each."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7695#msg7695"},{"f":"satoshi","d":1281026398,"b":[["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.  ","Quote from: bytemaster on August 05, 2010, 03:39:19 PM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7696#msg7696","s":1,"n":320,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/320/"},{"f":"ByteCoin","d":1281026758,"b":[["q","If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?","Quote from: satoshi on August 05, 2010, 04:39:58 PM"],["t","The transaction fee transaction would be designed to be a completely predictable consequence of the main transaction and hopefully any fee for processing the main transaction would also take into account the need for a fee transaction too. In other words the fee transaction would contain its own fee. This therefore seems to be a manageable aspect of the problem.\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7698#msg7698"},{"f":"bytemaster","d":1281026812,"b":[["t","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.  \n\nIf the transmit fee <= block integration fee no one could profitably forward the transaction and thus must generate a block themselves. "]],"u":"https://bitcointalk.org/index.php?topic=287.msg7699#msg7699"},{"f":"satoshi","d":1281030583,"b":[["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.  ","Quote from: bytemaster on August 05, 2010, 04:46:52 PM"],["t","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?\n\nThe way it is now, it's whoever builds this gets it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7710#msg7710","s":1,"n":324,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/324/"},{"f":"bytemaster","d":1281031922,"b":[["t","The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction.  In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway.  The tip would be below the amount that would allow said user to \"rebroadcast\" their transmit fee.  So you don't get recursive transmit fees. \n\nSay I want to send .001 BTC to Fred.   The cluster is operating at 1billion k/hash/second, then I need to distribute my transactions to enough nodes so that the k/hash/second % of the total is acceptably high for the transaction to get logged within the next N blocks.   \n\nSo generating nodes A, B, and C each price their transmit fee proportional to their khash rate.  (how do they prove their khash rate?  total blocks generated over time?)\n\nSo I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.   I send a different one to B and C.   \n\nNow A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.\n\nThe trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7713#msg7713"},{"f":"knightmb","d":1281037382,"b":[["q","Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.\n\nOnly if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.","Quote from: lfm on August 05, 2010, 02:52:32 PM"],["t","Does sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?\nCan the line be moved down slightly? Any bad side-effects if it was?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg7727#msg7727"},{"f":"Gavin Andresen","d":1281054769,"b":[["q","So I send a transaction of .001 BTC from me to Fred and .000001 BTC from me to A.   I send a different one to B and C.   \n\nNow A, B, and C cannot make a profit by sending that transaction for anyone else to crunch on so if they want to collect they have to process it.\n\nThe trick is enforcing the rule that 0.001 only flows from me to fred once and not in each block.","Quote from: bytemaster on August 05, 2010, 06:12:02 PM"],["t","I'm thoroughly confused on what, exactly, you're proposing.\n\nI want to make a 100 Bitcoin transaction to you.\n\nYou're proposing that I need to pay a \"transmit fee\" ... which is paid to who and does what, exactly?\n\nIf I pay it to A, B, and C, does that mean they rebroadcast the transaction to everybody they're connected to?  Do they, in turn, pay transmit fees to the nodes they're rebroadcast it to?  What stops them from saying \"Thank you very much for the transmit fee\" and cheating (drop my transaction on the floor)?\n\nSatoshi's proposal that all transaction carry a minimum fee to cover network overhead makes sense; whoever generates the block with the transaction gets the fee."]],"u":"https://bitcointalk.org/index.php?topic=287.msg7761#msg7761"},{"f":"lfm","d":1281159373,"b":[["q","> Quote from: lfm on August 05, 2010, 02:52:32 PM\n> Sending 1 BTC back and forth a million times creates a single transaction chain, sending a million transactions of 0.000001 BTC makes a million nearly independant transactions which all must be remembered. Due to the way bitcoin can drop old deeply confirmed transactions the first is far less overhead than the second in the long run. There may be similar network cost but the disk space cost can be greatly reduced for the single chain.\n>\n> Only if the \"dust\" is combined back together and confirmed deeply enough again only then can the dust space be dropped.\nDoes sending 0.1 BTC a million times also create a single transaction? Where is the line when it goes from a single transaction to independent transactions?\nCan the line be moved down slightly? Any bad side-effects if it was?","Quote from: knightmb on August 05, 2010, 07:43:02 PM"],["t","I don't think you understood, it's nothing to do with the size of the transaction. it's the way transactions get split up. If you start with 1 BTC and send 100 x 0.01 transactions to your friend thats 100 transaction chains one step long. He may or may not combine them back together into a single 1BTC transaction but untill he does the net must keep all 100 transactions stored.\n\nIf you start with the same 1BTC or 0.01BTC or any single amount and pass it back and forth to your friend 100 times. Its a similar amount of traffic and storage at first but once the last one gets deeply confirmed (ie 6 blocks/1 hr later) you can forget/delete from your disk database all the transactions but the last one. It's the Merkle hash tree pruning stuff in the white paper."]],"u":"https://bitcointalk.org/index.php?topic=287.msg8056#msg8056"},{"f":"Insti","d":1281345522,"b":[["t","Are:\n1) The transaction fees charged entirely up  to the block processing node?\nOr\n2) The transaction fees enforced by the network, which would mean that any block that contains an 'invalid' transaction because it did not include the correct fee would be rejected?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg8338#msg8338"},{"f":"throughput","d":1281435210,"b":[["t","Does that mean, that my abilities to DDoS the entire Bitcoin network are only limited by my BTC\nbying power? And not by the number of my network connections, nodes, etc?\n\nBTW, let's test the network someday?\nIt is trivial to automate the process of sending small transactions to the list of known addresses.\nLet's abuse the network and know the effect precisely.\n\nI suppose, we should caution the other users..."]],"u":"https://bitcointalk.org/index.php?topic=287.msg8508#msg8508"},{"f":"Insti","d":1281452021,"b":[["q","BTW, let's test the network someday?\nIt is trivial to automate the process of sending small transactions to the list of known addresses.\nLet's abuse the network and know the effect precisely.\n\nI suppose, we should caution the other users...","Quote from: throughput on August 10, 2010, 10:13:30 AM"],["t","You should use the Test network <http://bitcointalk.org/index.php?topic=363.0>"]],"u":"https://bitcointalk.org/index.php?topic=287.msg8541#msg8541"},{"f":"throughput","d":1281512243,"b":[["q","> Quote from: throughput on August 10, 2010, 10:13:30 AM\n> BTW, let's test the network someday?\n> It is trivial to automate the process of sending small transactions to the list of known addresses.\n> Let's abuse the network and know the effect precisely.\n>\n> I suppose, we should caution the other users...\n\nYou should use the Test network <http://bitcointalk.org/index.php?topic=363.0>","Quote from: Insti on August 10, 2010, 02:53:41 PM"],["t","Test network have test scale.\n\nHmm, I think the other guys may not ask your permission to abuse the real network next time.\nThey will just do it.\n\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  Grin\n\nPerhaps somebody just experimented already?"]],"u":"https://bitcointalk.org/index.php?topic=287.msg8697#msg8697"},{"f":"satoshi","d":1281569330,"b":[["t","It would be nice to keep the blk*.dat files small as long as we can.\n\nThe eventual solution will be to not care how big it gets.\n\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.\n\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.\n\nScale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance."]],"u":"https://bitcointalk.org/index.php?topic=287.msg8810#msg8810","s":1,"n":345,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/345/"}]},{"id":"p87","k":"p","s":"bitcointalk","t":"Warning this block was not received by any other nodes","u":"https://bitcointalk.org/index.php?topic=291","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/87/","m":[{"f":"hubdawg","d":1278946020,"b":[["t","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?\n\nBC: 1KDwVb4udipVSYLgRPWg9GiFiKJpXBFPHg"]],"u":"https://bitcointalk.org/index.php?topic=291.msg2320#msg2320"},{"f":"SmokeTooMuch","d":1278951502,"b":[["t","Does it really say, that the bitcoins could not get received or does it say the transaction is still unconfirmed ?\n\nDon't worry about the second case, it just means that the bitcoins have to get confirmed by the other nodes.\nThis happened after 120 blocks in the old bitcoin version (0.2). I`m not sure about the amount of block on 0.3.\n\nIf they really couldn't get received I can't give you an advice, this is above my knowledge, but I'm sure the other forum members are able to help you with that Smiley"]],"u":"https://bitcointalk.org/index.php?topic=291.msg2335#msg2335"},{"f":"hubdawg","d":1278951664,"b":[["t","Well I restarted the computer and the logs are now cleared.  My connection count is low at the moment.  I have 11 connections.  About an hour after I installed it yesterday I had around 40 connections.  I am not sure what is happening.  I wonder if my isp is blocking the traffic.  If it looks like bittorrent traffic they may be blocking it.  I am so fed up with isp thinking they can control what I do on the internet."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2336#msg2336"},{"f":"laszlo","d":1278952859,"b":[["t","It is normal for some blocks not to be accepted.  One connection is enough, the others are just redundant.  The client will make 8 outbound connections but will accept all inbound connections (on port 8333).\n\nThe blocks are generated in sequence so if two nodes happen to generate at almost the same time there will be a collision and one or the other will win.  If the current block count is 5000 and your node finds a suitable block 5001, but meanwhile some other node already created a 5001 and your node just didn't know because it's on a laggy connection possibly, your block won't be valid and you have to start searching for 5002.  I think this is explained in the pdfs, I'm not sure.\n\nAre you seeing a lot of these happen or was it just one?"]],"u":"https://bitcointalk.org/index.php?topic=291.msg2339#msg2339"},{"f":"laszlo","d":1278952929,"b":[["t","Sorry I misread, it's possible that you just weren't connected properly and it couldn't broadcast a transaction, what was the exact wording of the message?  Can you include a screen shot?  I might have been describing a different problem than you were having especially if it cleared up after restarting.."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2340#msg2340"},{"f":"hubdawg","d":1278953246,"b":[["t","It had 5 in a row... saying Warning: This block was not received by any other nodes.   I did not get a screen shot I should have though.  I will keep an eye on it.  If it happens again I will get the SS and post it in this thread.  I am concerned though if this app generates bittorrent type traffic my isp may be interfering with it."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2341#msg2341"},{"f":"laszlo","d":1278953685,"b":[["t","You could try using tor maybe and see if that works better, though it will increase your latency even more."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2343#msg2343"},{"f":"lachesis","d":1278971510,"b":[["t","This kind of error has only happened to me once, but I'm on a low latency connection at my Uni. Typically it occurs, like Laszlo said, when another node solves the next block and you don't receive it before you transmit your own connection.\n\nIt could be due to a whole number of things, but a bad internet connection is probably the first thing to look at."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2396#msg2396"},{"f":"theymos","d":1278972997,"b":[["t","Since it's happening so frequently (you shouldn't get more than two generations per day normally with the current difficulty), you probably haven't downloaded the entire block chain. There are 66145 blocks as I write this; how many do you have (lower right in BitCoin's UI)?\n\nIf you're running Microsoft Security Essentials, you need to add BitCoin as an exception for blocks to be downloaded at a reasonable speed."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2402#msg2402"},{"f":"ksd5","d":1278988075,"b":[["t","My friend got the same error. He has about 1600 khash/s, 48 connections, but only 3 blocks. "]],"u":"https://bitcointalk.org/index.php?topic=291.msg2460#msg2460"},{"f":"hubdawg","d":1278991782,"b":[["t","I am at the moment at  1046 khash/s   12 connections  66331 blocks.   I am on 10mb Newwave cable in west kentucky.  My internet is very fast pretty much all the time.   I average good speeds.   Still waiting to see if I get those errors again."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2471#msg2471"},{"f":"laszlo","d":1278993757,"b":[["t","Basically anything that's generated while the node doesn't have all the blocks just ends up being rejected because it would fall in the middle of the block chain not at the end (but your node thought it was at the end because it didn't know there were a lot more blocks).  The blocks are small but it takes a while for your computer to validate each one so that's why the initial download takes a while.  I'm not exactly sure why it's taking so long for some people, maybe it's because the database is flushed to disk constantly and some kind of antivirus is scanning every file write, but it takes about 10 minutes for me to get it all back if I remove my data directory."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2482#msg2482"},{"f":"hubdawg","d":1278994107,"b":[["t","The only antivirus I use is  Microsoft security essentials.  I don't know if that is any help.  I am running  a Core2Duo 3ghz  with 2gb of ram on Windows 7 64bit.  Just a few of my stats."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2485#msg2485"},{"f":"laszlo","d":1278994757,"b":[["t","Would be interesting to see if you get better results without it - someone else reported trouble with that until they added an exception for the %APPDATA%/Bitcoin directory."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2487#msg2487"},{"f":"hubdawg","d":1278994936,"b":[["t","I did add an exception for it as I noticed someone else had in the forum."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2490#msg2490"},{"f":"dkaparis","d":1279057953,"b":[["t","Make sure you add bitcoin.exe to the \"Excluded processes\" list, not only files for scanning.\n\nSee this thread: http://bitcointalk.org/index.php?topic=35.0\n\nI submitted bitcoin to the MS Security Essentials developers back then with explanation of the problem. They responded they would check the performance concerns, but I don't know what they've made of it."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2661#msg2661"},{"f":"hubdawg","d":1279119118,"b":[["t","Okay I am not sure if I should add this here.  But It has been a bit over three days since I installed and have had bitcoin running 24hrs a day.  The first day in under 15hours it had generated some progress and sent out the 5 failed transactions. Now it has been approximately 72 hours.  There has been no activity at all.  My client reports that it is working on the current block as noted by the page someone here setup to show the length of the current computations.  Is this common can it take days and weeks to generate even one bitcoin.  I am not a programmer at all. I read the whitepaper and other stuff but much of it just evades me."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2837#msg2837"},{"f":"BitLex","d":1279123052,"b":[["t","u can't generate just 1coin,\nu'll get 50coins for completing 1block, or you dont get them if someone else was quicker.\n\na few days ago i was able to generate 50coins in less than a day, but the difficulty to create a block tripled since slashdot and so did the time to generate coins.\n\nso yes, its pretty usual to take \"forever\" to generate a coin, at least expect it to take a few days, to get your first 50coins,\ndepending on how much cpu-power u'v got to spare."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2858#msg2858"},{"f":"satoshi","d":1279133789,"b":[["t","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.\n\nYou need to make bitcoin.exe an excluded process in Live Protection.\n\nThis is becoming a common problem.  Someone should write this up in a pegged thread.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=291.msg2913#msg2913","s":1,"n":186,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/186/"}]},{"id":"p88","k":"p","s":"bitcointalk","t":"Donations to freebitcoins.appspot.com needed!","u":"https://bitcointalk.org/index.php?topic=295","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/88/","m":[{"f":"Gavin Andresen","d":1278962146,"b":[["t","The Bitcoin Faucet is handling the slashdotting really well... except that I'm running out of coins to give away.  over 5,000 have flowed out of the Faucet since I refilled it last night.\n\nAny of you early adopters who generated tens of thousands of coins back in the early days, are you willing to send a few to the Faucet to be given away so more people can try out Bitcoin?  I know that most of them are likely to be lost (I suspect there a lot of slashdot lookey-loos who won't stick around long enough to spend their 5 bitcoins), but if that's the case then that'll just increase the value of your other bitcoins, anyway...\n\nFountain donation address is:  15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC\n\nDepending on donations and how long the slashdotting lasts, I might have to start giving away bitnickels..."]],"u":"https://bitcointalk.org/index.php?topic=295.msg2365#msg2365"},{"f":"Gavin Andresen","d":1278986244,"b":[["t","Thanks for the donations... whoever you are who donated!\n\nThe Faucet has about 2,000 coins in it at the moment; I just deployed a new version that will automatically start giving out bit-nickels if the balance falls below 500 (but allows anybody who gets a bit-nickel to come back later and get the 5 bitcoins \"they deserve\" if/when the Faucet is refilled)."]],"u":"https://bitcointalk.org/index.php?topic=295.msg2453#msg2453"},{"f":"XaviorPenguin","d":1279069541,"b":[["t","You can have the 5 you gave me back.  I just wanted to see how this all works and all and hopefully, I will have some coins popping up every couple of days.  Smiley\n\nThank you for running a great program/incentive!  I appreciate it!"]],"u":"https://bitcointalk.org/index.php?topic=295.msg2705#msg2705"},{"f":"Gavin Andresen","d":1279112672,"b":[["t","Thanks Xavier!\n\nTo everyone else:  the Faucet is now giving out bit-nickels; it just went under 500 BTC.  I've got just under 2,000 BTC left to refill it, but I think I'll start letting it drain a nickel-at-a-time and keep it above zero for as long as I can (refilling it to just under 500 if it gets near zero)."]],"u":"https://bitcointalk.org/index.php?topic=295.msg2817#msg2817"},{"f":"BitLex","d":1279121403,"b":[["t","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.\n\nregrettably i havent been around back in those early days, but i'll gladly send all incoming 5coin credits back to you.  Cool"]],"u":"https://bitcointalk.org/index.php?topic=295.msg2847#msg2847"},{"f":"satoshi","d":1279245727,"b":[["t","5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.\n\nThis is an important service so new users can at least get something if generating is too hard."]],"u":"https://bitcointalk.org/index.php?topic=295.msg3350#msg3350","s":1,"n":208,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/208/"}]},{"id":"p89","k":"p","s":"bitcointalk","t":"Fedora 13 libcrypto","u":"https://bitcointalk.org/index.php?topic=296","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/89/","m":[{"f":"chupacabra","d":1278962850,"b":[["t","I get this when trying to run bitcoin:\n\n[michael@fed13 64]$ ./bitcoin\n./bitcoin: error while loading shared libraries: libcrypto.so.0.9.8: cannot open shared object file: No such file or directory\n\nFedora 13 uses this:\n\n/lib64/libcrypto.so.1.0.0a\n\nHow can I get around this?\n\nI tried a symlink and running ldd and ldconfig to no avail.\n\nThanks"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2367#msg2367"},{"f":"diven","d":1278965115,"b":[["t","I am having the same issue on Slackware64 13.1."]],"u":"https://bitcointalk.org/index.php?topic=296.msg2369#msg2369"},{"f":"ribuck","d":1279034775,"b":[["t","I am having the same problem on Fedora 12 32-bit, which also uses libcrypto.so.1.0.0a.\n\nAs chupacabra says, a symlink doesn't help because the different library versions contain different symbols."]],"u":"https://bitcointalk.org/index.php?topic=296.msg2567#msg2567"},{"f":"sgtstein","d":1279040971,"b":[["t","I too am having issues running it. Same error as above.\n\nDoes anyone know how to build it from source on F13? If we could do that, it should work just fine with the new module."]],"u":"https://bitcointalk.org/index.php?topic=296.msg2578#msg2578"},{"f":"laszlo","d":1279042048,"b":[["t","If you're ok with hacking the makefile to update your paths and such, try looking these notes I took to get you started:\n\nhttp://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdf"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2585#msg2585"},{"f":"chupacabra","d":1279044752,"b":[["t","I would hope some real developer fixes this so Fedora and Slackware users can use it.  No telling what other distros it fails on.  What was it built on?  I'm guessing Ubuntu/Debian which in my opinion is the most broken fork existing. \n\nPlease guys.  Help us out.\n\nThanks.\n\nI'm having my wedding today so I dont have time to code.    Shocked"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2603#msg2603"},{"f":"lachesis","d":1279045224,"b":[["t","Mazel tov!\n\nDon't be hatin' on Ubuntu though. It's a good OS, and it's helping to drive Linux adoption in the home.\n\nTry building yourself when you get some free time on the honeymoon! Cheesy\n\nAlternatively, try this build: (x86_64 only, sorry)\nhttp://www.alloscomp.com/bitcoin/bitcoin-r102"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2605#msg2605"},{"f":"chupacabra","d":1279046355,"b":[["t","YAY.  Fedora users try this binary.  http://www.alloscomp.com/bitcoin/bitcoin-r102"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2611#msg2611"},{"f":"sgtstein","d":1279051087,"b":[["q","YAY.  Fedora users try this binary.  http://www.alloscomp.com/bitcoin/bitcoin-r102","Quote from: chupacabra on July 13, 2010, 06:39:15 PM"],["t","Second confirmation that this is the WORKING build for Fedora 13.\n\nThanks!"]],"u":"https://bitcointalk.org/index.php?topic=296.msg2630#msg2630"},{"f":"ribuck","d":1279055770,"b":[["t","Thanks for the link to that binary.\n\nUnfortunately it doesn't work for me. The bash shell gives a \"cannot execute binary file\" error.\n\nI guess bitcoin-r102 is a 64-bit binary, and I'm running 32-bit Fedora."]],"u":"https://bitcointalk.org/index.php?topic=296.msg2648#msg2648"},{"f":"sgtstein","d":1279059266,"b":[["q","Thanks for the link to that binary.\n\nUnfortunately it doesn't work for me. The bash shell gives a \"cannot execute binary file\" error.\n\nI guess bitcoin-r102 is a 64-bit binary, and I'm running 32-bit Fedora.","Quote from: ribuck on July 13, 2010, 09:16:10 PM"],["t","True. This is only a 64-bit binary.\n\nIf no one else gets a binary uploaded tonight, I will try my hand at building one tomorrow morning."]],"u":"https://bitcointalk.org/index.php?topic=296.msg2664#msg2664"},{"f":"ribuck","d":1279277237,"b":[["q","... I will try my hand at building one ...","Quote from: sgtstein on July 13, 2010, 10:14:26 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=296.msg3427#msg3427"},{"f":"satoshi","d":1279292123,"b":[["t","Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:\n\nhttp://bitcointalk.org/index.php?topic=383.0\n\nLet me know if that works."]],"u":"https://bitcointalk.org/index.php?topic=296.msg3495#msg3495","s":1,"n":212,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/212/"}]},{"id":"p90","k":"p","s":"bitcointalk","t":"Building Bitcoin 0.3","u":"https://bitcointalk.org/index.php?topic=298","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/90/","m":[{"f":"Nagilum","d":1278962451,"b":[["t","I tried building it myself but it didn't compile.\nWhich ports did you use?\nI tried with wxgtk28-unicode and db42-4.2.52_5 & db50-5.0.21.0\nHere the latest attempt:\nnagilum@cakebox ~/src > uname -a\nFreeBSD cakebox.tis 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #0: Tue Jun 29 22:25:46 CEST 2010     root@cakebox.tis:/usr/obj/export/src/sys/net5501  i386\nnagilum@cakebox ~/src > gmake -f makefile.unix\ng++45 -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -I\"/usr/include\" -I\"/usr/local/include\" -I\"/usr/local/include/wx-2.8\" -I\"/usr/local/lib/wx/include/gtk2-unicode-release-2.8\" -I\"/usr/local/include/db50\" -o headers.h.gch headers.h\nIn file included from headers.h:108:0:\nui.h:13:142: error: default argument for 'const wxString& caption' has type 'const char [8]'\nui.h: In function 'int MyMessageBox(const wxString&, const wxString&, int, wxWindow*, int, int)':\nui.h:19:51: error: no matching function for call to 'std::basic_string<char>::basic_string(const wxString&)'\n/usr/local/lib/gcc45/include/c++/bits/basic_string.tcc:219:5: note: candidates are: std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>, std::basic_string<_CharT, _Traits, _Alloc>::size_type = unsigned int]\n/usr/local/lib/gcc45/include/c++/bits/basic_string.tcc:212:5: note:                 std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]\n..."]],"u":"https://bitcointalk.org/index.php?topic=298.msg2366#msg2366"},{"f":"laszlo","d":1278967330,"b":[["t","Looks like your wxWidgets and STL - you should compile your own wxWidgets from the 2.9 release.\n\nUse something like this to configure it and adjust the reference paths in your makefile.unix"],["q","mkdir buildgtk\ncd buildgtk\n../configure --prefix=/home/my_user/bitcoin/deps \\\n--with-gtk \\\n--disable-shared \\\n--disable-debug_flag \\\n--enable-stl \\\n--enable-utf8 \\\n--with-libjpeg=builtin \\\n--with-libpng=builtin \\\n--withregex=builtin \\\n--with-libtiff=builtin \\\n--with-zlib=builtin \\\n--withexpat=builtin","Quote"]],"u":"https://bitcointalk.org/index.php?topic=298.msg2374#msg2374"},{"f":"satoshi","d":1279128890,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=298.msg2885#msg2885","s":1,"n":181,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/181/"}]},{"id":"p91","k":"p","s":"bitcointalk","t":"Runaway CPU usage for 64bit BitCoin (Linux Client)","u":"https://bitcointalk.org/index.php?topic=299","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/91/","m":[{"f":"knightmb","d":1278968356,"b":[["t","I did a forum search, didn't see this mentioned by anyone yet.\n\nI have 5 Bit Coin clients, some running Windows Bit Coin, others running Linux Bit Coin.\n\nI only have one 64 bit Linux system, but when I run Bit Coin, after about 10 minutes, the CPU usage runs away and brings the system to a stall unless I kill the Bit Coin application.\n\nNow I have 2 other computers running a 32 bit Linux Bit Coin client and they work just fine, no runaway CPU.\n\nI've tried running the 32 bit Bit Coin on the 64 bit Linux system, but the same thing still happens. My 64 bit Linux system has a dual-core processor, and even when I choose the \"use only 1 processor\" option, after a while Bit Coin ends up using both CPU to the 100% max that it can.\n\nIs this a bug that only affects 64 bit Linux users at the moment?\n\nUsing the latest version 0.3.0 from the front page of the website.\n\nSystem OS: Linux Mandriva 2010.0 (64 bit)\nRAM 16GB\nProcessor - Intel Dual-Core 3.06 CPU\n\nFeedback or advice welcome.  Grin\n\nEdit by Xunie: I merged this thread with the other \"Bitcoin slowing down your Linux system?\" thread, so things my be confusing for a second, heh."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2378#msg2378"},{"f":"Xunie","d":1278968732,"b":[["t","There has been a problem in settings the \"nice\" level on Linux.\nA programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!\n\nSo, we have a bug."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2383#msg2383"},{"f":"lachesis","d":1278970096,"b":[["t","I never noticed responsiveness issues. Perhaps I should nice Bitcoin until the fix."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2385#msg2385","sj":"Re: Bitcoin slowing down your Linux system?"},{"f":"lachesis","d":1278970143,"b":[["t","I wondered about that, but I've never noticed any issues on a dual-core 64bit system."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2386#msg2386"},{"f":"knightmb","d":1278970889,"b":[["q","There has been a problem in settings the \"nice\" level on Linux.\nA programmer who wasn't familiar with Unix/Linux used the highest priority (-20) instead of the lowest priority (20)!\n\nSo, we have a bug.","Quote from: Xunie on July 12, 2010, 09:05:32 PM"],["t","Yeah, that always gets me too. You would think a negative number would mean less and positive number means more, but it turns out \"Nice\" works the opposite of that, you want it to be more \"nice\" so you want a higher number, LOL.\n\nI checked the 32bit Linux clients, they run a Nice level of 0, so I guess it's running equal time with everything else.\n\nOn the Windows clients, Bit Coin runs at \"normal\" priority as well.\n\nIt's easy to start the process in low priority via command line for both of them, so for now I can do that to manually control their priority  Grin"]],"u":"https://bitcointalk.org/index.php?topic=299.msg2391#msg2391"},{"f":"Xunie","d":1278973673,"b":[["t","It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest.\nI think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried.\nSo, I think the dirty hack of editing /etc/security/limits.conf might fix it."],["q","I wondered about that, but I've never noticed any issues on a dual-core 64bit system.","Quote from: lachesis on July 12, 2010, 09:29:03 PM"],["t","I don't have any problems on my quad core system here either!"]],"u":"https://bitcointalk.org/index.php?topic=299.msg2406#msg2406","sj":"Re: Bitcoin slowing down your Linux system?"},{"f":"knightmb","d":1278974116,"b":[["q","It automatically raises it, I don't think nice 20 ./bitcoin will help to be honest.\nI think some people have set higher priorities for themselves in /etc/security/limits.conf, and when -20 isn't available as a nice level, a lower priority is tried.\nSo, I think the dirty hack of editing /etc/security/limits.conf might fix it.\n\n> Quote from: lachesis on July 12, 2010, 09:29:03 PM\n> I wondered about that, but I've never noticed any issues on a dual-core 64bit system.\nI don't have any problems on my quad core system here either!","Quote from: Xunie on July 12, 2010, 10:27:53 PM"],["t","That may be the issue because you can't \"Nice 20\" anything, 19 is the max  Wink\n\nSo far, I've \"Nice 19\" 3 clients (one 64 bit and two 32 bit) for the last hour and they haven't changed the Nice level on me yet.\n\nI figured since the process is started at that level, it would remain for all child processes spawned afterwards. I could be wrong though, I'll check again in another few hours to see."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2408#msg2408","sj":"Re: Bitcoin slowing down your Linux system?"},{"f":"knightmb","d":1278974353,"b":[["t","On a side note, I've tracked down the other GUI issue.\n\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.\n\nThis only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.\n\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?  Huh"]],"u":"https://bitcointalk.org/index.php?topic=299.msg2409#msg2409"},{"f":"asdfman","d":1278975559,"b":[["t","knightmb - just curious, if you check not just the main process, but all the thread processes (ps -eflL | grep bitcoin - need the L, or else it will just show the main process), do you see the other thread processes change the priority after a little while ?  When I change the priority or renice, it will just stick for the main process, but some of threads will change priority everytime it goes to the generate coin function..\n\nthere may be some confusion in thinking that nice is working in that if people dont use -L to list all threads, they just see the PID of the main process, and think that the nice/renice has worked, when in fact the 2 subthreads that are maxing the CPU are the ones that are changing the priority back..\n\nI myself just ripped out the whole priority changing function, so that whatever priority I set sticks permanently..\n\nmy post about ripping out priority change function is in : http://bitcointalk.org/index.php?topic=72.0\nalso shows the whole process tree.. in that code pasting, the main process would stay to whatever you nice/renice to, but 2 of the threads would change back, until i ripped out the function\n\nalso http://bitcointalk.org/index.php?topic=285.0 describes the bug with bitcoin changing the threads to use the highest priority instead of lowest"]],"u":"https://bitcointalk.org/index.php?topic=299.msg2412#msg2412"},{"f":"knightmb","d":1278976086,"b":[["q","knightmb - just curious, if you check not just the main process, but all the thread processes (ps -eflL | grep bitcoin - need the L, or else it will just show the main process), do you see the other thread processes change the priority after a little while ?  When I change the priority or renice, it will just stick for the main process, but some of threads will change priority everytime it goes to the generate coin function..","Quote from: asdfman on July 12, 2010, 10:59:19 PM"],["t","Feedback from the ps -elfL | grep bitcoin command"],["c","[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin\n0 S knightmb 11200  6781 11200  0   10  99  19 - 114169 poll_s 17:17 ?       00:00:02 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11202  0   10  99  19 - 114169 hrtime 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11203  0   10  99  19 - 114169 hrtime 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11204  0   10  99  19 - 114169 hrtime 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11212  0   10  99  19 - 114169 sk_wai 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 R knightmb 11200  6781 11213  0   10  99  19 - 114169 -     17:17 ?        00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11214  0   10  99  19 - 114169 hrtime 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 S knightmb 11200  6781 11215  0   10  82   2 - 114169 hrtime 17:17 ?       00:00:00 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 R knightmb 11200  6781 11216 86   10  99  19 - 114169 -     17:17 ?        00:40:37 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n1 R knightmb 11200  6781 11219 85   10  99  19 - 114169 -     17:17 ?        00:40:11 /home/knightmb/bin/bitcoin-0.3.0/bin/64/bitcoin\n0 R knightmb 13291 12282 13291  0    1  80   0 -  1842 -      18:04 pts/1    00:00:00 grep --color bitcoin"],["t","Anything in that look out of place? I did notice one that was nice to \"2\" instead of \"19\"\n\n[edit] I see now from the other topic, I'm running the client, the other was the server daemon, might be a bug with just the daemon, not sure though."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2414#msg2414"},{"f":"asdfman","d":1278976230,"b":[["t","yep, that 2 is exactly what im talking about..\nwait a little longer and another thread might reset too.. after my change all my threads all stay 19 forever...."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2415#msg2415"},{"f":"knightmb","d":1278976501,"b":[["q","yep, that 2 is exactly what im talking about..\nwait a little longer and another thread might reset too.. after my change all my threads all stay 19 forever....","Quote from: asdfman on July 12, 2010, 11:10:30 PM"],["t","Ah I see now. Since you've already dove into the code and disabled the function, is there any reason why the function in question wouldn't just set everything to lowest priority by default? Why would it need to change it around? I'm afraid to dive in myself, otherwise I'll spend days fixing it, hehe."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2418#msg2418"},{"f":"asdfman","d":1278976974,"b":[["t","from what I saw, there was an error in util.h basically the THREAD_PRIORITY_LOWEST was defined as PRIO_MIN.. the intention was to switch to the \"lowest\" priority, but in the linux kernel source in resourch.h PRIO_MIN is actually the lowest NUMBER (-20), meaning it actually changed to the HIGHEST priority.. and then after that function is done, it will change priority again (to either 0 or 2, not as bad as -20) but either way it is changing it, so either way no matter what you nice/renice the threads to, it will switch to diff priority levels automatically, with those particular threads that switch priorities never being the most unobtrusive at 19..\n\nIts been stated in the latest source code, this min/max is fixed, so if you dl the latest source tree and compile the min/max reversal should be fixed... personally I didnt care of having any of the threads change priority on its own at all, so I just removed the function alltogether.."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2420#msg2420"},{"f":"knightmb","d":1278977247,"b":[["q","from what I saw, there was an error in util.h basically the THREAD_PRIORITY_LOWEST was defined as PRIO_MIN.. the intention was to switch to the \"lowest\" priority, but in the linux kernel source in resourch.h PRIO_MIN is actually the lowest NUMBER (-20), meaning it actually changed to the HIGHEST priority.. and then after that function is done, it will change priority again (to either 0 or 2, not as bad as -20) but either way it is changing it, so either way no matter what you nice/renice the threads to, it will switch to diff priority levels automatically, with those particular threads that switch priorities never being the most unobtrusive at 19..","Quote from: asdfman on July 12, 2010, 11:22:54 PM"],["t","Yeah, I finally found it as well (I knew I shouldn't have peaked in the code, LOL). I'm going to try manually setting it to hard code 19 and see if that makes a difference after a compile. If so, it might be a more elegant solution that removing the function all together since it appears it's trying to balance out when to use more CPU depending on the system load."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2422#msg2422"},{"f":"asdfman","d":1278977482,"b":[["t","hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)\n\nI agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don't want any part of it)"]],"u":"https://bitcointalk.org/index.php?topic=299.msg2423#msg2423"},{"f":"knightmb","d":1278978580,"b":[["q","hardcoding to 19 should work, also you could just change PRIO_MIN to PRIO_MAX which would basically do the same thing, (technically PRIO_MAX is defined as 20 in the linux kernel source)\n\nI agree that there authors saw some practicality in changing the priority depending on what the function is doing, but personally Id rather just have it not touch the priority at all, as the program will work just fine sitting at lowest priority all day.. I dont want it ever stealing any priority from any process regardless of what the thread is doing.. (maybe it would be a good suggestion to make this a command line parameter to disable/enable automatic priority adjustment - Im sure theres many who would prefer to keep the automatic priority scheduling in place, but also plenty that don't want any part of it)","Quote from: asdfman on July 12, 2010, 11:31:22 PM"],["t","Good point. I just wanted to test if it made a difference (I suspect it will). But after reading the other topics, seems the fix was already checked into the SVN, just not in time for the release so there is no sense in me trying a fix that which is already fixed code wise, hehe.\n\nI agree though, it just needs to run at the lowest prioirty at *all* times, I mean it's suppose to run off of idle CPU and a nice level of 2 isn't far from *shared* CPU cycles than *idle* CPU cycles in my opinion."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2427#msg2427"},{"f":"aceat64","d":1279127301,"b":[["t","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)."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2882#msg2882"},{"f":"satoshi","d":1279133153,"b":[["t","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.\n\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."],["q","On a side note, I've tracked down the other GUI issue.\n\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.\n\nThis only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.\n\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?  Huh","Quote from: knightmb on July 12, 2010, 10:39:13 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2908#msg2908","s":1,"n":185,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/185/"},{"f":"knightmb","d":1279133574,"b":[["q","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.\n\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.\n\n> Quote from: knightmb on July 12, 2010, 10:39:13 PM\n> On a side note, I've tracked down the other GUI issue.\n>\n> The \"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.\n>\n> This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this.\n>\n> I 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?  Huh\nThat'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.","Quote from: satoshi on July 14, 2010, 06:45:53 PM"],["t","It only seems to happen if\nA) you minimize to tray, later bring it back up, minimize again, bring it back up. It starts stacking tray icons out (but they are blank, but still labeled as BitCoin)\nB) sometimes the program does it randomly\n\nI'll turn it back on with mine to make a screen shot, doesn't take long for it to happen, hehe."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2910#msg2910"},{"f":"knightmb","d":1279139100,"b":[["t","Ok, easy to replicate (well for me anyway)\n\n64bit Client Linux\n\nHaving either the \"minimize to tray instead of taskbar\" or \"minimize on close\" options checked will cause the bug.\n\nFirst thing you notice (as per the first screen-shot), the tasktray is being filled up with invisible icons \"spaces\". If you hover the mouse over them, they all say \"Bitcoin (not connected\" but the one that does have an Bit Coin icon, just says \"Bitcoin\" and that's what you can bring the window back up with.\n\nIf you just have \"minimize on close\" checked, it still sends it to task tray causing the bugs.\n\nAfter a while, all your CPU will be consumed by the X server, even after you close Bitcoin, I think some process stay stuck in memory, not sure.\n\nThe 32bit Client for Linux doesn't have this exact issue. I will still make at least one invisible Bitcoin icon, but doesn't tear up the CPU later. So the 32 bit client sort-a has the bug, but not in a way to bring the system down after a short while."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2934#msg2934"},{"f":"lachesis","d":1279140656,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=299.msg2943#msg2943"},{"f":"satoshi","d":1279153103,"b":[["t","OK, the undocumented switch \"-minimizetotray\" which re-enables the option.\n\nI uploaded the change to SVN."]],"u":"https://bitcointalk.org/index.php?topic=299.msg3008#msg3008","s":1,"n":189,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/189/"},{"f":"knightmb","d":1279153276,"b":[["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.","Quote from: lachesis on July 14, 2010, 08:50:56 PM"],["t","I like it alot too, wished it work for me  Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=299.msg3009#msg3009"},{"f":"satoshi","d":1279232550,"b":[["t","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"]],"u":"https://bitcointalk.org/index.php?topic=299.msg3309#msg3309","s":1,"n":204,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/204/"}]},{"id":"p92","k":"p","s":"bitcointalk","t":"Resending transaction","u":"https://bitcointalk.org/index.php?topic=303","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/92/","m":[{"f":"bdonlan","d":1278974804,"b":[["t","I created a send coins transaction when my laptop was offline; now it's stuck at 0/unconfirmed and not visible to the recipient, even though other transactions I created later went through. How do I force the transaction to be re-sent to the network so it can make progress? Or alternately, how do I cancel the transaction so I can get my funds back?"]],"u":"https://bitcointalk.org/index.php?topic=303.msg2410#msg2410"},{"f":"bdonlan","d":1278976319,"b":[["t","It seems the transaction went through after about an hour and a half."]],"u":"https://bitcointalk.org/index.php?topic=303.msg2417#msg2417"},{"f":"gazoakley","d":1279278112,"b":[["t","I'm having the same problem - opened BitCoin to create a transaction and possibly exited before it sent out the payment details. Now I have a 0/unconfirmed transaction.\n\nHaving the ability to resend a stuck transaction would be nice - if no nodes have picked it up yet then surely sending it again won't cause an issue (and if some have then they'll just ignore it right?)"]],"u":"https://bitcointalk.org/index.php?topic=303.msg3429#msg3429"},{"f":"d1337r","d":1279280374,"b":[["t","Looks like exiting BitCoin should be disabled until each transaction will get at least 1 confirmation Smiley"]],"u":"https://bitcointalk.org/index.php?topic=303.msg3438#msg3438"},{"f":"gazoakley","d":1279282078,"b":[["t","Phew - it's taken a couple of hours but it's now gone through Smiley. Wish I could generate coins more easily! Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=303.msg3447#msg3447"},{"f":"Insti","d":1279283365,"b":[["t","0/unconfirmed means that your client has seen the transaction\n\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.\n\nas the number of confirmations increases, so does the confidence in the 'truth' of the transaction.\n\nThere is no way to cancel a transaction.\n\nIt is not possible with the current client to resend a transaction."]],"u":"https://bitcointalk.org/index.php?topic=303.msg3450#msg3450"},{"f":"satoshi","d":1279292493,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=303.msg3499#msg3499","s":1,"n":213,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/213/"}]},{"id":"p93","k":"p","s":"bitcointalk","t":"Stuck on 513 blocks","u":"https://bitcointalk.org/index.php?topic=305","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/93/","m":[{"f":"ellimistd","d":1278980299,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=305.msg2429#msg2429"},{"f":"dkaparis","d":1279059753,"b":[["t","Are you by any chance using Microsoft Security Essentials or 'Live Protection' antivirus program? It is known to interfere with bitcoin's operation, see here:\n\nhttp://bitcointalk.org/index.php?topic=35.0"]],"u":"https://bitcointalk.org/index.php?topic=305.msg2667#msg2667"},{"f":"dkaparis","d":1279061466,"b":[["t","It should be enough to just add bitcoin.exe to the \"Excluded processes\" list in settings.\n\nIt is a good idea to add this to the FAQ somewhere."]],"u":"https://bitcointalk.org/index.php?topic=305.msg2673#msg2673"},{"f":"lachesis","d":1279067395,"b":[["t","513 is my area code. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=305.msg2692#msg2692"},{"f":"satoshi","d":1279130548,"b":[["t","This is the second time I've seen this \"Live Protection\" problem reported.\n\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.\n\nWe need to understand this problem better.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=305.msg2895#msg2895","s":1,"n":183,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/183/"}]},{"id":"p94","k":"p","s":"bitcointalk","t":"Error on Ubuntu 10.04","u":"https://bitcointalk.org/index.php?topic=318","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/94/","m":[{"f":"vishwambar","d":1279022205,"b":[["t","Hi,\n\nTried bitcoind 0.3 on Ubuntu 10.04 and I get the following error when I run bincoind"],["c","05: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\n\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"],["t","I get a similar error when running bitcoin UI but it has a continue handle and hence it works fine.\n\nCan somebody tell me what this error means and how to go about resolving this?"]],"u":"https://bitcointalk.org/index.php?topic=318.msg2537#msg2537"},{"f":"satoshi","d":1279131941,"b":[["t","What language is your computer set to?  Is it set to German, Dutch or Italian?  Is it one of those sub-languages like \"nl-??\"?\n\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.\n\nCan someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three?"]],"u":"https://bitcointalk.org/index.php?topic=318.msg2903#msg2903","s":1,"n":184,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/184/"}]},{"id":"p95","k":"p","s":"bitcointalk","t":"No blocks downloaded - MS Security Essentials users please read","u":"https://bitcointalk.org/index.php?topic=323","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/95/","m":[{"f":"ksd5","d":1279040263,"b":[["t","I got my friend to download and try Bitcoin out. I sent him one coin, but he hasn't received it. For some reason, his client isn't downloading any blocks. He turned on \"Generate Coins\" the minute he started the program for the first time. His speeds were in the 1400-1600 khash/s range, and he had 3 blocks. He generated 50 coins which will mature in another 100 blocks or so. He has around 40 connections.\n\nTo my knowledge, his coins will be invalid because none of the other nodes will accept his blocks. And, since he hasn't downloaded any blocks, he won't receive the one Bitcoin I sent him.\n\nHe uses Microsoft Security Essentials, but has added Bitcoin to its unblock list. He does have port 8333 open, but has a Linux network firewall. (He doesn't have the rights to access the firewall.)\n\nWhat could be the problem?"]],"u":"https://bitcointalk.org/index.php?topic=323.msg2576#msg2576"},{"f":"Strofcon","d":1279040893,"b":[["t","Might need to have him start it with -addnode=x.x.x.x, where x.x.x.x is someone's static IP. Hopefully someone should be able to share theirs for that purpose... if that's the issue, of course. :-) I don't know for sure though."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2577#msg2577","sj":"Re: No blocks downloaded... why?"},{"f":"laszlo","d":1279042304,"b":[["t","This seems like a commonly reported problem now - something to do with the block downloading being really slow.  It may be related to the excessive amount of disk I/O that is generated during the initial download.  The database file is flushed to disk every time a block is added so this is being really slow for some people.  I think we can probably fix this up now that we know about it.. I for one didn't do much testing without having all the blocks, so it never occurred to me to try this under different systems."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2588#msg2588","sj":"Re: No blocks downloaded... why?"},{"f":"agaumoney","d":1279042539,"b":[["t","The static IP using addnode will probably work.\n\nHowever the software is designed to bootstrap using IRC.  Probably connecting out to the IRC server is being blocked either by Microsoft or his Linux firewall.  Without IRC his system is unable to discover other nodes.\n\nIRC has nothing to do with port 8333, but most likely the Linux firewall is blocking incoming port 8333, so bitcoin will need to establish outgoing connections to other systems with a 8333 open for incoming connections.  Without opening incoming 8333 the max connections will be limited to 8 (I think)."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2589#msg2589","sj":"Re: No blocks downloaded... why?"},{"f":"ksd5","d":1279042920,"b":[["t","Well, I don't have port 8333 open, but I was able to download all the blocks. (I don't use a firewall, though.)\n\nI'll ask him to get rights to the firewall and check what it does with port 8333 connections. His port 8333 is open, but the firewall may be messing with it."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2591#msg2591","sj":"Re: No blocks downloaded... why?"},{"f":"Strofcon","d":1279043888,"b":[["t","I think I read somewhere that if he has any connections, he is connecting to the IRC channel just fine... I think you're correct on the 8 connection limit without having port 8333 forwarded.\n\nMy thinking was that the static IP -addnode would help by providing a dedicated download source. If that still doesn't work well then I'd guess that laszlo has hit the nail on the head, and the constant full-rewrite of the file is to blame."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2597#msg2597","sj":"Re: No blocks downloaded... why?"},{"f":"agaumoney","d":1279044822,"b":[["q","I think I read somewhere that if he has any connections, he is connecting to the IRC channel just fine... I think you're correct on the 8 connection limit without having port 8333 forwarded.\n\nMy thinking was that the static IP -addnode would help by providing a dedicated download source. If that still doesn't work well then I'd guess that laszlo has hit the nail on the head, and the constant full-rewrite of the file is to blame.","Quote from: Strofcon on July 13, 2010, 05:58:08 PM"],["t","Oh, right.  Missed that he had 40 connections.   Huh\n\nBut 0 blocks downloaded?\n\nMy macmini is currently downloading blocks.  It is up to 38xxx after about 4 hours.  That is with two dedicated sources on the same lan plus another 6 it discovered out on the 'net.  (It is a 2009 model with 4gb of ram using only a 150GB partition of a 500GB, 7200rpm, 2.5\" drive, running the 0.30 .zip'd version as a -server.)\n\nThe old macmini drive is in an atom D510 system and is a very slow hard disk.  It took a long time (18+hours) to download the blocks even with a dedicated source.  But even then it did not stay at 0 blocks for more than a minute or so.\n\nI wonder how much downloading to a ramdisk would speed it up..."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2604#msg2604","sj":"Re: No blocks downloaded... why?"},{"f":"bitcoin2paysafe","d":1279046274,"b":[["t","Maybe, the hdd is full?"]],"u":"https://bitcointalk.org/index.php?topic=323.msg2610#msg2610","sj":"Re: No blocks downloaded... why?"},{"f":"Strofcon","d":1279046545,"b":[["t","Yea, possibly a full disk, or a failing disk... It's odd that even with a dedicated connection within your LAN it took that long to get that number of blocks. My 100 Mbps router funneled them from one of my PCs to another in less than 15 minutes, at the 65K+ blocks it needed.\n\nMaybe a flakey router or internet connection? Might be worthwhile to do a speed test, or research Microsoft Security Essentials to make sure it's not toying with Bitcoin's ability to build the block list in some other way... not too familiar with Microsoft products I'm afraid.  Undecided"]],"u":"https://bitcointalk.org/index.php?topic=323.msg2613#msg2613","sj":"Re: No blocks downloaded... why?"},{"f":"ksd5","d":1279059574,"b":[["t","Okay, I solved the problem. The solution was in http://bitcointalk.org/index.php?topic=35.0."]],"u":"https://bitcointalk.org/index.php?topic=323.msg2666#msg2666","sj":"Re: No blocks downloaded... why?"},{"f":"satoshi","d":1279124523,"b":[["t","So that was responsible for keeping blocks from downloading?\n\nThe link: \"Win32 CPU Cycles vs 'Live Protection' Engines\"\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=323.msg2867#msg2867","s":1,"n":178,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/178/","sj":"Re: No blocks downloaded... why?"}]},{"id":"p96","k":"p","s":"bitcointalk","t":"Hash/sec Throttling for Democracy","u":"https://bitcointalk.org/index.php?topic=325","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/96/","m":[{"f":"InterArmaEnimSil","d":1279045435,"b":[["t","I've seen a number of posts complaining that coin generation on old machines is impractical (actually, the posts say impossible, but that's not correct).  A number of others have espoused the general idea that flops*luck=coins, which seems to me to be about right.  One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the \"flops\" category of flops*luck.  \n\nNow, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck.  They operate upon statistical averages.  (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).  \n\nTherefore, why not cap the number of hashes per second?  If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the \"minimum requirements\" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope).  Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2606#msg2606"},{"f":"laszlo","d":1279046138,"b":[["t","Couldn't I just run 500 instances of the proposed capped client?  This is more about trading than generating - the generation is just to make it so the supply is limited."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2608#msg2608"},{"f":"Xunie","d":1279052293,"b":[["q","flops*luck=coins, which seems to me to be about right.  One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the \"flops\" category of flops*luck.  \n\nNow, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck.  They operate upon statistical averages.  (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).  ","Quote from: InterArmaEnimSil on July 13, 2010, 06:23:55 PM"],["t","Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times.\nWe will keep statistics of how many times it gives us what number between 0 and 1024.\nThe more we run it, the more difference in the array between the two numbers which got out putted the least and the most.\n\nAnd so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the \"chance\" of generating a block."],["q","Therefore, why not cap the number of hashes per second?  If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the \"minimum requirements\" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope).  Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.","Quote from: InterArmaEnimSil on July 13, 2010, 06:23:55 PM"],["t","We can't.\nBitcoin's Opensource so anyone can run a modified client and thus remove the cap!"],["q","Now, some have said \"If you have no luck, you don't get coins....\" but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck.  They operate upon statistical averages.  (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow). ","Quote from: InterArmaEnimSil on July 13, 2010, 06:23:55 PM"],["t","The Linux kernel RNG is seeded by noise on the system actually."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2634#msg2634"},{"f":"RHorning","d":1279061747,"b":[["q","Couldn't I just run 500 instances of the proposed capped client?  This is more about trading than generating - the generation is just to make it so the supply is limited.","Quote from: laszlo on July 13, 2010, 06:35:38 PM"],["t","The original question still applies here, however, and the idea that people new to the network don't have coins with which to even experiment is an issue, where in this case it is a hoarding issue of those who have come earlier.\n\nIs it possible to have a multi-tiered coin generation system, where you would have a cryptographically difficult series that would generate a whole bunch of coins at once when the series is completed (taking a few days, weeks, or even months to complete on average), but for those who are more interested in generating coins on a more gradual basis could generate say one bitcoin or even a fractional amount of a bitcoin every few minutes or hours?\n\nThe complaint right now is that given the current number of users on the network (which has increased substantially since the slashdot story.... look at the download statistics on Source Forge with a huge spike in the last few days for downloads alone) that coins simply aren't being generated at all.\n\nBTW, it would be nice to see if some other alternative random number generators could be used, as the current one seems to be a time-randomized Linear Congruential Generator.  (see http://en.wikipedia.org/wiki/Linear_congruential_generator for details)  BTW, feel free to correct me if I'm wrong on this point too. \n\nIt might be kind of interesting to experiment with alternate number generators, and it certainly would be healthy for the network if more than one kind of generator was being used.  The nice thing with the LCG as a random number generator is that it can be implemented using only integer arithmetic (often with floating point operations, however) and generally is the most efficient generator in terms of simply getting a number for most common implementations (such as is found with a typical video game) with the fewest CPU cycles.  There are some classes of numerical analysis applications where a generator of this nature may not be the best choice."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2675#msg2675"},{"f":"laszlo","d":1279064105,"b":[["t","I'm not sure which random number thing you're referring to, but here is a quick outline of how the generation works:\n\nPrepare a block of memory organized as a struct - certain fields like the hash of the previous block, the current time and some other housekeeeping information is filled in.  The struct has an integer field and another 'expansion' field where the data is free form.  This free form data is altered (simple increment of a number) and then the struct is hashed.  The resulting hash is interpreted as a large integer.  If it is equal to or less than the current difficulty function then the proof of work has been found and this block is added locally and broadcast to other nodes.\n\nThis is similar to having a 100 sided die - if you roll below 70 you win.  To make the game harder you have to roll below 50, then 40, etc.  Basically there is no known shortcut to go from a desired hash value to the original input, we only know how to do it quickly in the other direction, so it is simply a brute force iterative process.  Statistically, less blocks of data will be below the target value, the lower the target value is.  Finding a block that hashes below the difficulty value proves that you worked on the problem, or got lucky and hit it on the first try, but over a long period of time you won't keep getting lucky, you'll have to try lots and lots of different values."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2679#msg2679"},{"f":"InterArmaEnimSil","d":1279078283,"b":[["q","Couldn't I just run 500 instances of the proposed capped client?  This is more about trading than generating - the generation is just to make it so the supply is limited.","Quote from: laszlo on July 13, 2010, 06:35:38 PM"],["t","Maybe, or maybe not.  It would depend upon whether the code did any checking for running clients. The software could easily run some check and prevent a machine from running more than one client.  Of course, there are ways around this, a la VMs, etc, but that's another issue altogether."],["q","Say I have a RNG that can output 1024 different numbers, and we run it 1024*1024 times.\nWe will keep statistics of how many times it gives us what number between 0 and 1024.\nThe more we run it, the more difference in the array between the two numbers which got out putted the least and the most.\n\nAnd so, I can say with a certain amount of security without looking like a fool that how RNGs are used in Bitcoin affects the \"chance\" of generating a block.","Quote from: Xunie on July 13, 2010, 08:18:13 PM"],["t","Actually, the number of outputs for the least output number and the number of the outputs for the most output number would tend, as you increased the number of runs to infinity, toward the same number.  Specifically, each would tend toward RUNS*1/RNG_RANGE.  This was my initial point - there is no luck involved - there's a mechanistic algorithmic process that simulates luck for a small set, but for any large number of runs or large number of machines performing runs, you get the result of the above formula."],["q","We can't.\nBitcoin's Opensource so anyone can run a modified client and thus remove the cap!","Quote from: Xunie on July 13, 2010, 08:18:13 PM"],["t","Just because the program is open source doesn't mean that it can't check work for validity.  This comment is akin to saying \"Anyone could modify the program to create fifty billion bitcoins, since its open source.\"  No.  The other nodes on the network run checks to determine that blocks (I think blocks is the right terminology, I just found bitcoin recently) are legitimate.  Similarly, there are a myriad of ways to sign work to verify that it is originating from an un-hacked client.  This would reject work from clients which had been modified to remove the cap, or to remove the limit of one instance of the program per machine.  Sure, someone is free to modify the source and remove all caps.  However, if they do that, their work would be rejected by the network of legitimate clients, and the \"hacked\" client would be useless unless someone wanted to start an entire new chain, and thus a competitive currency."],["q","The Linux kernel RNG is seeded by noise on the system actually.","Quote from: Xunie on July 13, 2010, 08:18:13 PM"],["t","Yes, dev/random works this way, but it is blocking, and as I said, very slow.  Run \"cat /dev/random\" and see how quickly the bytes pour onto your screen - they trickle.  This may or may not be fast enough for bitcoin - I haven't delved into the source as of yet.  Conversely, dev/urandom does not work exclusively off of atmospheric noise, and thus is not truly random.   Run \"cat /dev/urandom\" and you'll be deluged with pseudorandom noise.  /dev/urandom, obviously, is more practical due to the fact that it doesn't hang the machine as it waits for more truly random data - it generates more as it needs it if there is none left in the kernel noise pool.  Even with fully random clients, however, they tend, statistically, over time, to the RUNS*1/RNG_RANGE formula for each output possibility.  Luck applies per each individual chance.  Statistically, as the number of blocks processed grows, it ceases to be a factor.\n\nMy key point, or key question....Do those with faster computers have an advantage, or do they not?  In the general forums people claim that the \"luck\" factor makes up for this...but statistics beg to differ.  Granted, and I do agree, the point is trading, not generation, but essentially with generation we're handing out free (though inflating) money.  I would like to think that the process is equitable and not based upon one's ability to afford, in USD, a beast of a machine.  This would loosely tie the initial distribution of BTC to the present distribution of USD of those willing to contribute...and seems to undermine the currency philosophically, apart from being unfair.\n\nThanks for all the hearty discussion on the matter, everyone."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2736#msg2736"},{"f":"knightmb","d":1279080017,"b":[["q","My key point, or key question....Do those with faster computers have an advantage, or do they not?  In the general forums people claim that the \"luck\" factor makes up for this...but statistics beg to differ.  Granted, and I do agree, the point is trading, not generation, but essentially with generation we're handing out free (though inflating) money.  I would like to think that the process is equitable and not based upon one's ability to afford, in USD, a beast of a machine.  This would loosely tie the initial distribution of BTC to the present distribution of USD of those willing to contribute...and seems to undermine the currency philosophically, apart from being unfair.\n\nThanks for all the hearty discussion on the matter, everyone.","Quote from: InterArmaEnimSil on July 14, 2010, 03:31:23 AM"],["t","Yes, they do. If the old PC can only generate 1 block in 48 hours and the super fast modern PC can generate 1 block in 12 hours, then statistically, the old PC is 4 times as slow as the modern PC during coin generation. The difference is the luck factor. It's possible that the old PC will find a crypto solution by pure luck in less time. So it's possible that the old PC finds one in 2 hours while the super fast PC has to burn through the entire brute force before finding a block in 12 hours. So the advantage is the odds. Simplified of course, but yes, the faster PC gives you a 1 in 12 chance to get the solution and the old PC gives you a 1 in 48 chance (again, way over simplified example)\n\nSo the faster PC is like having a few extra lottery tickets  Wink"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2739#msg2739"},{"f":"InterArmaEnimSil","d":1279094385,"b":[["q","Yes, they do. If the old PC can only generate 1 block in 48 hours and the super fast modern PC can generate 1 block in 12 hours, then statistically, the old PC is 4 times as slow as the modern PC during coin generation. The difference is the luck factor. It's possible that the old PC will find a crypto solution by pure luck in less time. So it's possible that the old PC finds one in 2 hours while the super fast PC has to burn through the entire brute force before finding a block in 12 hours. So the advantage is the odds. Simplified of course, but yes, the faster PC gives you a 1 in 12 chance to get the solution and the old PC gives you a 1 in 48 chance (again, way over simplified example)\n\nSo the faster PC is like having a few extra lottery tickets  Wink","Quote from: knightmb on July 14, 2010, 04:00:17 AM"],["t","Given our sample size of 67082 runs, I think that luck is ironed out by statistics at this point.  Finding a crypto solution by \"luck\" would imply that the machines began the calculations at a different starting point in instruction sequence, wouldn't it?  However, if my machine does, say, 100MFLOPS, and begins a 10-trillion operation procedure to decode a block, and another machine with 1GFLOPS begins the same procedure at ANY time when I'm not 90% done with the process, then the faster machine will always finish faster, will it not?  These are deterministic machines working on deterministic problems, with finite starting and ending points and X number of steps in between....I fail to see where luck comes in to play.\n\nOn the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.\n\nOne question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done?  In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally.  Anyone care to shed any clarity on the situation?"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2776#msg2776"},{"f":"Insti","d":1279101774,"b":[["q","Given our sample size of 67082 runs, I think that luck is ironed out by statistics at this point.  Finding a crypto solution by \"luck\" would imply that the machines began the calculations at a different starting point in instruction sequence, wouldn't it?  However, if my machine does, say, 100MFLOPS, and begins a 10-trillion operation procedure to decode a block, and another machine with 1GFLOPS begins the same procedure at ANY time when I'm not 90% done with the process, then the faster machine will always finish faster, will it not?  These are deterministic machines working on deterministic problems, with finite starting and ending points and X number of steps in between....I fail to see where luck comes in to play.","Quote from: InterArmaEnimSil on July 14, 2010, 07:59:45 AM"],["t","Everybody is working on a different problem.\n\nI am trying to find a hash for a block which includes a transaction paying ME 50 BTC, you are trying to find the hash for a block which includes a transaction paying YOU 50BTC. These blocks will be different, so the nonce value required to hash them below the target value will be different."],["q","On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.","Quote"],["t","I have an old slow machine that is only getting about 80khash/s, I managed to generate a block when the difficulty was 23. That seems pretty lucky to me."],["q","One question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done?  In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally.  Anyone care to shed any clarity on the situation?","Quote"],["t","Once a valid block comes through, everyone stops working on the one they were working on and starts working on the next block.\nIt doesn't really matter if you start a few seconds before anyone else, because you're working on a different problem as I explained above."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2790#msg2790"},{"f":"knightmb","d":1279119729,"b":[["q","On the other hand, as I have a rather slow (but not ancient) laptop, I'd LIKE to see how luck comes into the equation...so if anyone can fill me, in, please do so.\n\nOne question...Do machines cease work on a block upon discovery that it has been finished first by someone else, or does everyone keep working on a block until he/she is done?  In this case, it is conceivable that if I happen to start the next block at the right time, I could \"by luck\" finish first...on the other hand, if machines all discard their current block when it is finished by someone else, then everyone is beginning the blocks at roughly the same time, and the fastest machines will win almost universally.  Anyone care to shed any clarity on the situation?","Quote from: InterArmaEnimSil on July 14, 2010, 07:59:45 AM"],["t","From what I've read, when a new block is discovered, the other machines will take a few milliseconds to verify if it's real or not first because say two people's computer discovered a solution within a second of each other. How do we know who the winner is? Well, again more luck. Other people's computers have to verify that your PC wasn't cheating/stupid/error/etc for the block. After a hundred or more confirmations, it's accepted by the \"group\" that your PC founding the winning block and everyone assigns the credit to your PC. So when two computers at the same time find the block, it's more luck on how fast it will be accepted by the group by how many other people's computers verify your find.\n\nThe chain is updated and if your neighbors computer was working on block 66777, it hears the news that your found the winning block and says \"well, time to start on the next block\" and begins the calculations over. Now your computer and your neighbors computer are working on block 66778, but each is doing it's own unique brute force. They aren't both working on the same brute force for the same block, otherwise, the fastest computer would always win over and over. The faster computer does have an advantage that it can brute force the next find faster than the slow guy, but the slow guy still has luck on his side.\n\nNow imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet  Wink  I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2839#msg2839"},{"f":"Strofcon","d":1279123325,"b":[["q","Now imagine this with thousands of PCs out there playing the lotto every second. Just because you have a quad-core system churning 2,400 khash/s doesn't mean you are going to win every time. It makes your odds better of course, but by no means is it a sure thing just because of the raw CPU power you have. Ask the people at this forum who are running this on a server farm (like myself) and you'll see. I'm churning 10,000 khash/s on one of my systems (6 cpu) and it hasn't won a single block yet  Wink  I'm not bitter though, it proves to me that the system is being fair in the block generation, so I'm happy actually.","Quote from: knightmb on July 14, 2010, 03:02:09 PM"],["t","This is a good point. My weaker PC is barely squeaking out 1,000 khash/s on two cores, and has netted me 100 coins in less than 48 hours. My server, on the other, hitting closer to 1,200 khash/s on two cores (not a huge bump, but still more), and has been running for about 12 hours longer than the other and has netted me 0 coins. So, like knightmb said... there's hope still. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2860#msg2860"},{"f":"InterArmaEnimSil","d":1279134423,"b":[["t","Okay - if everyone's machines are working on a hash to a different problem, then I can see how luck would be a factor.  However, what is the source of the variation between the problem my machine is working on, the problem yours is, etc?  One reply earlier seemed to imply that it had to do with transactions in which the individual recently took part....but what about those of us not taking part in any recent transactions? (My most recent one is at least two days old now)"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2916#msg2916"},{"f":"knightmb","d":1279135063,"b":[["q","Okay - if everyone's machines are working on a hash to a different problem, then I can see how luck would be a factor.  However, what is the source of the variation between the problem my machine is working on, the problem yours is, etc?  One reply earlier seemed to imply that it had to do with transactions in which the individual recently took part....but what about those of us not taking part in any recent transactions? (My most recent one is at least two days old now)","Quote from: InterArmaEnimSil on July 14, 2010, 07:07:03 PM"],["t","In terms of Coin Generation, you need only be connected to the network. That's all that is needed for your computer to broadcast \"I found it!!\" message and for other computers to check if it's valid. Since blocks are being generated on a constant basis, doing offline Coin generation won't be practical. Because if 2 days ago your computer found a block, but so did mine and my PC was online the whole time, mine will be proclaimed the winner/owner of that Coin by the network as a whole. Your PC comes in 2 days later and broadcast that it has the same solution and the other computers will just snide a \"too late, XYZ already solved it, better luck next time\".\n\nIn terms of variation between problems, when a block is found, everyone starts on the next block. So if your computer was only 1% towards solving block 68000 and got the message \"XYZ solved the block 68000 just a few minutes ago\", your PC thinks \"well, on to the next one\". It doesn't waste CPU trying to solve a block that was already solved by someone else. That's where the verification part comes in. Otherwise, someone would just hack together a client that broadcast \"I solved block 68000, 680001, 68002, etc\" to claim ownership of the entire range. When a client says it solved a block, all the other computers say \"ok, well prove it then, send me your results\". When enough of them talk to each other about it, they will agree that \"yes, your PC solved block 68000, you are the new owner, congratulations\".\n\nThe key part is that it takes hours/days for our PCs to solve a block, but only milliseconds for everyone else to check if it's true. That prevents a \"fake block found\" attack from happening on the network.\n\nAnother example, you have a room with hundreds of people in it. Everyone is given a randomly mixed up Rubix cube to solve. The first one to solve his/her cube gets 50 coin.\n\nNow if someone shouts \"I solved it\", it won't take but a mere glance from the surrounding people to tell if it's true or not (solid colors on all sides) If someone shouts \"I solved it\" and it's still a jumbled mess, well everyone just ignores that person and continues on. The first person who solves it for \"real\" wins the prize and then everyone throws away their current Rubix cube and a bunch more randomly mixed Rubix cubes drop from the ceiling to start the process all over again."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2917#msg2917"},{"f":"InterArmaEnimSil","d":1279135800,"b":[["q","In terms of variation between problems, when a block is found, everyone starts on the next block. So if your computer was only 1% towards solving block 68000 and got the message \"XYZ solved the block 68000 just a few minutes ago\", your PC thinks \"well, on to the next one\". It doesn't waste CPU trying to solve a block that was already solved by someone else.","Quote from: knightmb on July 14, 2010, 07:17:43 PM"],["t","But the problem for solving block X is the same across all the computers, right?  So they have a starting point, an algorithm for finding the hash, and a processor.  Each starts churning away at the instruction sequence...fastest one wins.  I still don't see the luck."],["q","...randomly mixed Rubix cubes drop from the ceiling to start the process all over again.","Quote from: knightmb on July 14, 2010, 07:17:43 PM"],["t","So the starting point for the crypto hash problems is different for the various nodes?  This would make sense - if a slow machine happened to get a block that needed only 100,000 steps to solve, but a fast machine happened to get a block that needed 10 trillion steps, the slow machine might \"win.\"  My question remains, though.  What is the source of the variation between starting points?  How are the differences created?  Obviously, if every machine starts in the same place each time, the fastest machine always wins...so from where do the different starting points come?"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2923#msg2923"},{"f":"laszlo","d":1279136031,"b":[["t","Aside from the housekeeping fields needed to make sense of the data, the rest of the data that is being hashes is just random.  Everyone's is different and you never get any closer to solving it.  Every time it is twiddled and re-hashed you have the same chance of finding a solution.  This is just like buying raffle tickets.  Everyone's numbers are different and they could all be winners, however the guy who gets more raffle tickets might win more often, if this process was repeated over and over.  Computers that can try hashing faster have more raffle tickets but every hash calculation has the same chance of being a winner."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2925#msg2925"},{"f":"Strofcon","d":1279137002,"b":[["t","Take this lightly until confirmed, but here's my understanding...\n\nThere is no variation in the problem itself - every node is intended to work on the same block at the same time (accounting for latencies and such). The luck factor is really the random number generated at the beginning of each node's attempt to solve a new block. When a new block needs to be solved, each node generates a random value (nonce), which is used to hash the block. If that hash isn't the right one, the nonce is incremented, and the new incremented value is used to hash the block again.\n\nSay my clunker manages 1,000 khash/s (which it really does...  Sad), and you have a cluster that cranks out 100,000 khash/s, there's still a reasonable chance that my clunker will randomly (and very luckily) land on the value that solves the block within a very small number of hashes... say my nonce is a winner after only 10 hashes. I'm working out 1,000,000 hashes per second, so it only took me 1/100,000 of a second to solve the block. You cluster would have to (again, luckily) generate the right nonce in less than 0.00001 seconds to beat my lucky guess... which means your cluster would have guess correctly in less than 100,000,000 (hash/s) / 100,000 (s) = 1,000 hashes. Given the huge number of hashes possible, the likelihood of you hitting it in under 1,000 is remarkably low...\n\nGranted, my chances of hitting it in under 10 hashes was even more insanely low, but you get the idea I think. So yes, the cluster will, overall, solve more blocks than my clunker, but it won't win out every single time.\n\nNow that I've gone through all that... I'm sure someone will point out a flaw in my reasoning! Smiley I'm fine with that though, I want to make sure I understand it all correctly!\n\nEdit - Laszlo said it much more conscisely, but I think we made the same point...? Hopefully!"]],"u":"https://bitcointalk.org/index.php?topic=325.msg2927#msg2927"},{"f":"theymos","d":1279137505,"b":[["t","In addition the the random nonce, each block also contains a BitCoin address (newly-generated, used only for this purpose) that the 50 BC reward is credited to if you solve a block. Even if two nodes choose the same random nonce to start at (which is unlikely), they're pretty much guaranteed to have different BitCoin addresses."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2928#msg2928"},{"f":"satoshi","d":1279139106,"b":[["q"," So if your computer was only 1% towards solving block 68000 ","Quote from: knightmb on July 14, 2010, 07:17:43 PM"],["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=325.msg2935#msg2935","s":1,"n":187,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/187/"}]},{"id":"p97","k":"p","s":"bitcointalk","t":"UPDATED - Linux x64 bins for those having libcrypto and GLIBCXX_3.4.11 troubles","u":"https://bitcointalk.org/index.php?topic=326","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/97/","m":[{"f":"laszlo","d":1279045964,"b":[["t","This is mostly for those having troubles on fedora with newer openssl than the binaries on the front page of the site were built with.\n\nPlease try these or compile yourself using these instructions: http://heliacal.net/~solar/bitcoin/bitcoin-linuxbuild.pdf\n\nhttp://heliacal.net/~solar/bitcoin/builds/Linux-amd64-SVN-102/"]],"u":"https://bitcointalk.org/index.php?topic=326.msg2607#msg2607"},{"f":"diven","d":1279059835,"b":[["t","Thanks!\n\nWorks on Slackware64 13.1."]],"u":"https://bitcointalk.org/index.php?topic=326.msg2668#msg2668","sj":"Re: Static Linux x86_64 bins for those having libcrypto troubles"},{"f":"dougztr","d":1279083767,"b":[["t","No dice on my Gentoo system. I get the following.\n\n$ bitcoin\nbitcoin: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by bitcoin)\n\nand then\n\n$ ldd bitcoind\n./bitcoind: /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./bitcoind)\n   linux-vdso.so.1 =>  (0x00007fffc9bff000)\n   libdl.so.2 => /lib/libdl.so.2 (0x00007ffeefbe1000)\n   libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/libstdc++.so.6 (0x00007ffeef8d3000)\n   libm.so.6 => /lib/libm.so.6 (0x00007ffeef64e000)\n   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ffeef437000)\n   libpthread.so.0 => /lib/libpthread.so.0 (0x00007ffeef21a000)\n   libc.so.6 => /lib/libc.so.6 (0x00007ffeeeea4000)\n   /lib64/ld-linux-x86-64.so.2 (0x00007ffeefde5000)\n\nThis file isn't statically linked. I'm only trying to use it because my gentoo system is in a bad state and will take some time to get upgraded to build the source code.\n\nAnyways, thought I'd send a bug report"]],"u":"https://bitcointalk.org/index.php?topic=326.msg2753#msg2753","sj":"Re: Static Linux x86_64 bins for those having libcrypto troubles"},{"f":"Ground Loop","d":1279156037,"b":[["t","I get the same:\n`GLIBCXX_3.4.11' not found\non Debian.\n\nThe libg++ is not as new as the one bitcoind was compiled with, and the newer one is not available in stable."]],"u":"https://bitcointalk.org/index.php?topic=326.msg3025#msg3025","sj":"Re: Static Linux x86_64 bins for those having libcrypto troubles"},{"f":"laszlo","d":1279158997,"b":[["t","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 Smiley"]],"u":"https://bitcointalk.org/index.php?topic=326.msg3048#msg3048","sj":"Re: Static Linux x86_64 bins for those having libcrypto troubles"},{"f":"satoshi","d":1279204384,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=326.msg3157#msg3157","s":1,"n":191,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/191/","sj":"Re: Static Linux x86_64 bins for those having libcrypto troubles"}]},{"id":"p98","k":"p","s":"bitcointalk","t":"resource hog","u":"https://bitcointalk.org/index.php?topic=327","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/98/","m":[{"f":"andy_3_913","d":1279048787,"b":[["t","i've read through the forums, seen a few topics...\nbut...\nthis program really does slow things down.\ndon't really understand why, if it's supposed to give priority to other progs.\nbut, crap, makes my system move like it's walking through treacle!!\n\nnot a great system,\npentium d, 2.8 mhz each cpu.\n3 gb ram\nwindows 7 home 64"]],"u":"https://bitcointalk.org/index.php?topic=327.msg2624#msg2624"},{"f":"SmokeTooMuch","d":1279050337,"b":[["t","I guess you are still at the initial download of the current block chain.\nuntil your blockcount is around 66k you still have to download the blocks and verify them. this takes quite some hard-drive performance, so maybe thats what is slowing down your system."]],"u":"https://bitcointalk.org/index.php?topic=327.msg2628#msg2628"},{"f":"andy_3_913","d":1279053481,"b":[["t","i'm sorry, but no!\ni started at 666## something, ages ago. now up to 66812\nand got my 5 freebies Smiley\nstill got max cpu usage?"]],"u":"https://bitcointalk.org/index.php?topic=327.msg2639#msg2639"},{"f":"laszlo","d":1279053596,"b":[["t","It will always use max CPU to generate but the generating thread is scheduled at a low priority so it should yield to other processes.  I can compile code and do other things on my windows machine with 0.3 running and it doesn't seem to slow it down for me at least."]],"u":"https://bitcointalk.org/index.php?topic=327.msg2641#msg2641"},{"f":"andy_3_913","d":1279054154,"b":[["q","It will always use max CPU to generate but the generating thread is scheduled at a low priority so it should yield to other processes.  I can compile code and do other things on my windows machine with 0.3 running and it doesn't seem to slow it down for me at least.","Quote from: laszlo on July 13, 2010, 08:39:56 PM"],["t","thanks for the quick answer Smiley\n\ni have bitcoin running, gomez peer and BOINC.\nthere is definitely a major slow down.\nif i have bitcoin running, and click on gomez icon, it takes a good 30+seconds to open. should be instantaneous!!\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=327.msg2642#msg2642"},{"f":"andy_3_913","d":1279055363,"b":[["t","while i'm at it.\nprobably totally wrong place, but,...\n248 confirmations and my address has changed. why has my address changed. please? Smiley\nHELP!!!\nhehe Smiley"]],"u":"https://bitcointalk.org/index.php?topic=327.msg2645#msg2645"},{"f":"laszlo","d":1279056275,"b":[["t","It generates a new address and puts it in the main window for you if a payment is received for the previous address.  This is so each time you click 'copy to clipboard' to send it to someone, it's easier to get a unique one.  The old one is still valid and it's still in your address book.\n\nTry renicing bitcoin and see if it helps.   Find the pid in top or ps and then renice +19 1234 where 1234 is the pid."]],"u":"https://bitcointalk.org/index.php?topic=327.msg2652#msg2652"},{"f":"SmokeTooMuch","d":1279056486,"b":[["q","windows 7 home 64","Quote from: andy_3_913 on July 13, 2010, 07:19:47 PM"],["t","I don't think their is any renicing under Windows."]],"u":"https://bitcointalk.org/index.php?topic=327.msg2653#msg2653"},{"f":"theymos","d":1279067295,"b":[["q","> Quote from: andy_3_913 on July 13, 2010, 07:19:47 PM\n> windows 7 home 64\nI don't think their is any renicing under Windows.","Quote from: SmokeTooMuch on July 13, 2010, 09:28:06 PM"],["t"," Wink\nC:\\Windows\\System32\\cmd.exe /c start \"BitCoin\" /LOW /MIN \"C:\\Program Files\\Bitcoin\\bitcoin.exe\""]],"u":"https://bitcointalk.org/index.php?topic=327.msg2690#msg2690"},{"f":"satoshi","d":1279124979,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=327.msg2871#msg2871","s":1,"n":179,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/179/"},{"f":"andy_3_913","d":1279202409,"b":[["q","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.\n\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.\n\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.","Quote from: satoshi on July 14, 2010, 04:29:39 PM"],["t","thanks every one for your help Smiley\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%"]],"u":"https://bitcointalk.org/index.php?topic=327.msg3149#msg3149"},{"f":"satoshi","d":1279205940,"b":[["t","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%."]],"u":"https://bitcointalk.org/index.php?topic=327.msg3162#msg3162","s":1,"n":192,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/192/"}]},{"id":"p99","k":"p","s":"bitcointalk","t":"wiki registration email?","u":"https://bitcointalk.org/index.php?topic=338","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/99/","m":[{"f":"fernly","d":1279080561,"b":[["t","I tried to register with the wiki, it said \"The user has been created and the password sent by email,\" but no email has arrived. Then I went thru the registration process again, same username and email, and it didn't object to the duplication (nor sent an email)."]],"u":"https://bitcointalk.org/index.php?topic=338.msg2743#msg2743"},{"f":"sirius","d":1279082168,"b":[["t","Have you checked your spam folder?"]],"u":"https://bitcointalk.org/index.php?topic=338.msg2748#msg2748"},{"f":"RHorning","d":1279933918,"b":[["q","Have you checked your spam folder?","Quote from: sirius-m on July 14, 2010, 04:36:08 AM"],["t","I'm having the same problems.\n\nYes, I checked my spam folder.  I've even created a second account in case the first one I made a mistake on with the e-mail address.  Neither are working."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5418#msg5418"},{"f":"FreeMoney","d":1279934596,"b":[["t","I eventually got the email, very slow though."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5422#msg5422"},{"f":"RHorning","d":1280047924,"b":[["q","I eventually got the email, very slow though.","Quote from: FreeMoney on July 24, 2010, 01:23:16 AM"],["t","How long is that supposed to take?  Weeks?  Months?"]],"u":"https://bitcointalk.org/index.php?topic=338.msg5664#msg5664"},{"f":"FreeMoney","d":1280055475,"b":[["t","12 hours? Not sure exactly because I went to bed and when I next checked it was there."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5677#msg5677"},{"f":"RHorning","d":1280066537,"b":[["q","12 hours? Not sure exactly because I went to bed and when I next checked it was there.","Quote from: FreeMoney on July 25, 2010, 10:57:55 AM"],["t","It has now been more than four days for me.... this time with three different accounts that I've used to apply.  I'm going to try another mail ISP just in case the host for bitcoins has somehow been blocked by the main ISP I'm using."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5689#msg5689"},{"f":"RHorning","d":1280148961,"b":[["t","As a follow-up, switching to a completely different ISP (I just created a new \"throw away\" e-mail account to see what was going on here) I was able to get the registration to be completed.  Still, bitcoins.org is on some kind of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5849#msg5849"},{"f":"theymos","d":1280158254,"b":[["q","As a follow-up, switching to a completely different ISP (I just created a new \"throw away\" e-mail account to see what was going on here) I was able to get the registration to be completed.  Still, bitcoins.org is on some kind of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.","Quote from: RHorning on July 26, 2010, 12:56:01 PM"],["t","Looks like bitcoin.org is listed <http://www.spamhaus.org/pbl/query/PBL340779> on the PBL."]],"u":"https://bitcointalk.org/index.php?topic=338.msg5884#msg5884"},{"f":"satoshi","d":1280369446,"b":[["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=338.msg6307#msg6307","s":1,"n":288,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/288/"}]},{"id":"p100","k":"p","s":"bitcointalk","t":"They want to delete the Wikipedia article","u":"https://bitcointalk.org/index.php?topic=342","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/100/","m":[{"f":"Giulio Prisco","d":1279092068,"b":[["t","http://en.wikipedia.org/wiki/Bitcoin\n\nThis article is being considered for deletion in accordance with Wikipedia's deletion policy.\nPlease share your thoughts on the matter at this article's entry on the Articles for deletion page.\n\nThis article needs references that appear in reliable third-party publications. Primary sources or sources affiliated with the subject are generally not sufficient for a Wikipedia article. Please add more appropriate citations from reliable sources.\n\nThe recent Slashdot article should be considered as a reliable reference:\nhttp://news.slashdot.org/story/10/07/11/1747245/Bitcoin-Releases-Version-03\n\nI cannot edit at this moment, can you guys save the WP artcile?"]],"u":"https://bitcointalk.org/index.php?topic=342.msg2771#msg2771"},{"f":"Stone Man","d":1279094263,"b":[["t","Thanks for the heads up. I added a section titled \"Recent appearance in the news.\""]],"u":"https://bitcointalk.org/index.php?topic=342.msg2774#msg2774"},{"f":"joechip","d":1279105646,"b":[["t","The WP page should discuss the maintenance cost of the p2p network.  Not only are there costs associated with the generation of the bitcoins, but their value can only be maintained as long as the 'proof-of-work' network is available and stable.\n\nThis cost, of course, is difficult to calculate but it is non-zero, though it may be trivial.  There is opportunity cost associated with the storage and maintenance of the network itself.  This could be seen as analogous to third-party gold storage fees."]],"u":"https://bitcointalk.org/index.php?topic=342.msg2795#msg2795"},{"f":"RHorning","d":1279510322,"b":[["t","This is mainly a notice to the Bitcoin community that the article about Bitcoins on Wikipedia is being deleted.\n\nhttp://en.wikipedia.org/wiki/Bitcoin\n\nFrom my own perspective, I think that the rationale for its deletion is valid, as there is little in the way of 3rd party discussions of Bitcoins and their role in alternate currencies, other than discussions on this forum.  On the other hand, if there is anybody in the Bitcoin community that is aware of a presentation about Bitcoins at a scholarly conference, some sort of published scholarly paper, or something that perhaps is even in a \"mainstream\" news source.... it would be appreciated to either note that link here or on that Wikipedia article.\n\nThe reason for the deletion is non-notability.  In other words, nobody outside of the Bitcoin community is really paying attention to the currency or saying much about it.  There needs to be some better public relations and discussion beyond personal blogs and such.  Yes, I get that this is a chicken or egg situation where if an article like this is deleted that nobody will hear about it either, but it is an issue.\n\nOn the other hand, if you are a student (or better yet a professor) and want to make a splash about an interesting topic, this could be something useful to not just the project but also to help spread the word about this project.  There is a need to do some real scholarship about Bitcoins, the people involved with getting it going, and how it is different (or the same) from other alternative currencies.  Such a paper wouldn't hurt, and could be useful for a number of reasons... not just writing Wikipedia articles."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4157#msg4157","sj":"Deletion of Bitcoin Wikipedia Article"},{"f":"Bitcoiner","d":1279560053,"b":[["t","Once deleted, are the contents of the article lost forever, or can they be restored at some point?"]],"u":"https://bitcointalk.org/index.php?topic=342.msg4294#msg4294","sj":"Re: Deletion of Bitcoin Wikipedia Article"},{"f":"mtgox","d":1279560963,"b":[["q","Once deleted, are the contents of the article lost forever, or can they be restored at some point?","Quote"],["t","They can be restored."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4297#msg4297"},{"f":"Traktion","d":1279561684,"b":[["t","Haven't there been articles on slashdot, ronpaul.com and other places? I've found quite a few links on Googling."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4303#msg4303"},{"f":"RHorning","d":1279565839,"b":[["q","Haven't there been articles on slashdot, ronpaul.com and other places? I've found quite a few links on Googling.","Quote from: Traktion on July 19, 2010, 05:48:04 PM"],["t","None of which are considered credible sources on Wikipedia.  ronpaul.com is about as good as it gets, and that still is just an ordinary blog entry from a site participant than something that is a credible independent source.\n\nSlashdot in particular was something generated by fans of Bitcoins and was talked about extensive on this forum before it was even posted.  Not that it was something bad for Slashdot, but that isn't how Wikipedia works.  Essentially Bitcoins still hasn't become a part of the larger world culture yet.\n\nThe purpose of this work for credible sources of information and insistence on reliable 3rd party accounts is in part to keep people like \"UFO Researchers\" and others with fringe theories from taking over Wikipedia.  Anybody can come up with some theory that may seem credible, but nobody is really taking seriously.  You need to demonstrate that others outside of your immediate community at least consider the concept to be credible and at least worth criticism.  None of this is happening with Bitcoins at the moment."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4317#msg4317"},{"f":"FreeMoney","d":1279577629,"b":[["t","I don't really get it, if there was a group of 11,000 UFO researchers who called themselves UFORO and spent hours every night searching would they get no article unless someone who did not want to join took them seriously enough to write peer reviewed papers?\n\nI think BitCoin has great potential, blah blah, but that doesn't matter. Thousands of people are doing something that's at least moderately interesting. I can't see what the harm of putting a neutrally worded article in the worlds largest encyclopedia is. It isn't like the thing is going to get to heavy to sit on a shelf."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4364#msg4364"},{"f":"NewLibertyStandard","d":1279578452,"b":[["t","The idea behind bitcoin has been around in research white papers for years. I imagine we should be able to list such research papers as a source. Bitcoins is the first time this theoretical idea which has been around for quite a while, has actually been implemented. I don't have sources available at the moment, but if I get some time, I'll try to look around. If anybody can find these historical research papers and discussions from before Bitcoin was started, please post links to them."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4371#msg4371"},{"f":"bdonlan","d":1279593038,"b":[["q","I don't really get it, if there was a group of 11,000 UFO researchers who called themselves UFORO and spent hours every night searching would they get no article unless someone who did not want to join took them seriously enough to write peer reviewed papers?\n\nI think BitCoin has great potential, blah blah, but that doesn't matter. Thousands of people are doing something that's at least moderately interesting. I can't see what the harm of putting a neutrally worded article in the worlds largest encyclopedia is. It isn't like the thing is going to get to heavy to sit on a shelf.","Quote from: FreeMoney on July 19, 2010, 10:13:49 PM"],["t","The thing is, if they allow an exception to the policy once, then people will ask for exceptions _all the time_. The rule is really quite simple: \"significant coverage in reliable sources that are independent of the subject\". Independent means the papers on bitcoin are out, as is the forum - after all, anything can have lots of non-independent sources. And a single slashdot article is clearly not 'significant coverage' (or reliable coverage Wink."],["q","The idea behind bitcoin has been around in research white papers for years. I imagine we should be able to list such research papers as a source. Bitcoins is the first time this theoretical idea which has been around for quite a while, has actually been implemented. I don't have sources available at the moment, but if I get some time, I'll try to look around. If anybody can find these historical research papers and discussions from before Bitcoin was started, please post links to them.","Quote from: NewLibertyStandard on July 19, 2010, 10:27:32 PM"],["t","You can reference them, but they don't count for notability, as they either don't discuss bitcoin itself (and instead discuss the general concept), or they are not independent (ie, they're written by Satoshi)."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4415#msg4415"},{"f":"FreeMoney","d":1279617113,"b":[["t","Clearly the wiki community knows how to run an open encyclopedia, and clearly I'm biased. I still feel the need to say though that the \"human race\" has not been independent verified. It's only those damn humans ever talk about it."]],"u":"https://bitcointalk.org/index.php?topic=342.msg4433#msg4433"},{"f":"dwdollar","d":1279648185,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=342.msg4502#msg4502"},{"f":"satoshi","d":1279651108,"b":[["t","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\n\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?\n\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.\n\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.\n\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.\n\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.  (edit: or at least I assume so, that's how the world usually works, but maybe Wiki is different)"]],"u":"https://bitcointalk.org/index.php?topic=342.msg4508#msg4508","s":1,"n":249,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/249/","qt":["The 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."],"qc":["general"]}]},{"id":"p101","k":"p","s":"bitcointalk","t":"stopped prodicing coins","u":"https://bitcointalk.org/index.php?topic=343","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/101/","m":[{"f":"devnull791101","d":1279098759,"b":[["t","Hi\n\nim using the 64bit linux version. i installed two days ago and produced three lots of 50 coins. yesterday i produced 50 coins within two hours of the last lots completing and have had no others even starting since then. the last lots completed 8:51 am yesterday and its now 10am the next morning and ive got no transactions working at all. have i been snubbed for completing the last two too quickly? if so how long does this last?"]],"u":"https://bitcointalk.org/index.php?topic=343.msg2785#msg2785"},{"f":"joechip","d":1279106364,"b":[["q","Hi\n\nim using the 64bit linux version. i installed two days ago and produced three lots of 50 coins. yesterday i produced 50 coins within two hours of the last lots completing and have had no others even starting since then. the last lots completed 8:51 am yesterday and its now 10am the next morning and ive got no transactions working at all. have i been snubbed for completing the last two too quickly? if so how long does this last?","Quote from: devnull791101 on July 14, 2010, 09:12:39 AM"],["t","I've been generating for nearly two days straight and have not produced a single coin.  It seems distribution is completely random."]],"u":"https://bitcointalk.org/index.php?topic=343.msg2798#msg2798"},{"f":"SmokeTooMuch","d":1279107292,"b":[["t","The production rate depends on your hashs per second and the probability of 1 hash to be the right one.\n\nso basically khash/s * luck factor = generaterd bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=343.msg2803#msg2803"},{"f":"joechip","d":1279107746,"b":[["q","The production rate depends on your hashs per second and the probability of 1 hash to be the right one.\n\nso basically khash/s * luck factor = generaterd bitcoins.","Quote from: SmokeTooMuch on July 14, 2010, 11:34:52 AM"],["t","Given the current jump in 'difficulty' at around 875 khash/s I should be generating a block every 2.8 days.\n\nSo, no complaints.... yet.   Grin\n\nhttp://www.alloscomp.com/bitcoin/calculator.php"]],"u":"https://bitcointalk.org/index.php?topic=343.msg2805#msg2805"},{"f":"satoshi","d":1279127042,"b":[["t","Thanks for making that calculator.\n\nThe difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells."]],"u":"https://bitcointalk.org/index.php?topic=343.msg2880#msg2880","s":1,"n":180,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/180/"}]},{"id":"p102","k":"p","s":"bitcointalk","t":"Hash() function not secure","u":"https://bitcointalk.org/index.php?topic=360","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/102/","m":[{"f":"bdonlan","d":1279147076,"b":[["t","Hi,\n\nThe Hash() function in util.h forms the backbone of most of bitcoin's crypto:"],["c","template<typename T1>\ninline uint256 Hash(const T1 pbegin, const T1 pend)\n{\n    uint256 hash1;\n    SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char*)&hash1);\n    uint256 hash2;\n    SHA256((unsigned char*)&hash1, sizeof(hash1), (unsigned char*)&hash2);\n    return hash2;\n}"],["t","As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!\n\nA better solution would be something like:"],["c","template<typename T1>\ninline vector<unsigned char> HashV(const T1 pbegin, const T1 pend)\n{\n    uint256 sharesult;\n    uint160 riperesult;\n    SHA256((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&sharesult);\n    RIPEMD160((unsigned char*)&pbegin[0], (pend - pbegin) * sizeof(pbegin[0]), (unsigned char *)&riperesult);\n\n    vector<unsigned char> ret;\n    ret.insert(ret.end(), (unsigned char *)(&sharesult), (unsigned char *)(&sharesult + 1));\n    ret.insert(ret.end(), (unsigned char *)(&riperesult), (unsigned char *)(&riperesult + 1));\n    return ret;\n}"],["t","The key is to concatenate the hashes, not merge them. This means the attacker has to break both hashes - even in the worst case, this cannot be less secure than a single hash.\n\nUnfortunately, changing hashes would break the chain..."]],"u":"https://bitcointalk.org/index.php?topic=360.msg2982#msg2982"},{"f":"bdonlan","d":1279147131,"b":[["t","Incidentally, a similar problem exists with Hash160, only worse - an attacker can break _either_ RIPEMD160 or SHA256, and win. At least with Hash() the attacker _must_ break SHA256."]],"u":"https://bitcointalk.org/index.php?topic=360.msg2983#msg2983"},{"f":"jib","d":1279154475,"b":[["t","The original hash isn't what you're trying to break. You're trying to break the hash bitcoin uses, which is the double hash."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3014#msg3014"},{"f":"Gavin Andresen","d":1279155921,"b":[["q","As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!","Quote from: bdonlan on July 14, 2010, 10:37:56 PM"],["t","If I understand correctly, you've got two chances to find a collision instead of one.\n\nSo this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal.  Bitcoin is using, essentially SHA255 instead of SHA256.  It'll still take longer than forever to find a collision..."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3024#msg3024"},{"f":"bdonlan","d":1279156947,"b":[["q","> Quote from: bdonlan on July 14, 2010, 10:37:56 PM\n> As you can see, this tries to be more secure by hashing twice. However, this actually reduces security. To break pure SHA256, an attacker needs to find a d' such that SHA256(d') == SHA256(d), for a known d. This is also sufficient to break Hash(). However the attacker can also attack the outer layer of the hash, finding a d' such that SHA256(SHA256(d')) == SHA256(SHA256(d)), even though SHA256(d') != SHA256(d). As you can see, the double hashing here makes it _easier_ to break the hash!\n\nIf I understand correctly, you've got two chances to find a collision instead of one.\n\nSo this decreases the security of SHA256 by a factor of 2... which is just Not a Big Deal.  Bitcoin is using, essentially SHA255 instead of SHA256.  It'll still take longer than forever to find a collision...","Quote from: gavinandresen on July 15, 2010, 01:05:21 AM"],["t","It's true that it's not a big deal, but what concerns me is that someone went out of their way to implement an unproven hashing method, without thinking it through to realize that it actually decreases security. Things like this reduce one's confidence in the system as a whole - after all, if such a mistake exists, what other problems may be lurking?\n\nWhat we really need is a documented protocol, so it can be audited by third parties. I'm working on reverse-engineering it from the source, but it's slow going - the intent of much of the scripting system is poorly documented."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3035#msg3035"},{"f":"theymos","d":1279158303,"b":[["t","You're trying to solve:\nSHA256(SHA256(d'))==256-bit number\n\nThis still has 256 bits of security, and you have to do two hashes per attempt to brute-force it."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3044#msg3044"},{"f":"knightmb","d":1279159957,"b":[["q","You're trying to solve:\nSHA256(SHA256(d'))==256-bit number\n\nThis still has 256 bits of security, and you have to do two hashes per attempt to brute-force it.","Quote from: theymos on July 15, 2010, 01:45:03 AM"],["t","I agree, basically I get what he is saying at the top, but it isn't as bad as everyone thinks.\n\nTo brute force your 256bit hash, you either guess the starting string or the second hash string. Which means you have to guess, convert to 256, convert to 256 again and see if that matches. If you attack the second hash, you can't start a guess at 0000000.....1 for example, you know it's already another 256bit number that have to start with. That's like trying to brute force a password and knowing ahead of time the guy's password was 100 digits long. Does it make it any easier? Well no because the first 99 digits could be 0 and the last 1 but either way you still have to try all in between.\n\nMathematically, I see no advantage. Either you guess the first string to generate the hash or guess the first hash that generates the second hash. Either way you are going to have to brute force the entire key-space to do this. The only advantage is that instead of having \"one\" correct answer, you have \"two\" correct answers out of the billion trillion million guesses possible.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3054#msg3054"},{"f":"Gavin Andresen","d":1279160916,"b":[["t","There's a stackoverflow <http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once> question about double hashing, by the way.  Consensus is that it's not less secure.  It's too late for my brain to process the nuances of hashing..."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3060#msg3060"},{"f":"Bitcoiner","d":1279161112,"b":[["t","Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3064#msg3064"},{"f":"bdonlan","d":1279161716,"b":[["q","Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.  Smiley","Quote from: Bitcoiner on July 15, 2010, 02:31:52 AM"],["t","Nope! At least, not easily - block and transaction identities are based on this hash, among other things, so this would break the chain. You'd need to do a phased rollout - first, add parsing support to all clients, then obsolete older clients, then roll out a new version which generates a new version of the block serialization format using the new hashing method."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3067#msg3067"},{"f":"theymos","d":1279161763,"b":[["t","I have no doubt that hashing multiple times is secure, since it is specified in PKCS #5 <http://tools.ietf.org/html/rfc2898> and other standards:"],["q","An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.","Quote"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3069#msg3069"},{"f":"Bitcoiner","d":1279164233,"b":[["q","> Quote from: Bitcoiner on July 15, 2010, 02:31:52 AM\n> Could this be fixed in the next release? We were just discussing what would happen if a flaw were found: Here we go, our first real test of the situation.  Smiley\nNope! At least, not easily - block and transaction identities are based on this hash, among other things, so this would break the chain. You'd need to do a phased rollout - first, add parsing support to all clients, then obsolete older clients, then roll out a new version which generates a new version of the block serialization format using the new hashing method.","Quote from: bdonlan on July 15, 2010, 02:41:56 AM"],["t","All the better to practice now, while the network is still young! Well, if it is not a real flaw, it's not necessary, but it would be good practice. This could always be done first in the test network."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3079#msg3079"},{"f":"jib","d":1279165954,"b":[["q","I have no doubt that hashing multiple times is secure, since it is specified in PKCS #5 <http://tools.ietf.org/html/rfc2898> and other standards:\n\n> Quote\n> An iteration count has traditionally served the purpose of increasing the cost of producing keys from a password, thereby also increasing the difficulty of attack. For the methods in this document, a minimum of 1000 iterations is recommended. This will increase the cost of exhaustive search for passwords significantly, without a noticeable impact in the cost of deriving individual keys.","Quote from: theymos on July 15, 2010, 02:42:43 AM"],["t","That quote is about using hashes to transform passwords, which is a different application to what Bitcoin is using SHA-256 for. I don't think the security issues in the two cases are analogous."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3085#msg3085"},{"f":"theymos","d":1279179474,"b":[["t","PKCS #5 is used by TrueCrypt (and GPG, I think). If each iteration reduced the difficulty of finding collisions, as bdonlan suggests, then TrueCrypt would be easy to break. You'd just attack the hashing algorithm to find the master key."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3109#msg3109"},{"f":"Some Mouse","d":1279197899,"b":[["q","There's a stackoverflow <http://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once> question about double hashing, by the way.  Consensus is that it's not less secure.  It's too late for my brain to process the nuances of hashing...","Quote from: gavinandresen on July 15, 2010, 02:28:36 AM"],["t","Note that that discussion is referring to hashing passwords - and the most upvoted comment is explicitly discussing such with that in mind. Trying to do a dictionary attack has no coherent meaning, and someone directly attacking the algorithms behind bitcoin would obviously not start there. It will attack the algorithm."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3145#msg3145"},{"f":"mcdett","d":1279209402,"b":[["t","What is being hashed in this function?  <-- let's call this item x\n\nIf the total number of possible x is smaller than 256bit space that sha256 provides than an attack would come in the form of a table of all sha256(x) values.\n\nIf all of the possible combination's of x is greater than the 256bit space, then here is some math for you (the attack would be at the hash value itself rather than a table on known sha256(x)):\n\nWhat follows is from www.atmel.com/dyn/resources/prod_documents/doc8668.pdf <http://www.atmel.com/dyn/resources/prod_documents/doc8668.pdf>\n\nIf there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.\n\nHere are some estimates of big numbers:\n\n2^66 Number of grains of sand on the earth\n2^76 Number of stars in the universe\n2^79 Avogadro's number. The number of carbon atoms in 12 grams of coal.\n2^96 Number of atoms in a cubic meter of water\n2^190 Number of atoms in the sun\n2^255 Number of attempts to find the key value from above\n\nBut what about very well funded entities such as the US National Security Agency (NSA)? Could they build a machine to crack a 256 bit key? Assume they could build a theoretical nanocomputer that executes 10^13 instructions per second (approximate rate of atomic vibrations) in a space of a cube with a side that is 5.43nm across (This is the approximate size of a silicon lattice10 atoms wide, or a crystal containing 1000 silicon atoms). Assume that it could calculate an attempt in 10 cycles. Such a computer the size of the earth would take more than 10^13 years (roughly 58 times the estimated age of the earth) to attack a 256 bit algorithm via brute force."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3174#msg3174"},{"f":"laszlo","d":1279216522,"b":[["t","I want some nanocomputers!"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3220#msg3220"},{"f":"Bitcoiner","d":1279217123,"b":[["q","What is being hashed in this function?  <-- let's call this item x\n\nIf the total number of possible x is smaller than 256bit space that sha256 provides than an attack would come in the form of a table of all sha256(x) values.\n\nIf all of the possible combination's of x is greater than the 256bit space, then here is some math for you (the attack would be at the hash value itself rather than a table on known sha256(x)):\n\nWhat follows is from www.atmel.com/dyn/resources/prod_documents/doc8668.pdf <http://www.atmel.com/dyn/resources/prod_documents/doc8668.pdf>\n\nIf there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.\n\nHere are some estimates of big numbers:\n\n2^66 Number of grains of sand on the earth\n2^76 Number of stars in the universe\n2^79 Avogadro's number. The number of carbon atoms in 12 grams of coal.\n2^96 Number of atoms in a cubic meter of water\n2^190 Number of atoms in the sun\n2^255 Number of attempts to find the key value from above\n\nBut what about very well funded entities such as the US National Security Agency (NSA)? Could they build a machine to crack a 256 bit key? Assume they could build a theoretical nanocomputer that executes 10^13 instructions per second (approximate rate of atomic vibrations) in a space of a cube with a side that is 5.43nm across (This is the approximate size of a silicon lattice10 atoms wide, or a crystal containing 1000 silicon atoms). Assume that it could calculate an attempt in 10 cycles. Such a computer the size of the earth would take more than 10^13 years (roughly 58 times the estimated age of the earth) to attack a 256 bit algorithm via brute force.","Quote from: mcdett on July 15, 2010, 03:56:42 PM"],["t","Quantum computing and encryption: http://stackoverflow.com/questions/2768807/quantum-computing-and-encryption-breaking"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3225#msg3225"},{"f":"SmokeTooMuch","d":1279218038,"b":[["q","If there are 256 bits in the key, then after 2^255 attempts the attacker has a 50% chance of finding the right key and after 2^256 attempts he has tried all possible keys and is guaranteed to have found the key.","Quote from: mcdett on July 15, 2010, 03:56:42 PM"],["t","That's true, but only when you brute-force every singe hash.\nThere are other know attacking methods for SHA algorithms, thats why it is planned to replace the SHA-2 family with SHA-3 soon.\n\nGerman source:"],["q","Als Reaktion auf die bekanntgewordenen Angriffe gegen SHA-1 hielt das National Institute of Standards and Technology (NIST) im Oktober 2005 einen Workshop ab, in dem der aktuelle Stand kryptologischer Hashfunktionen diskutiert wurde. NIST empfiehlt den Übergang von SHA-1 zu Hashfunktionen der SHA-2-Familie (SHA-224, SHA-256, SHA-384, SHA-512). Langfristig sollen diese durch einen neuen Standard SHA-3 ersetzt werden. Dazu ruft das NIST nach Vorbild des Advanced Encryption Standard (AES) zu einem Ausschreiben auf. Die endgültige Wahl und Benennung des Hash-Standards ist für 2012 vorgesehen.","Quote"],["t","http://de.wikipedia.org/wiki/Secure_Hash_Algorithm#Empfehlungen"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3235#msg3235"},{"f":"Some Mouse","d":1279235189,"b":[["q","...\n\n2^255 Number of attempts to find the key value from above","Quote from: mcdett on July 15, 2010, 03:56:42 PM"],["t","1) Your equations don't take into account reversible computing advancements at all. These techniques could halve the search space by being able to take advantage of algorithms that traditional computers find impossible.\n\n2) Your equations assume the algorithm is perfectly secure. Given that NIST is rather gung ho about developing SHA-3, I'm not terribly confident in that analysis.\n\n3) An attacker does not need to find a specific key to compromise the system, they just need to find the keys to someone's wallet. If you want this to be a viable currency for Earth's population, plus corporate accounts, you drop the search space by 10^10 to 10^12.\n\nThat 2^256 search space could get whittled down to the 2^110 range by the end of the century. Assuming no major attacks on its integrity exist.\n\nI'm not particularly sold on the technical soundness of this program, honestly. Why use SHA256 rather than Whirlpool or SHA512? "]],"u":"https://bitcointalk.org/index.php?topic=360.msg3317#msg3317"},{"f":"knightmb","d":1279237369,"b":[["q","I'm not particularly sold on the technical soundness of this program, honestly. Why use SHA256 rather than Whirlpool or SHA512?","Quote from: Some Mouse on July 15, 2010, 11:06:29 PM"],["t","For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000\n\nThere are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it, are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?\n\nWhen they can crack SHA256 in under 10 minutes, I'll be worried, but until then, time is on your side."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3324#msg3324"},{"f":"Some Mouse","d":1279239232,"b":[["q","For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000","Quote from: knightmb on July 15, 2010, 11:42:49 PM"],["t","No. SHA512 and Whirlpool exist, are well defined, well supported, well analyzed, and they exist for a reason."],["q","There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it,","Quote"],["t","Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.\n\nYou are basically betting the entire economy (if you believe bitcoins will succeed anyway) on no one developing a means to halve the effective bit length as has been done with e.g. AES.\n\nIt's careless."],["q"," are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?","Quote"],["t","Ten years, assuming only minor flaws in SHA256.\n\nIf there is a major flaw (again, see the push for SHA-3) there is a much more serious problem. There does not appear to be a clear mechanism for handling a compromise of the basic algorithm, and there should be."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3334#msg3334"},{"f":"knightmb","d":1279242013,"b":[["q","> Quote from: knightmb on July 15, 2010, 11:42:49 PM\n> For the same reason they didn't use SHA1024 or SHA2048 or SHA4048 or SHA1000000000000000000000000000000000\n\nNo. SHA512 and Whirlpool exist, are well defined, well supported, well analyzed, and they exist for a reason.","Quote from: Some Mouse on July 16, 2010, 12:13:52 AM"],["t","I'm sure the same was said back when 40, 64, 128, and 256 bit encryption was coming out. SHA512 is part of SHA2, I remember when everyone was talking about how insecure SHA1 was with that significant *flaw* and how we all need to move to SHA2 because it was well defined, well supported, and well analyzed; sound familiar?"],["q","> Quote\n> There are lots of theoretical attacks that can be done against it, but if a program or new math proof can half the amount of time it takes to crack it,\n\nReversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.\n\nYou are basically betting the entire economy (if you believe bitcoins will succeed anyway) on no one developing a means to halve the effective bit length as has been done with e.g. AES.\n\nIt's careless.","Quote"],["t","I'm not betting anything for the simple fact that unless you can see into the future, we work with what we have in front of us. We can debate all day that in the future computers will be a million times faster or that some math genius is going to discover a flaw in the system that would bring everything down. I'm well aware of many peer reviewed papers and tech journals, even blogs about encryption. Not everything in existence, as I don't have the time for all of it, but enough practical experience to be able to visualize what it would really take to do what you propose."],["q","> Quote\n>  are we really worried about the encryption taking 100 billion years to crack but now with this new attack (insert math,attack,flaw) it's only going to take only 1 billion years to crack? How about a million years? Even one-hundred thousand years?\n\nTen years, assuming only minor flaws in SHA256.\n\nIf there is a major flaw (again, see the push for SHA-3) there is a much more serious problem. There does not appear to be a clear mechanism for handling a compromise of the basic algorithm, and there should be.","Quote"],["t","10 years is a good a guess as my 1 million years. SHA1 still has not been broken, but you can brute force/exploit flaws on a super-computer in under 60 hours if you have $35 million to throw at it.\n\nOverall, I hear what you say and if BitCoin jumped in the SHA3 realm, I would sleep just as well at night as I did with it using the older SHA2 realm of technology.\n\nI'm not trying to nitpick your post, just offering up my opinion and I certainly respect yours. I think we can both agree that if the encryption is bumped up another notch in the future, it would be a good thing for the system and community as a whole."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3341#msg3341"},{"f":"Some Mouse","d":1279246996,"b":[["q","I'm sure the same was said back when 40, 64, 128, and 256 bit encryption was coming out. SHA512 is part of SHA2, I remember when everyone was talking about how insecure SHA1 was with that significant *flaw* and how we all need to move to SHA2 because it was well defined, well supported, and well analyzed; sound familiar?","Quote from: knightmb on July 16, 2010, 01:00:13 AM"],["t","I'm not aware of any 40 bit hash length. The reason for SHA512 and Whirlpool's excessive bit lengths are just for such future proofing. A collision has a 50% chance of occurring at half of the bit length (roughly), so weak hashes such as MD5 would have problems at around 2^64 elements, this was well known and few people thought this was impossible to achieve in the future.\n\nSo no, it's not exactly familiar. Wanting to double it again because the idea is to form a basis for a new economy is not crazy talk - there is no technical reason not to use Whirlpool or SHA512 (or both). The only hurt would be a lower hash generation rate... which isn't exactly a problem."],["q","I'm not betting anything for the simple fact that unless you can see into the future, we work with what we have in front of us. We can debate all day that in the future computers will be a million times faster or that some math genius is going to discover a flaw in the system that would bring everything down. I'm well aware of many peer reviewed papers and tech journals, even blogs about encryption. Not everything in existence, as I don't have the time for all of it, but enough practical experience to be able to visualize what it would really take to do what you propose.","Quote"],["t","Your participation is your bet."],["q","10 years is a good a guess as my 1 million years. SHA1 still has not been broken, but you can brute force/exploit flaws on a super-computer in under 60 hours if you have $35 million to throw at it.","Quote"],["t","$35 million to swipe any single person's bank account."],["q","I'm not trying to nitpick your post, just offering up my opinion and I certainly respect yours. I think we can both agree that if the encryption is bumped up another notch in the future, it would be a good thing for the system and community as a whole.","Quote"],["t","I'm honestly rather keen on exploring alternative possibilities for generation. As one Slashdotter put it, the current scheme is like claiming a forest of unknown size as currency, burning it down, then proclaiming the most select 21 tons of ash as the representative medium. I have an idea but I have no clue about who would be interested."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3355#msg3355"},{"f":"knightmb","d":1279247415,"b":[["t","That's why I'm glad we have people like you here to participate in the discussion as well. A room full of \"yes men\" is a dangerous thing.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3357#msg3357"},{"f":"D҉ataWraith","d":1279279666,"b":[["q","Reversible computing techniques 'cheat' around the entropy limit. This means they can reach effective speeds far, far beyond what are possible with current computers, as they are effectively capable of performing nondeterministic operations.","Quote from: Some Mouse on July 16, 2010, 12:13:52 AM"],["t","Wait, what? I thought reversible computation just uses less energy. Where does the non-determinism come in?\n\nAnyway, about the hashing being insecure: Wikipedia says that attacks on SHA-256 still take on the order of 2250 operations. And unless I made a big thinko here, doesn't the hash target change every ~10 minutes? Wouldn't that throw of an attacker? And if it was possible to break SHA faster, wouldn't the system adjust by raising the difficulty level?"]],"u":"https://bitcointalk.org/index.php?topic=360.msg3434#msg3434"},{"f":"Some Mouse","d":1279286508,"b":[["q","Wait, what? I thought reversible computation just uses less energy. Where does the non-determinism come in?","Quote from: D҉ataWraith on July 16, 2010, 11:27:46 AM"],["t","It's the theoretical limit of how far you can go with it. When doing a brute force search, you can reverse back to any previous state and try new states."],["q","Anyway, about the hashing being insecure: Wikipedia says that attacks on SHA-256 still take on the order of 2250 operations. And unless I made a big thinko here, doesn't the hash target change every ~10 minutes? Wouldn't that throw of an attacker? And if it was possible to break SHA faster, wouldn't the system adjust by raising the difficulty level?","Quote"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3463#msg3463"},{"f":"satoshi","d":1279296833,"b":[["t","SHA256 is not like the step from 128 bit to 160 bit.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=360.msg3520#msg3520","s":1,"n":216,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/216/"}]},{"id":"p103","k":"p","s":"bitcointalk","t":"Website integration for bitcoin","u":"https://bitcointalk.org/index.php?topic=364","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/103/","m":[{"f":"martin","d":1279156163,"b":[["t","I've been working on a project inspired by a suggestion (and the offer of bounty Wink ) over from another thread <http://bitcointalk.org/index.php?topic=39.msg2065#msg2065>. I thought I should stop derailing that thread and start my own project thread.\n\nBasically, the idea of the project is an easy way for websites to integrate bitcoin payment. How it works is the user runs a website on their local machine, which is only accessible to them, then when the shop wants a user to pay some money, they simply send them to this local site, which handles sending the money and then redirects back to the shop site to finish the transaction.\n\nSo at the moment, I have a test of this running on my PC, visiting this URL:\n\nhttp://127.0.0.1:8080/BitcoinSalepoint/LandingPage?continue=http://www.google.co.uk&paymentname=testaddress&address=1DoMXge6kToHZN8m4B2my43anCPbD4rJgE&amount=0.25\n\nwill simply send 0.25BC to my laptop from my PC, and then redirect me to google.\n\nMy todo list:\n-> Add some stylesheets for prettiness\n-> Add a confirm/deny button\n-> Add a way to communicate to the shop if the transaction succeeded or failed (mostly done)\n-> Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies.\n\nSuggestions (and donations) very welcome Smiley"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3027#msg3027"},{"f":"theymos","d":1279160292,"b":[["t","Don't use 8080. Freenet Message System uses that port by default (on localhost), and I expect that there are a lot of FMS users here. It's also a registered port. I suggest using a port that isn't listed here <http://en.wikipedia.org/wiki/List_of_tcp_ports>."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3056#msg3056"},{"f":"martin","d":1279161581,"b":[["t","Good point! I hadn't thought about that as 8080 is just the default test port. I'll see about changing to port 18011 tomorrow Smiley"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3066#msg3066"},{"f":"Bitcoiner","d":1279216962,"b":[["t","Hey Martin,\n\n\"Look into packaging the program up into a simple executable which you can run instead of bitcoin, and it will run in the background and kill itself when the bitcoin process dies.\"\n\nMy only concern with this is that we need to open the JSON API, which is insecure. So easy for a trojan to wipe out a user's wallet.\n\nIf this feature were embedded directly within Bitcoin, there would be no need to open the JSON API, and security measures could be taken (such as a captcha to be entered before a pay could be fired, or a password).\n\nI am not, however, a security expert. What do you think?"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3222#msg3222"},{"f":"Bitcoiner","d":1279217032,"b":[["t","And alternatively, the JSON API itself can be password secured; would there be a man in the middle attack possible, though?\n\nLots of security issues to address, but great stuff. I can't wait to see this in action!"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3223#msg3223"},{"f":"lachesis","d":1279219933,"b":[["t","The JSON-API definitely needs some sort of security features. On Linux, you can use iptables to restrict the users who can access it, but that's hardly secure. If I want to access it from my website backend, then whatever user runs my httpd needs to be able to access it, and that's the user most likely to be compromised on my server!\n\nOf course, a password wouldn't help that scenario too much, since the password would just be another variable in django's settings.py for an attacker to read, but still, it beats a blank!"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3251#msg3251"},{"f":"martin","d":1279222963,"b":[["t","This is definately a temporary solution, ideally this functionality would be built into the client itself.\n\nA temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.\n\nOf course, for now, bitcoin probably isn't popular enough to be targeted by a trojan."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3270#msg3270"},{"f":"Anonymous","d":1279250519,"b":[["q","This is definately a temporary solution, ideally this functionality would be built into the client itself.\n\nA temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.\n\nOf course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.","Quote from: martin on July 15, 2010, 07:42:43 PM"],["t","Thanks for this martin.If it works as easily as copy and pasting code from paypal onto my site you will have an amazon giftcard coming your way  Grin"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3371#msg3371"},{"f":"Anonymous","d":1279250698,"b":[["q","This is definately a temporary solution, ideally this functionality would be built into the client itself.\n\nA temporary solution could be to use a password which the user has to enter, that way the website connects to the bitcoin client (via https), the user enters a password to prove their identity and onlythen everything will work. However, that requires https support from the client - either way the client needs some work to make anything like this properly secure.\n\nOf course, for now, bitcoin probably isn't popular enough to be targeted by a trojan.","Quote from: martin on July 15, 2010, 07:42:43 PM"],["t","Security through obscurity?\n\n3 things I can think of\n- Allow sellers to specify the value of their goods and services easily.\n-Have a message section for the buyers when making payment to allow for such things as contact details and postage etc...\n- ping bitmarket for the latest exchange prices to allow automatic conversion between currencies."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3372#msg3372"},{"f":"martin","d":1279285760,"b":[["t","I'm not certain how paypal is integrated into your site, but it should be fairly easy - simply direct the user to the payment address, then wait for them to come back to your site and when they do check that you've received payment off them.\n\nThe current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely u nacceptable for acommerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features."],["q","Security through obscurity?","Quote from: Anonymous on July 16, 2010, 03:24:58 AM"],["t","It's terrible, I know, but the only other option is to request changes to the client and wait until they get implemented.\n\nEdit: Anyone out there any good at doing stylesheets? I can make them, but I'm not great at it"]],"u":"https://bitcointalk.org/index.php?topic=364.msg3460#msg3460"},{"f":"BitLex","d":1279287779,"b":[["q","The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely u nacceptable for acommerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.","Quote"],["t","you could still create a new address for any transaction,\nif only one person knows that address, it's pretty obvious where bitcoins came from.\n\ntrue that you can't get a list of all transactions from JSON yet, but from received credits by addresses, or labels,\nno need to know about generated coins on a payment-system, or about sending, when your system is only supposed to accept payments."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3468#msg3468"},{"f":"Quantumplation","d":1279288975,"b":[["t","It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side.  Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3474#msg3474"},{"f":"martin","d":1279289349,"b":[["q","> Quote\n> The current problem I'm facing is that there is no way to identify who a transaction came from (and, in fact, there is no way to even get a list of transactions in json at the moment), this makes it very difficult to confirm that a person actually sent the payment - which is of course completely unacceptable for a commerce application. If I can't find a solution to this I'll have to make some requests to satoshi and wait until he updates the client with some new features.\nyou could still create a new address for any transaction,\nif only one person knows that address, it's pretty obvious where bitcoins came from.","Quote from: BitLex on July 16, 2010, 01:42:59 PM"],["t","Absolutely, I realised a while after posting that you can simply have a unique address per transaction."],["q","It's a good temporary solution, and the only drawback I can see is that it requires a different/separate install, as opposed to just being something server-side.  Granted, I can't come up with an alternative either, but it IS a bit of barrier-to-entry for some people.","Quote from: Quantumplation on July 16, 2010, 02:02:55 PM"],["t","It is, I hope that ultimately this is just a proof of concept, and once it's shown to work it can be integrated into the client (using the same port and URLs)."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3476#msg3476"},{"f":"Quantumplation","d":1279289664,"b":[["q","It is, I hope that ultimately this is just a proof of concept, and once it's shown to work it can be integrated into the client (using the same port and URLs).","Quote from: martin on July 16, 2010, 02:09:09 PM"],["t","*nods*  It's a good initiative, and ANY development in the interest of bitcoins right now is good development."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3479#msg3479"},{"f":"satoshi","d":1279304584,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=364.msg3559#msg3559","s":1,"n":224,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/224/"}]},{"id":"p104","k":"p","s":"bitcointalk","t":"[Bitcoin 0.3.0] Runtime error","u":"https://bitcointalk.org/index.php?topic=373","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/104/","m":[{"f":"Anonymous","d":1279185086,"b":[["t","Installed Bitcoin 0.3.0 on disk \"D\". When I try to start it i get these errors:\n\nWhat am I doing wrong?"]],"u":"https://bitcointalk.org/index.php?topic=373.msg3118#msg3118"},{"f":"knightmb","d":1279189995,"b":[["t","You are using Windows I can tell, but what version, arch (32 or 64 bit) ,etc?"]],"u":"https://bitcointalk.org/index.php?topic=373.msg3132#msg3132"},{"f":"Anonymous","d":1279191155,"b":[["t","I'm using Microsoft Windows XP Professional Service Pack 3, 32 bit."]],"u":"https://bitcointalk.org/index.php?topic=373.msg3136#msg3136"},{"f":"SmokeTooMuch","d":1279196716,"b":[["t","http://bitcointalk.org/index.php?topic=316.0\n\nMaybe that thread helps."]],"u":"https://bitcointalk.org/index.php?topic=373.msg3144#msg3144"},{"f":"satoshi","d":1279202720,"b":[["t","More directly, this:\nhttp://bitcointalk.org/index.php?topic=246.0\n\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."]],"u":"https://bitcointalk.org/index.php?topic=373.msg3150#msg3150","s":1,"n":190,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/190/"}]},{"id":"p105","k":"p","s":"bitcointalk","t":"bitcoin trademark?","u":"https://bitcointalk.org/index.php?topic=378","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/105/","m":[{"f":"andy_3_913","d":1279207619,"b":[["t","could there be a possible copyright thing here?\ndid a search for bitcoin on twitter and came up with these links...\n\nhttp://twitter.com/bitcoin\n\nwhich leads to\n\nhttp://bitcoin.com/\n\nor are these somehow related?"]],"u":"https://bitcointalk.org/index.php?topic=378.msg3169#msg3169"},{"f":"ultrasonicsite","d":1279287024,"b":[["t","I also wonder about this."]],"u":"https://bitcointalk.org/index.php?topic=378.msg3465#msg3465"},{"f":"satoshi","d":1279302425,"b":[["t","No, not related at all."]],"u":"https://bitcointalk.org/index.php?topic=378.msg3540#msg3540","s":1,"n":222,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/222/"}]},{"id":"p106","k":"p","s":"bitcointalk","t":"Bitcoin 0.3.1 released","u":"https://bitcointalk.org/index.php?topic=383","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/106/","m":[{"f":"satoshi","d":1279213554,"b":[["t","This is a bugfix maintenance release.  It is now uploaded to SourceForge.  Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.\n\nThe download links are on bitcoin.org\n\nChanges:\n- Added Portuguese translation by Tiago Faria\nWindows\n- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it\nLinux\n- Laszlo's fix for lowering generate thread to lowest priority\n- Fix for if you're having trouble with libcrypto linkage\n- Gavin Andresen's implementation of \"start on windowing system startup\" option"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3198#msg3198","s":1,"n":193,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/193/"},{"f":"andy_3_913","d":1279213909,"b":[["t","hi satoshi,\nare there any back-ups need to be done before installing?"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3200#msg3200","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279214628,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3205#msg3205","s":1,"n":194,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/194/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279214733,"b":[["q","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.","Quote from: satoshi on July 15, 2010, 05:23:48 PM"],["t","okey dokey Smiley\n\nbeen crunching away for a couple of days now, don't want to start all over again!!!!"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3206#msg3206","sj":"Re: 0.3.1 release candidate, please test"},{"f":"Insti","d":1279215134,"b":[["t","you know you're not actually making 'progress' right? http://bitcointalk.org/index.php?topic=325.msg2935#msg2935"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3210#msg3210","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279215174,"b":[["t","on this end,\nhasn't helped.\nstill same symptoms, but can't set to belownormal. access is denied!!\n\nedit:\nstrange,\nfirefox and windows explorer open quickly enough, bit laggy, but the likes of gomez doesn't!"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3212#msg3212","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279216603,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3221#msg3221","s":1,"n":195,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/195/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"jimbobway","d":1279217070,"b":[["t","I am really scared to lose my wallet due to an install, re-install, or backing up.  In another thread a user backed up his wallet only to lose all of his bitcoins, forever.\n\nSee this thread: http://bitcointalk.org/index.php?topic=359.0\n\nMaybe we can have a step-by-step procedure to successfully backup and to restore."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3224#msg3224","sj":"Re: 0.3.1 release candidate, please test"},{"f":"laszlo","d":1279217249,"b":[["t","He tried to double spend his coins and the system prevented it.  In the process he also lost the coins he didn't spend because he lost one of the wallet files while swapping them around.\n\nIt is enough to back up the wallet.dat, try it out with some free coins from the bitcoin faucet."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3226#msg3226","sj":"Re: 0.3.1 release candidate, please test"},{"f":"Anonymous","d":1279217810,"b":[["t","This build solved my problem (additional info in this topic http://bitcointalk.org/index.php?topic=373.0)."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3233#msg3233","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279218197,"b":[["q","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.","Quote from: satoshi on July 15, 2010, 05:56:43 PM"],["t","possible.\nbut, and i'm NOT being offensive here, this sort of performance lag has only appeared while i'm running bitcoin.\nand BOINC is active, but not running any projects at the moment.\n\n3gig memory,\ncached 1524,\navailable 1573,\nfree 108.\nnot going to stop bitcoin, but it does seem a bit strange Smiley\n\nanything you would like me to send?\n\nps...\nhaven't noticed any extra disk thrashing while bitcoin is running Smiley"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3236#msg3236","sj":"Re: 0.3.1 release candidate, please test"},{"f":"laszlo","d":1279218921,"b":[["t","Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)?  It's hard to diagnose without seeing it first hand, sorry."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3241#msg3241","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279219130,"b":[["q","Are there any errors maybe in dmesg or the syslog (usually /var/log/messages or /var/log/syslog or something like that)?  It's hard to diagnose without seeing it first hand, sorry.","Quote from: laszlo on July 15, 2010, 06:35:21 PM"],["t","on a windows machine here. sorry!\nany better pointers?\ni'm re-installing .3\nthis update isn't quite working lol Smiley"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3243#msg3243","sj":"Re: 0.3.1 release candidate, please test"},{"f":"lachesis","d":1279219334,"b":[["t","Very nice Satoshi. What about the slow block download bug?"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3246#msg3246","sj":"Re: 0.3.1 release candidate, please test"},{"f":"diven","d":1279222160,"b":[["t","Working on 32 bit Slackware 12.2 and 13.0 (with updated gcc-g++).  I have not reverted the upgrade to test if it works with the stock gcc."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3267#msg3267","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279222630,"b":[["t","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.\n\nI should have counted the cores ahead of time  Lips sealed , confirmed NOT to be a bug when testing Windows 2000, XP, Vista 32/64, Windows 7/ 32-64"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3269#msg3269","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279224946,"b":[["t","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).\n\nBut, the priority of the threads all seem to be \"nice\" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive."],["c","[knightmb@KnightMB ~]$ ps -eflL | grep bitcoin\n0 S knightmb 13676 13591 13676  0    9  80   0 - 113704 poll_s 14:52 pts/1   00:00:02 ./bitcoin\n1 S knightmb 13676 13591 13681  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 S knightmb 13676 13591 13682  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 S knightmb 13676 13591 13683  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 S knightmb 13676 13591 13685  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 S knightmb 13676 13591 13686  0    9  80   0 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 S knightmb 13676 13591 13687  0    9  82   2 - 113704 hrtime 14:52 pts/1   00:00:00 ./bitcoin\n1 R knightmb 13676 13591 13689 70    9  99  19 - 113704 -     14:52 pts/1    00:09:34 ./bitcoin\n1 R knightmb 13676 13591 13714 71    9  99  19 - 113704 -     14:53 pts/1    00:09:39 ./bitcoin\n1 R knightmb 13676 13591 13924 72    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin\n1 R knightmb 13676 13591 13314 73    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin\n1 R knightmb 13676 13591 13114 74    9  99  19 - 113704 -     14:53 pts/1    00:08:19 ./bitcoin\n1 R knightmb 13676 13591 13984 75    9  99  19 - 113704 -     14:53 pts/1    00:09:19 ./bitcoin\n1 R knightmb 13676 13591 13214 76    9  99  19 - 113704 -     14:53 pts/1    00:09:09 ./bitcoin\n1 R knightmb 13676 13591 13917 77    9  99  19 - 113704 -     14:53 pts/1    00:08:12 ./bitcoin\n1 R knightmb 13676 13591 13919 78    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin\n1 R knightmb 13676 13591 13934 79    9  99  19 - 113704 -     14:53 pts/1    00:08:51 ./bitcoin\n1 R knightmb 13676 13591 13114 80    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin\n1 R knightmb 13676 13591 13624 81    9  99  19 - 113704 -     14:53 pts/1    00:09:11 ./bitcoin\n1 R knightmb 13676 13591 13224 82    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin\n1 R knightmb 13676 13591 13374 83    9  99  19 - 113704 -     14:53 pts/1    00:08:55 ./bitcoin\n1 R knightmb 13676 13591 13261 84    9  99  19 - 113704 -     14:53 pts/1    00:09:43 ./bitcoin\n1 R knightmb 13676 13591 13171 85    9  99  19 - 113704 -     14:53 pts/1    00:08:55 ./bitcoin\n1 R knightmb 13676 13591 13741 86    9  99  19 - 113704 -     14:53 pts/1    00:08:23 ./bitcoin\n1 R knightmb 13676 13591 13371 87    9  99  19 - 113704 -     14:53 pts/1    00:09:42 ./bitcoin\n1 R knightmb 13676 13591 13690 88    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin\n1 R knightmb 13676 13591 13234 89    9  99  19 - 113704 -     14:53 pts/1    00:08:33 ./bitcoin\n1 R knightmb 13676 13591 13703 90    9  99  19 - 113704 -     14:53 pts/1    00:08:38 ./bitcoin\n1 R knightmb 13676 13591 13991 91    9  99  19 - 113704 -     14:53 pts/1    00:08:39 ./bitcoin"],["t","I'm not exactly sure what the \"Start BitCoin on window system startup\" is suppose to do?\n\nOn library errors, you get a /usr/lib/libstdc++.so.6 'GLIBCXX_3.4.11' not found on older linux clients (one was only a year old). I checked the file, it's just linked to libstdc++.so.10 but I don't know if that's a high enough version or not."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3274#msg3274","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279225561,"b":[["t","i'm sorry, but this is mostly ??\ni'm not a complete thickie, but most of this is way over my loaf!!\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3277#msg3277","sj":"Re: 0.3.1 release candidate, please test"},{"f":"db","d":1279226348,"b":[["t","The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3278#msg3278","sj":"Re: 0.3.1 release candidate, please test"},{"f":"andy_3_913","d":1279228938,"b":[["q","The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)","Quote from: db on July 15, 2010, 08:39:08 PM"],["t","yep!\ni'm sure they are!!\nalready said, i haven't a clue!\nwhat on earth are you talking about???"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3291#msg3291","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279230034,"b":[["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.","Quote from: knightmb on July 15, 2010, 07:37:10 PM"],["t","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.\n\nDo you have dual-proc?  Are you sure you weren't running a single processor hog?"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3295#msg3295","s":1,"n":200,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/200/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279230509,"b":[["q","> Quote from: knightmb on July 15, 2010, 07:37:10 PM\n> 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.\nI 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.\n\nDo you have dual-proc?  Are you sure you weren't running a single processor hog?","Quote from: satoshi on July 15, 2010, 09:40:34 PM"],["t","LOL, I think you are right. I've got waaaayy too many PCs around me and it's difficult to keep track of which is single core, dual core, quad, 8 core, etc. I'll test it again on the single proc PC and see what happens."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3298#msg3298","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279230969,"b":[["t","Yeah, you are right, works just fine. *smacks forehead for not counting cores ahead of time*, so scrap the prioirty bug then, I'll go back and edit my post. Works just fine on Windows 2000, XP, Vista, and 7"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3302#msg3302","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279231655,"b":[["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).","Quote from: knightmb on July 15, 2010, 08:15:46 PM"],["t","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!\n\nhttp://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3305#msg3305","s":1,"n":201,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/201/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279231819,"b":[["q","The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)","Quote from: db on July 15, 2010, 08:39:08 PM"],["t","Yes a bug.  It'll have to be fixed in the next version."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3306#msg3306","s":1,"n":202,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/202/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"db","d":1279232632,"b":[["t","On Linux 0.3.0 gets nice 0 when generating but with 0.3.1 the generating thread gets nice 19 while the other threads stay at 0. Looks good."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3310#msg3310","sj":"Re: 0.3.1 release candidate, please test"},{"f":"RHorning","d":1279232968,"b":[["q","I'm not exactly sure what the \"Start BitCoin on window system startup\" is suppose to do?","Quote from: knightmb on July 15, 2010, 08:15:46 PM"],["t","In Windows, it should put Bitcoin.exe into \"HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" for the system registry... or as an alternative into \"HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\"\n\nI 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.\n\nI haven't done a full forensics with this new version in Windows, but the install seemed to go without a hitch for me... using the Windows install."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3311#msg3311","sj":"Re: 0.3.1 release candidate, please test"},{"f":"adavid","d":1279233573,"b":[["q","But, the priority of the threads all seem to be \"nice\" properly I think. The ones using all the CPU time are nice to 19, so the others that are 0 and 2 aren't using any CPU time so the system seems to be responsive.","Quote from: knightmb on July 15, 2010, 08:15:46 PM"],["t","I confirm this. bitcoind is actually nice now."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3314#msg3314","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279236184,"b":[["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.","Quote from: RHorning on July 15, 2010, 10:29:28 PM"],["t","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.\n\nOpenOffice is another example of something that puts its link in the Startup folder."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3319#msg3319","s":1,"n":205,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/205/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"lachesis","d":1279238602,"b":[["q","> Quote from: knightmb on July 15, 2010, 08:15:46 PM\n> 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).\nI 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!\n\nhttp://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz","Quote from: satoshi on July 15, 2010, 10:07:35 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3331#msg3331","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279241072,"b":[["t","Run it with the undocumented switch -minimizetotray and the option is available in the options menu.\n\nI don't know how to fix it.  It's something wrong deep inside wxWidgets or GTK or Gnome."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3339#msg3339","s":1,"n":207,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/207/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"lachesis","d":1279242746,"b":[["t","Alright, thanks. That's all I need."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3344#msg3344","sj":"Re: 0.3.1 release candidate, please test"},{"f":"BioMike","d":1279257899,"b":[["t","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.\n\nB.T.W. Why does the standard makefile builds a static version anyway?"]],"u":"https://bitcointalk.org/index.php?topic=383.msg3396#msg3396","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279292999,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3505#msg3505","s":1,"n":214,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/214/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279294046,"b":[["t","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?\n\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.\n\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)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3509#msg3509","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279301177,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3536#msg3536","s":1,"n":220,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/220/","sj":"Re: 0.3.1 release candidate, please test"},{"f":"knightmb","d":1279303104,"b":[["q","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.","Quote from: satoshi on July 16, 2010, 05:26:17 PM"],["t","The Windows Client had it's own static IP with port 8333 open for it, I could see from the gateway device that it was connecting out to other peers and other peers were connecting back in. But after the 8, it's like it quit connecting out to peers and after a while the incoming peers stopped as well since it appeared to only be concerned with the peers on the LAN vs the WAN. The behavior of the Linux client is different though I've noticed, even if 50 people are connected to it, it will still seek outbound connections to other peers and inbound peers continue to trickle in as well.\n\nWhile this will only be a problem for people like me that have hundreds of PCs at their disposal, the reverse is, one could setup PC(s) to connect to a single client 8 or more times and then after a while, the poor windows client would suck itself into it's own matrix world where it thinks it's on the network solving blocks, but it's really trapped back in time.\n\nThis is just a theoretical attack of course, I'm not going to lose any sleep over it, but I figured I would throw it out there for the future. The easiest way to negate this would be to put in some self-checking code for IPs. Basically, have to check that is has 8 connections or more that are NOT from the LAN/Same IP Address/etc when it's running as a dual node/client mode."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3544#msg3544","sj":"Re: 0.3.1 release candidate, please test"},{"f":"BioMike","d":1279309599,"b":[["q","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.","Quote from: satoshi on July 16, 2010, 03:09:59 PM"],["t","I think size (static binary is 8x as big in my case) is not the problem, but security.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3581#msg3581","sj":"Re: 0.3.1 release candidate, please test"},{"f":"satoshi","d":1279314417,"b":[["t","I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=383.msg3590#msg3590","s":1,"n":227,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/227/"}]},{"id":"p107","k":"p","s":"bitcointalk","t":"\"SetIcons(): icon bundle doesn't contain any suitable icon\"","u":"https://bitcointalk.org/index.php?topic=391","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/107/","m":[{"f":"EricJ2190","d":1279221773,"b":[["t","In Windows, when opening the \"Send Coins\" or the \"Your Receiving Addresses\", I get the following message.\n\nClicking Cancel allows me to make it go away, and everything still works fine, but it is still a bit annoying.\n\nI am running BitCoin 0.3.0 on Windowx Vista SP2 x64."]],"u":"https://bitcointalk.org/index.php?topic=391.msg3265#msg3265"},{"f":"satoshi","d":1279232306,"b":[["t","That's surprising that we've never heard of that before now.\n\nMaybe you're the first person to ever run it on Vista  Smiley\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=391.msg3308#msg3308","s":1,"n":203,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/203/"},{"f":"bdonlan","d":1279236434,"b":[["t","Also happens here - Windows XP, 32-bit color depth, 1680x1050 LCD screen in 120DPI mode. Perhaps the use of an unusual DPI is breaking it?"]],"u":"https://bitcointalk.org/index.php?topic=391.msg3320#msg3320"},{"f":"satoshi","d":1279237283,"b":[["q","in 120DPI mode.","Quote from: bdonlan on July 15, 2010, 11:27:14 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=391.msg3323#msg3323","s":1,"n":206,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/206/"},{"f":"bdonlan","d":1279238553,"b":[["q","> Quote from: bdonlan on July 15, 2010, 11:27:14 PM\n> in 120DPI mode.\nWhat 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.","Quote from: satoshi on July 15, 2010, 11:41:23 PM"],["t","In XP, display properties -> settings -> advanced. It basically makes all display elements a bit larger."]],"u":"https://bitcointalk.org/index.php?topic=391.msg3330#msg3330"},{"f":"EricJ2190","d":1279239691,"b":[["t","Also using 120 DPI here. Same bit depth and resolution as the previous user as well."]],"u":"https://bitcointalk.org/index.php?topic=391.msg3335#msg3335"},{"f":"satoshi","d":1279248209,"b":[["t","That must be it then.\n\nIt must be looking for a larger icon like 20x20 but we don't have one."]],"u":"https://bitcointalk.org/index.php?topic=391.msg3362#msg3362","s":1,"n":209,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/209/"}]},{"id":"p108","k":"p","s":"bitcointalk","t":"Source code documentation","u":"https://bitcointalk.org/index.php?topic=393","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/108/","m":[{"f":"AndrewBuck","d":1279229423,"b":[["t","Hello to the other developers, I finally got a working build environment set up on my Ubuntu machine here and have been perusing the sourcecode a bit.  So far I like what I am seeing, the program makes use of the standard template library to avoid messy data structure code and the class structure seems to make pretty good use of public/private access to promote modularity.\n\nThe thing that really seems to be lacking though is a good organizational structure between the .h and .cpp files, as well as a lack of function documentation.  I would be happy to start writing documentation for the functions using the doxygen <http://www.doxygen.org> documentation system.  I am using this on OpenDungeons <http://sourceforge.net/projects/opendungeons/> which is a game I am the lead coder on and it has served me well.\n\nFor those that are unfamiliar with it, Doxygen works by reading your sourcefiles to extract information which it automatically collects (like function parameters, class organization and inheritance, etc), as well as information you add yourself (comments describing what functions do, what variables are used for, etc).  After it parses all of the code it produces  a directory containing a bunch of HTML files which are very well crosslinked and easy to navigate.  It can also be configured to autogenerate neat little call graphs showing what subfunctions are called from each function (so you can trace dependancies/bugs).\n\nAll in all Doxygen is an excellent system and I would be happy to get it set up and begin writing documentation for the functions (at least the ones I can figure out anyway) and provide patches so they can be uploaded to SVN.  I don't want to do this though if other developers would be opposed to it so I wanted to post here before I got started.  Let me know if you would like me to do this.\n\nEDIT:  In case people want to see what the documentation on an existing system looks like, here is a link <http://www.ogre3d.org/docs/api/html/> to the documentation for the OGRE 3d rendering system.  The best place to get a feel for the documentation is to click the \"Classes\" link at the top and then look at the pages for a couple of classes.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3292#msg3292"},{"f":"lachesis","d":1279238239,"b":[["t","I think that would be cool, but as always, the decision rests with Satoshi, the project lead."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3329#msg3329"},{"f":"AndrewBuck","d":1279289747,"b":[["q","I think that would be cool, but as always, the decision rests with Satoshi, the project lead.","Quote from: lachesis on July 15, 2010, 11:57:19 PM"],["t","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\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3480#msg3480"},{"f":"satoshi","d":1279294620,"b":[["t","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.\n\nTo add them now at this point, what would be written would just be what's obvious from looking at the function.\n\nThe external API we have, in rpc.cpp, the usage documentation is in the help string.\n\nSorry to be a wet blanket."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3510#msg3510","s":1,"n":215,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/215/"},{"f":"AndrewBuck","d":1279295530,"b":[["t","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.\n\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.\n\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\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3514#msg3514"},{"f":"satoshi","d":1279300547,"b":[["t","It's in init.cpp.\n\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)\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3534#msg3534","s":1,"n":219,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/219/"},{"f":"AndrewBuck","d":1279310053,"b":[["t","I don't know anything about JSON and my knowledge of website design is quite limited so I will be of no use here.  I do have pretty extensive C++ knowledge though so I should be able to do a bit of work on the codebase.\n\nI am currently tweaking the commandline handling a bit to make it behave more like the standard unix/linux command line (specifically I am adding -h to display help).  I also plan to get the man-page text written up based on the current code.\n\nI will put the man page on the wiki when I get it written, where should I submit the patch for the source code?\n\nEDIT:  Actually since I am writing the man page in the man page markup language I will include this in the patch as well since it would look like nonsense on the wiki.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3584#msg3584"},{"f":"AndrewBuck","d":1279376824,"b":[["t","I am still crunching along on the man page, it is starting to look pretty good.  I did come across a couple of issues though.  First, there is a \"-printtodebugger\" command line option.  I added it to the \"usage\" information when you give -h and I also added it to the man page but I can't tell what it does by looking at the code, other than to see that it is only used on windows machines.\n\nSecondly, in the process of investigating the OutputDebugStringF() function I discovered that the code has the ability to output to a console by setting the global variable fPrintToConsole to true.  The variable, however, was initialized to false and there was no where in the code that sets it to true.  Because of this I added a -printtoconsole which sets both this variable and fDebug to true.  I think both should be set but I am wondering if I should leave fDebug alone.  If I don't set it in the code then the user would have to do \"-printtoconsole -debug\" on the command line instead, we may or may not want this depending on whether there is more/less verbosity implied by debug but from a quick grep of the code it looks like it should be the way I currently have it where it automatically sets both variables.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3756#msg3756"},{"f":"AndrewBuck","d":1279381796,"b":[["t","Sorry to keep replying to myself but I am posting these little snippets as I stumble across them.  I am currently documenting the -dropmessagestest command line switch and I see a minor improvement you may want to add to the code.  Currently if a message is dropped as a result of this switch, a debug message is printed to the log indicating a message was dropped.  It would probably be pretty useful to print the contents of the dropped message to the log as well.  This way if one of the dropped messages really does break bitcoin, you can see what message caused the problem.  It would also allow you to later re-create the problem by adding a filter on the incoming network stream blocking messages like the one that broke it the first time so that you can verify that you have fixed the issue later on.\n\nIf you think it is a good idea I can probably add this myself as well.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3765#msg3765"},{"f":"Insti","d":1279387711,"b":[["t","Thanks Andrew.\nAll your hard work is not going unnoticed."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3777#msg3777"},{"f":"AndrewBuck","d":1279393533,"b":[["t","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).\n\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.\n\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.  Smiley\n\nAttached to this message you should find a zip file with the patch in it.\n\nEDIT:  The 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\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3785#msg3785"},{"f":"satoshi","d":1279408710,"b":[["t","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.\n\nAll the user-facing commands are listed in the -? help."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3828#msg3828","s":1,"n":236,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/236/"},{"f":"AndrewBuck","d":1279417806,"b":[["t","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:\n\n\fBUnsupported - Behaviour may change in future versions\fR\n\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.\n\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\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=393.msg3861#msg3861"},{"f":"satoshi","d":1279465974,"b":[["t","They're only intended for intrepid programmers who read the sourcecode."]],"u":"https://bitcointalk.org/index.php?topic=393.msg3999#msg3999","s":1,"n":239,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/239/"}]},{"id":"p109","k":"p","s":"bitcointalk","t":"Request: expected bitcoins per day display","u":"https://bitcointalk.org/index.php?topic=397","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/109/","m":[{"f":"gould","d":1279240851,"b":[["t","I'd be interested in seeing something like \"expected bitcoins generated/day\" next to (or in place of) the khash/s number. I'd rarely need to see the khash/s number since that won't change unless I make changes to the software or hardware, and the bitcoins per day figure is what I really want to know.\n\nI know I can use the calculator at http://www.alloscomp.com/bitcoin/calculator.php but it's still easier just to see it displayed automatically."]],"u":"https://bitcointalk.org/index.php?topic=397.msg3338#msg3338"},{"f":"BitLex","d":1279241816,"b":[["t","what one could \"expect\" depends on luck and how much of it you expect to have on our block lottery. Cheesy\ni guess that's pretty hard to calculate.\nthe average time to generate a block shown on the calculator website doesnt mean, you'll find a block after X days,\nit still might happen, that you dont find one for a very long period.\npeople would complain even more than they do already, if the client tells them \"you should have generated xy coins so far, but you had no luck\".  Wink"]],"u":"https://bitcointalk.org/index.php?topic=397.msg3340#msg3340"},{"f":"knightmb","d":1279242230,"b":[["t","Agreed, I had a 933MHz PIII generate (2) blocks when I have other machines running multiple cores that don't generate anything. It's mainly luck of the draw with those that have faster systems having a bit better luck.\n\nI setup a new system for the farm a few hours ago and it got a block within the first hour, I was stunned, it wasn't even that fast, like 135 khash/s old PC."]],"u":"https://bitcointalk.org/index.php?topic=397.msg3342#msg3342"},{"f":"BitLex","d":1279260987,"b":[["t","hehe,\ni just checked my old pIII laptop, that i set up ~12hrs ago,\nit does ~150khash/sec @1066MHz and already won the race 10hrs ago.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=397.msg3404#msg3404"},{"f":"FreeMoney","d":1279272362,"b":[["t","I've been running two laptops. One does 1280k/sec and the other 580. The 580 found one first. It does run 24/7 though and I make my faster one stop when I do other stuff.\n\nOh, I keep hearing that there should be 6 blocks an hour, but it seems more like 80. And didn't the difficult just rest? So shouldn't it be close to the goal? I must have some misunderstanding."]],"u":"https://bitcointalk.org/index.php?topic=397.msg3423#msg3423"},{"f":"Insti","d":1279284553,"b":[["q","Oh, I keep hearing that there should be 6 blocks an hour, but it seems more like 80. And didn't the difficult just rest? So shouldn't it be close to the goal? I must have some misunderstanding.","Quote from: FreeMoney on July 16, 2010, 09:26:02 AM"],["t","Difficulty only adjusts every 2016 blocks.\n\nThe amount of processor power being applied is increasing faster than the difficulty is adjusting so we're getting about 27 blocks per hour at the moment.\n\nThere will be a big difficulty jump later today when we hit 68,544 blocks."]],"u":"https://bitcointalk.org/index.php?topic=397.msg3453#msg3453"},{"f":"gould","d":1279293964,"b":[["q","what one could \"expect\" depends on luck and how much of it you expect to have on our block lottery. Cheesy\ni guess that's pretty hard to calculate.","Quote"],["t","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.\n\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. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=397.msg3507#msg3507"},{"f":"satoshi","d":1279298834,"b":[["t","Many businesses are like that.  For a car salesman, when will the next customer walk in the door?\n\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?\n\nThe difficulty quadrupled a few minutes ago to 181.54.  It's going to take typically about a week to generate now."]],"u":"https://bitcointalk.org/index.php?topic=397.msg3524#msg3524","s":1,"n":217,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/217/"}]},{"id":"p110","k":"p","s":"bitcointalk","t":"Assertion Failure - Ubuntu Lucid","u":"https://bitcointalk.org/index.php?topic=400","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/110/","m":[{"f":"singpolyma","d":1279254615,"b":[["t","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:\n\nbitcoin: main.cpp:823: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.\nAborted\n\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:\n\nbitcoin: main.cpp:743: unsigned int GetNextWorkRequired(const CBlockIndex*): Assertion `pindexFirst' failed.\nAborted\n\nHas my db got corrupted?  Do I have a broken dependancy?\n\nI tried to build 0.3 from source but got many errors, probably missing some *-dev packages.  Will look at that more later."]],"u":"https://bitcointalk.org/index.php?topic=400.msg3384#msg3384"},{"f":"satoshi","d":1279291924,"b":[["t","That's the first time I've seen this error.\n\nHow many blocks do you have? (in the status bar)\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=400.msg3492#msg3492","s":1,"n":211,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/211/"},{"f":"singpolyma","d":1279405036,"b":[["t","I have 58464 blocks... haven't run the software in awhile"]],"u":"https://bitcointalk.org/index.php?topic=400.msg3814#msg3814"},{"f":"singpolyma","d":1279405188,"b":[["t","Moved the block files... it's working through them all again.  My coins disappeared, but I assume they'll come back when it's up to current?"]],"u":"https://bitcointalk.org/index.php?topic=400.msg3815#msg3815"},{"f":"satoshi","d":1279406226,"b":[["q","My coins disappeared, but I assume they'll come back when it's up to current?","Quote from: singpolyma on July 17, 2010, 10:19:48 PM"],["t","Right, they'll re-appear when it's finished downloading all the blocks. "]],"u":"https://bitcointalk.org/index.php?topic=400.msg3823#msg3823","s":1,"n":234,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/234/"}]},{"id":"p111","k":"p","s":"bitcointalk","t":"The dollar cost of bitmining energy","u":"https://bitcointalk.org/index.php?topic=403","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/111/","m":[{"f":"Ground Loop","d":1279258934,"b":[["t","I run my computers off solar-generated electricity, so I keep pretty tight tabs on how much power they consume.\n\nI have one headless Ubuntu server that is always-on, usually with the disk array spun down, as it has some central network management roles.  It's an Intel Core2Duo E6300 @ 1.86 GHz, and mines at about 950 khash/s.\n\nI was curious to see the impact bitcoind generation would have on it.  Here is what it looks like:\n\nThe lowest level on the left is idle, and the noise after it is bitcoind inhaling the block history.  The step up is the bitminer threads.\nIn short, hashing raised the idle floor from about 120W to 160W, or +40W.\n\nThis draws 29 kilowatt-hours a month from my generation, which means I net some $3.80 less for power ($0.13/kwh marginal power rate)\n\nIf I generate an average of 13 blocks a month at the current difficulty, BTC 650, that puts my cost at about US$0.005/BTC.\n\nIn short, I'm better off buying BTC from the exchange than generating them on this particular machine.  Food for thought."]],"u":"https://bitcointalk.org/index.php?topic=403.msg3397#msg3397"},{"f":"knightmb","d":1279260606,"b":[["t","It's like they always say, \"To make a billion dollars, you have to start with 4 billion dollars first\"  Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=403.msg3402#msg3402"},{"f":"Bitcoiner","d":1279288473,"b":[["q","In short, I'm better off buying BTC from the exchange than generating them on this particular machine.  Food for thought.","Quote from: Ground Loop on July 16, 2010, 05:42:14 AM"],["t","Don't forget to amortize your fixed costs. Those parts don't last forever and eventually need replacing."]],"u":"https://bitcointalk.org/index.php?topic=403.msg3471#msg3471"},{"f":"satoshi","d":1279303124,"b":[["t","Neat chart.\n\nDifficulty just increased by 4 times, so now your cost is US$0.02/BTC."]],"u":"https://bitcointalk.org/index.php?topic=403.msg3545#msg3545","s":1,"n":223,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/223/","qt":["Difficulty just increased by 4 times, so now your cost is US$0.02/BTC."],"qc":["difficulty"]}]},{"id":"p112","k":"p","s":"bitcointalk","t":"Sample account system using JSON-RPC needed","u":"https://bitcointalk.org/index.php?topic=417","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/112/","m":[{"f":"satoshi","d":1279309510,"b":[["t","We need someone to write sample code, preferably Python or Java, showing the recommended way to use the JSON-RPC interface to create an account system.  Most sites that sell things will need something like this.  Someone who's kept up on the JSON-RPC threads here should have some idea how it should work.\n\nWhen a user is logged in to their account, you show the bitcoin address they can send to to add funds.  Before showing it, you check if it's been used, if it has then you replace it with a new one (getnewaddress <username>).  You only need to keep the latest bitcoin address for the account in your database.  (I posted a sample code fragment for this in an earlier thread somewhere, search on getnewaddress)\n\nYou use getreceivedbylabel <username> with the username as the label to get the \"credit\" amount of the account.  You need to keep a \"debit\" amount in your database.  The current balance of the account is (credit - debit).  When the user spends money, you increase debit.\n\nIf you're requiring more than 0 confirmations, it's nice if you show the current balance (0 confirmations) and the available balance (1 or more confirmations), so they can immediately see that their payment is acknowledged.  Not all sites need to wait for confirmations, so the dual current & available should be optional.  Most sites selling digital goods are fine to accept 0 confirmations.\n\nA nice sample app for this would be a simple bank site, which would have the above, plus the option to send a payment to a bitcoin address.  The sample code should be the simplest possible with the minimum extra stuff to make it a working site.\n\nvekja.net is an example of a site like this."]],"u":"https://bitcointalk.org/index.php?topic=417.msg3579#msg3579","s":1,"n":226,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/226/"}]},{"id":"p113","k":"p","s":"bitcointalk","t":"Network Size","u":"https://bitcointalk.org/index.php?topic=419","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/113/","m":[{"f":"InterArmaEnimSil","d":1279321484,"b":[["t","Is there any way to query the current size of the network, say, in connected clients, actively generating clients, FLOPS, or preferably, all three?  I see that my client is connected, and has been connected, to 15 clients for the past four days....yet somehow I doubt there are only 15 people generating coins.  I'm looking for this in the context of scalability assessments."]],"u":"https://bitcointalk.org/index.php?topic=419.msg3614#msg3614"},{"f":"AndrewBuck","d":1279374112,"b":[["t","How is it that you get more than 15, all of my clients exactly level out at 15 and never go higher like there is some hard limit imposed.  Did you have to tweak the source to make that happen?\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=419.msg3741#msg3741"},{"f":"SmokeTooMuch","d":1279395423,"b":[["t","15 connections was the maximum of 0.2 without port forwarding.\nbut it doesn't matter how much connections you have, 1 is enough, all the others are redundant."]],"u":"https://bitcointalk.org/index.php?topic=419.msg3791#msg3791"},{"f":"AndrewBuck","d":1279396008,"b":[["t","I am aware that 1 is plenty for proper functioning, but more connections helps prevent the network from becoming segmented.  I was just wondering if there was a limit because I am always at 15 which seemed odd to me.\n\nAnyway in regards to the question I think the protocol itself should support some kind of mechanism like this as it is good to know.  As far as I understand it the IRC server is more of a temporary thing until a more permanent solution is implemented.  This will probably have to happen sooner, rather than later, since the growth of the system will soon overwhelm the IRC server.  It is also somewhat of a single point of failure, even though the clients have other ways of finding eachother losing the IRC server could end up fragmenting the network causing several \"islands\" of interconnected nodes.  If this islanding persisted for long enough transactions could be lost.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=419.msg3792#msg3792"},{"f":"NewLibertyStandard","d":1279405329,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=419.msg3817#msg3817"},{"f":"FreeMoney","d":1279406081,"b":[["t","I have v3 w/ no forwarding and never get more than 8."]],"u":"https://bitcointalk.org/index.php?topic=419.msg3822#msg3822"},{"f":"satoshi","d":1279409116,"b":[["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.","Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM"],["t","In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15.\n\nPlease upgrade to 0.3.2, it's available now."]],"u":"https://bitcointalk.org/index.php?topic=419.msg3830#msg3830","s":1,"n":237,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/237/"}]},{"id":"p114","k":"p","s":"bitcointalk","t":"Bitcoin snack machine (fast transaction problem)","u":"https://bitcointalk.org/index.php?topic=423","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/114/","m":[{"f":"Insti","d":1279334021,"b":[["t","How would a Bitcoin snack  machine work?\n\n1) You want to walk up to the machine. Send it a bitcoin.\n2) ?\n3) Walk away eating your nice sugary snack. (Profit!)\n\nYou don't want to have to wait an hour for you transaction to be confirmed.\nThe vending machine company doesn't want to give away lots of free candy.\n\nHow does step 2 work?"]],"u":"https://bitcointalk.org/index.php?topic=423.msg3647#msg3647"},{"f":"laszlo","d":1279335509,"b":[["t","For low value items like that you would normally accept the transaction without any confirmations.  If the bitcoin node that the vending machine is talking to accepted the transaction then it's probably valid.  I think the only danger in that is if it was somehow double spent in a short time window - then it may never get into any blocks.  I'm not sure if that's really possible, maybe it is, but it seems like it would be hard to pull it off reliably."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3650#msg3650"},{"f":"knightmb","d":1279336105,"b":[["t","I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3651#msg3651"},{"f":"FreeMoney","d":1279343189,"b":[["q","I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.","Quote from: knightmb on July 17, 2010, 03:08:25 AM"],["t","It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.\n\nThe first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3676#msg3676"},{"f":"knightmb","d":1279343402,"b":[["q","> Quote from: knightmb on July 17, 2010, 03:08:25 AM\n> I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.\n\nIt will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.\n\nThe first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.","Quote from: FreeMoney on July 17, 2010, 05:06:29 AM"],["t","That might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3678#msg3678"},{"f":"FreeMoney","d":1279346586,"b":[["q","> Quote from: FreeMoney on July 17, 2010, 05:06:29 AM\n> > Quote from: knightmb on July 17, 2010, 03:08:25 AM\n> > I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.\n>\n> It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.\n>\n> The first solution that comes to my mind is a \"verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.\nThat might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first.","Quote from: knightmb on July 17, 2010, 05:10:02 AM"],["t","Oh, yeah. It doesn't have to be two vending machines though. I could even send the coin to my friend then immediately spend it at the vending machine. I think the way things are you aren't safe to release until the transaction is embedded in a block that the majority finds acceptable."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3681#msg3681"},{"f":"d1337r","d":1279351259,"b":[["t","The problem with slow confirmations is because of a little amount of nodes. When Bitcoin will become somewhat popular, then you could get the confirmations much quicker (especially the ones in the limit of an ISP/city/region[or state]/country)"]],"u":"https://bitcointalk.org/index.php?topic=423.msg3691#msg3691"},{"f":"Insti","d":1279354541,"b":[["t","You can act on a transaction before it is included in a block.\n\nSo you can still check for double spending in all the transactions you can see already.\n\nSo to buy 2 snacks with the same coin you'd have to spend it at 2 distant nodes simultaneously and get your snack faster than the network propagation time.\n\nSo vending machines are easily possible and the scope of the attack is actually quite limited?"]],"u":"https://bitcointalk.org/index.php?topic=423.msg3699#msg3699"},{"f":"NewLibertyStandard","d":1279354814,"b":[["t","The solution is for the snack vendor to have debit accounts. You've got a fantastic vending machine at work, so you transfer ฿2000 bitcoins to it which can be withdrawn or spent at any time. Withdrawing the bitcoins takes about ten minutes, but spending them is instantaneous. Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow, which is trusted by both parties and perhaps regulated by the government. They hold bitcoins 100% in reserve and offer instant transfer of balances between customer/merchant/supplier accounts. Withdrawals and deposits take about ten minutes, but purchases are instant."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3701#msg3701"},{"f":"knightmb","d":1279355039,"b":[["q","The solution is for the snack vendor to have debit accounts. You've got a fantastic vending machine at work, so you transfer ฿2000 bitcoins to it which can be withdrawn or spent at any time. Withdrawing the bitcoins takes about ten minutes, but spending them is instantaneous. Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow, which is trusted by both parties and perhaps regulated by the government. They hold bitcoins 100% in reserve and offer instant transfer of balances between customer/merchant/supplier accounts. Withdrawals and deposits take about ten minutes, but purchases are instant.","Quote from: NewLibertyStandard on July 17, 2010, 08:20:14 AM"],["t","If the machine is setup to only connect to their node, that could work since it would be kind of a central spending point that would quickly be able to tell if someone was trying to double-spend the coin.\n\nAs for different networks and nodes, like Bob's Escrow is different from Jane's Escrow, the added delay would make a theoretical attack possible, but no one is going to get rich ripping off vending machines."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3702#msg3702"},{"f":"mizerydearia","d":1279355206,"b":[["q","Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow","Quote from: NewLibertyStandard on July 17, 2010, 08:20:14 AM"],["t","Perhaps there could be a variety of intermediary service providers that offer this type of 3rd party escrow service and the customer can decide which 3rd party they like to use and the vending machine can choose which 3rd party escrow services it is compatible with.  If the customer finds a vending machine that accepts using a particular 3rd party escrow, then the customer can buy from the vending machine.  Of course, it would be useful if the most popular/trusted/established escrow services are used both by vending machine and customer."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3704#msg3704"},{"f":"Babylon","d":1279355302,"b":[["t","what you folks are calling an escrow sounds a lot like a debit card account."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3705#msg3705"},{"f":"NewLibertyStandard","d":1279355779,"b":[["q","what you folks are calling an escrow sounds a lot like a debit card account.","Quote from: Babylon on July 17, 2010, 08:28:22 AM"],["t","Bitcoins are the equivalent to cold hard cash. There's nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in this related thread <http://bitcointalk.org/index.php?topic=376.0>. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3708#msg3708"},{"f":"Babylon","d":1279356150,"b":[["q","> Quote from: Babylon on July 17, 2010, 08:28:22 AM\n> what you folks are calling an escrow sounds a lot like a debit card account.\nBitcoins are the equivalent to cold hard cash. There's nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in this related thread <http://bitcointalk.org/index.php?topic=376.0>. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off.","Quote from: NewLibertyStandard on July 17, 2010, 08:36:19 AM"],["t","Yeah, I understood the fractional reserve thread.  I am not sure that I fully understand escrow, I know it is usually used in large transactions to ensure the seller that the cash is indeed on hand, and will stay that way.  Part of the purpose, as far as I can tell, is usually to slow down transactions, thus making them more secure.  In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3709#msg3709"},{"f":"Insti","d":1279357745,"b":[["t","The beauty of bitcoin is you don't need 3rd parties like banks.\n\nI can see how an escrow could be useful.\n\nSurely it's still possible to do this without one.\nAdding an escrow will add cost to the transaction."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3713#msg3713"},{"f":"NewLibertyStandard","d":1279391878,"b":[["q","In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is.","Quote from: Babylon on July 17, 2010, 08:42:30 AM"],["t","You're not misunderstanding. Escrow and debit are similar services and their definitions overlap. I was stretching the definition. Debit fits my description just as well if not better than escrow. I was just putting the emphasis on the fact that the company, whatever it's called, can transfer bitcoin balances on an accounting sheet instantly without having to wait for a real bitcoin transaction, but like is described in the fractional reserve lending thread."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3784#msg3784"},{"f":"llama","d":1279401614,"b":[["t","Even better than an escrow, you just fund the beverage machine company itself.\n\nLike this: you go to the company's website and send them 100 BC.  Then, they give you an ID.  They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3805#msg3805"},{"f":"Babylon","d":1279402027,"b":[["q","Even better than an escrow, you just fund the beverage machine company itself.\n\nLike this: you go to the company's website and send them 100 BC.  Then, they give you an ID.  They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.","Quote from: llama on July 17, 2010, 09:20:14 PM"],["t","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.  "]],"u":"https://bitcointalk.org/index.php?topic=423.msg3806#msg3806"},{"f":"satoshi","d":1279405753,"b":[["t","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.\n\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.\n\nA rough back-of-the-envelope example:\n1         0\n4         1\n16        4\n64        16\n80%      20%\n\nSo if a double-spend has to wait even a second, it has a huge disadvantage.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3819#msg3819","s":1,"n":233,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/233/"},{"f":"llama","d":1279411409,"b":[["q","The service provider 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 service provider'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.","Quote from: satoshi on July 17, 2010, 10:29:13 PM"],["t","This is a good start, but still not impermeable.  This kind of security relies on the fact that the majority of nodes (which really just boils down to the majority of IP's) are honest.  However, if the attacker could amass many IP addresses, then he could control the propagation (for example, by refusing to propogate word of the transaction at the vending machine), and still lead a successful double-spending attack.  Which sort of brings us back to the main novel idea of bitcoin: truth is voted on by computing power, not IP.\n\nFor just a beverage, it may seem like this attack is uneconomical.  But imagine if instead the machine dispensed small-denomination giftcards, and the attack was performed thousands of times (maybe even at the same time in a concerted effort).  Suddenly, the cost of that IP block might be a bargain for the attacker..."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3836#msg3836"},{"f":"satoshi","d":1279418355,"b":[["q","This is a good start, but still not impermeable.","Quote from: llama on July 18, 2010, 12:03:29 AM"],["t","I didn't say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards."],["q","(for example, by refusing to propogate word of the transaction at the vending machine)","Quote"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=423.msg3867#msg3867","s":1,"n":238,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/238/"}]},{"id":"p115","k":"p","s":"bitcointalk","t":"Nenolod, the guy that wants to prove Bitcoin doesn't work.","u":"https://bitcointalk.org/index.php?topic=431","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/115/","m":[{"f":"wobber","d":1279372876,"b":[["t","So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.\nHis name is William Pitock aka Nenolod http://twitter.com/nenolod\n\nWhat do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.\nIf he does, we all loose.\n\nI hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.\nAlso, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3\nso I can prove him he's wrong.\n\nPlease discuss the issue."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3733#msg3733"},{"f":"Insti","d":1279373731,"b":[["t","what is the issue?"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3736#msg3736"},{"f":"wobber","d":1279373881,"b":[["q","what is the issue?","Quote from: Insti on July 17, 2010, 01:35:31 PM"],["t","He hoards massive amounts of BTC only to create inflation later by putting them into circuit."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3737#msg3737"},{"f":"sirius","d":1279376438,"b":[["t","Now that the network is still relatively small, he can create swings in the proof-of-work difficulty and to some extent in BTC price if he sells his coins in large quantities. Nothing too serious, I think."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3751#msg3751"},{"f":"juengasa","d":1279378012,"b":[["t","Hi, i'm new from a week. My question is.. where i can see the cost of generation of new coin? i suppose that with people with 1000 cores, we will need more time for get new coins.\n\nbye bye\nJuan."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3759#msg3759"},{"f":"dwdollar","d":1279379178,"b":[["q","How much money is he wasting to tie up 1000 cores? I'd love to have that kind of disposable income to prove my point Smiley","Quote from: davidonpda on July 17, 2010, 02:31:12 PM"],["t","Probably the son of a [paper] banker.  Or some other powerful interest that will be hurt by a disruptive technology."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3761#msg3761"},{"f":"teff","d":1279379835,"b":[["t","nope, hes the Technology Director at SystemInPlace http://www.linkedin.com/in/nenolod Appears to be a hosting company http://www.linkedin.com/companies/system-in-place.\n\nI would guess that if he doesn't manage to break the market, he will find something useful to do with it that will benefit him and probably bitcoin as a whole (though maybe not all individual users of bitcoin)."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3762#msg3762"},{"f":"d1337r","d":1279380821,"b":[["t","I wonder how much he spends for using these 1000 cores... Because the price of bitcoins you get is NOT much larger than price you have to pay to generate them."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3764#msg3764"},{"f":"sirius","d":1279382429,"b":[["t","Nenolod, you're welcome to join this forum or #bitcoin-dev on Freenode. It would be interesting to have a chat with you.\n\nBTW, Nenolod writes on Twitter:"],["q","bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.","Quote"],["t","He hasn't sold anything at BitcoinExchange.com and the service is down just for technical maintenance. Should be up today or tomorrow. Maybe he meant that 1500 € was the rate for the 84,732 BTC he supposedly has."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3768#msg3768"},{"f":"Some Mouse","d":1279384085,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3771#msg3771"},{"f":"satoshi","d":1279385766,"b":[["t","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%.\n\nBut if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3773#msg3773","s":1,"n":231,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/231/"},{"f":"The Madhatter","d":1279386738,"b":[["t","Satoshi, could you explain this security safeguard? Is this an undocumented feature of the Bitcoin client or something?"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3775#msg3775"},{"f":"Some Mouse","d":1279389366,"b":[["t","It looks like the generation rate dropped to about half about six hours ago.\n\nSome of the things he mentions are a bit suspicious. Generating 207... then 913 coins. The former could be explained by selling a random number, the latter... In addition, a thousand cores on Amazon EC2 instances is not so cheap as to make it economical even if he prepaid for the nodes."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3781#msg3781"},{"f":"d1337r","d":1279390792,"b":[["t","Well, yeah. Even at the usual difficulty level generating coins is NOT so profitable, and at the harder one, it is just pure waste of real money."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3783#msg3783"},{"f":"dwdollar","d":1279394567,"b":[["t","Maybe he's trying to cause panic selling through rumor and hearsay.  Wouldn't be the first time someone's tried."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3790#msg3790"},{"f":"SmokeTooMuch","d":1279396197,"b":[["t","I can't see whats malicious about his actions.\nHording bitcoins and selling them later to create inflation ?\nSo ? Wow, inflation, that's definitely something a free market can't handle ..."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3793#msg3793"},{"f":"BitcoinFX","d":1279403992,"b":[["t","Nenolod is a highly talented individual, coder and open source developer according to http://nenolod.net/about/ where he indicates he has \"highly functional autism.\"\n\nWith the up most respect I welcome his 'actions' to openly challenge Bitcoin. As the technical director of http://www.systeminplace.net/ he certainly has the processing power to back-up the claims.\n\nI cannot imagine that a founding member of http://atheme.org/ has malicious intent against Bitcoin. I'm sure Nenolod is just 'testing' Bitcoin and will find a good use for all those Bitcoins !\n\n~ Anyone who destroys 'money' in the name of art or otherwise will always regret it...\n\nSee: K Foundation Burn a Million Quid - http://en.wikipedia.org/wiki/K_Foundation_Burn_a_Million_Quid  Cry"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3811#msg3811"},{"f":"Anonymous","d":1279408605,"b":[["q","Maybe he's trying to cause panic selling through rumor and hearsay.  Wouldn't be the first time someone's tried.","Quote from: dwdollar on July 17, 2010, 07:22:47 PM"],["t","Cause a panic or a problem and then take advantage of the confusion to push through your agenda...\n\nhmmmmm...where have I heard that before? Wink"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3826#msg3826"},{"f":"SmokeTooMuch","d":1279416703,"b":[["t","http://twitter.com/nenolod"],["q","bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.\n11:34 AM Jul 15th via web","Quote"],["t","I'm curious about that. Is this why bitcoinexchange.com is down ?"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3853#msg3853"},{"f":"Anonymous","d":1279417073,"b":[["q","http://twitter.com/nenolod\n\n> Quote\n> bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.\n> 11:34 AM Jul 15th via web\n\nI'm curious about that. Is this why bitcoinexchange.com is down ?","Quote from: SmokeTooMuch on July 18, 2010, 01:31:43 AM"],["t","He probably exchanged more bitcoins than the exchange has cash reserves ....\n\nI thought there was a daily limit on the amount of bitcoins you could exchange at one time?"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3855#msg3855"},{"f":"Babylon","d":1279417123,"b":[["t","bitcoin exchange has been down for a while.  I don't think it has anything to do with him."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3856#msg3856"},{"f":"kosovito","d":1279417721,"b":[["q","as expected, bitcoin difficulty cranked up to 181.5. this basically takes the little man out of the equasion...","Quote"],["t","I am really worried about this...."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3860#msg3860"},{"f":"Babylon","d":1279417852,"b":[["t","I'm not.  It will adjust downward again once he takes his node offline. "]],"u":"https://bitcointalk.org/index.php?topic=431.msg3863#msg3863"},{"f":"SmokeTooMuch","d":1279419143,"b":[["t","Bitcoin is not about generating coins and sell them for money.\nBitcoin is about trading and people should start seeing it this way.\nOf course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3872#msg3872"},{"f":"eugene2k","d":1279419390,"b":[["t","Hmm... think I'll rent a few servers too for easy money..."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3874#msg3874"},{"f":"sirius","d":1279420904,"b":[["q","http://twitter.com/nenolod\n\n> Quote\n> bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.\n> 11:34 AM Jul 15th via web\n\nI'm curious about that. Is this why bitcoinexchange.com is down ?","Quote from: SmokeTooMuch on July 18, 2010, 01:31:43 AM"],["q","BTW, Nenolod writes on Twitter:\n\n> Quote\n> bitcoinexchange: demolished - 84,732 BTC / 1500 EUR profit (for 50,000 BTC) looooooooooooooooool.\n\nHe hasn't sold anything at BitcoinExchange.com and the service is down just for technical maintenance. Should be up today or tomorrow. Maybe he meant that 1500 € was the rate for the 84,732 BTC he supposedly has.","Quote from: sirius-m on July 17, 2010, 04:00:29 PM"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3885#msg3885"},{"f":"FreeMoney","d":1279421616,"b":[["q","Hmm... think I'll rent a few servers too for easy money...","Quote from: eugene2k on July 18, 2010, 02:16:30 AM"],["t","You actually found servers to rent at a price to make this profitable? "]],"u":"https://bitcointalk.org/index.php?topic=431.msg3892#msg3892"},{"f":"Babylon","d":1279423807,"b":[["t","His stated goal of bankrupting the exchanges is where I think his basic mistake is.  I don't think he realizes that bitcoinmarket is not an exchange in the same way bitcoinexchange is.  It's a market place and if he sells enough bitcoins to exhaust the current demand he will make the price go down, for a while, but he won't be making any real difference.  He will make himself some money, but he seems to be doing so at the expense of his server clients, which is pretty poor business practices and I hope it is pointed out to them."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3908#msg3908"},{"f":"Bitcoiner","d":1279425164,"b":[["q","Bitcoin is not about generating coins and sell them for money.\nBitcoin is about trading and people should start seeing it this way.\nOf course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you.","Quote from: SmokeTooMuch on July 18, 2010, 02:12:23 AM"],["q","operation: bankrupt the bitcoin exchanges is now underway.","Quote"],["t","LOL\n\nThough, I'm not sure how an exchange can be \"bankrupted\". Any trade should always be zero-sum or profitable for an exchange; only the individual players should possibly lose out. That is, unless the exchange itself is doing their own trades and not simply acting as a mediator."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3912#msg3912"},{"f":"Babylon","d":1279425247,"b":[["q","> Quote from: SmokeTooMuch on July 18, 2010, 02:12:23 AM\n> Bitcoin is not about generating coins and sell them for money.\n> Bitcoin is about trading and people should start seeing it this way.\n> Of course it`s nice to get some \"free\" coins by generating them yourself but if that's all what bitcoin is to you, you should start questioning whether bitcoin is the right thing for you.\n\n> Quote\n> operation: bankrupt the bitcoin exchanges is now underway.\n\nLOL\n\nThough, I'm not sure how an exchange can be \"bankrupted\". Any trade should always be zero-sum or profitable for an exchange; only the individual players should possibly lose out. That is, unless the exchange itself is doing their own trades and not simply acting as a mediator.","Quote from: Bitcoiner on July 18, 2010, 03:52:44 AM"],["t","Yep, that was my point.  The only exchange that isn't just a mediator is, I believe, bitcoinexchange.com"]],"u":"https://bitcointalk.org/index.php?topic=431.msg3913#msg3913"},{"f":"knightmb","d":1279440679,"b":[["q","So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.\nHis name is William Pitock aka Nenolod http://twitter.com/nenolod\n\nWhat do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.\nIf he does, we all loose.\n\nI hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.\nAlso, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3\nso I can prove him he's wrong.\n\nPlease discuss the issue.","Quote from: wobber on July 17, 2010, 01:21:16 PM"],["t","I'm 100% certain that he isn't really generating that much and I'll leave it at that."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3952#msg3952"},{"f":"eugene2k","d":1279446947,"b":[["q","> Quote from: eugene2k on July 18, 2010, 02:16:30 AM\n> Hmm... think I'll rent a few servers too for easy money...\n\nYou actually found servers to rent at a price to make this profitable?","Quote from: FreeMoney on July 18, 2010, 02:53:36 AM"],["t","Not sure as I have no idea what their output will be, but for the sake of experiment..."]],"u":"https://bitcointalk.org/index.php?topic=431.msg3957#msg3957"},{"f":"aceat64","d":1279481117,"b":[["q","> Quote from: wobber on July 17, 2010, 01:21:16 PM\n> So this guy has about 1000 cores generating bitcoins. About 10% of the total amount fo BTC.\n> His name is William Pitock aka Nenolod http://twitter.com/nenolod\n>\n> What do you think? If he cannot prove the system isn't sustainable, he wins, because he will have lots of bitcoins.\n> If he does, we all loose.\n>\n> I hope he will post here, as we discuss HIS ACTIONS and not HIS PERSON.\n> Also, I hope he will pay me 31337 bitcoins at this address 1EZdM6HBRn4BQNa2Bqcyh47fQWYFS5Ujr3\n> so I can prove him he's wrong.\n>\n> Please discuss the issue.\nI'm 100% certain that he isn't really generating that much and I'll leave it at that.","Quote from: knightmb on July 18, 2010, 08:11:19 AM"],["t","I agree, there are many things about his statements which don't seem to be in line with reality. In particular his quoted generation rates are not divisible by 50."]],"u":"https://bitcointalk.org/index.php?topic=431.msg4044#msg4044"},{"f":"SmokeTooMuch","d":1279482798,"b":[["t","when you modulo-devide it trough 50, the rest could be from transaction fee, he's running ~1000 instances (or at least cores) of bitcoin, so the probability of him getting transaction fees is very high."]],"u":"https://bitcointalk.org/index.php?topic=431.msg4047#msg4047"},{"f":"knightmb","d":1279488280,"b":[["q","when you modulo-devide it trough 50, the rest could be from transaction fee, he'`s running ~1000 instances (or at least cores) of bitcoin, so the probability of he getting transaction fees is very high.","Quote from: SmokeTooMuch on July 18, 2010, 07:53:18 PM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=431.msg4069#msg4069"},{"f":"satoshi","d":1279490178,"b":[["t","Typically, over 25,000 BTC."]],"u":"https://bitcointalk.org/index.php?topic=431.msg4073#msg4073","s":1,"n":244,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/244/"}]},{"id":"p116","k":"p","s":"bitcointalk","t":"BUG Report: Rounding glitch","u":"https://bitcointalk.org/index.php?topic=432","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/116/","m":[{"f":"The Madhatter","d":1279375803,"b":[["t","Check this out...\n\nI just installed 0.3.1 on two different machines and moved one bitpenny (0.01):\n\n-= Before the transfer =-\n\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\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\n-= AFTER the transfer =-\n\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\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}\n\nI personally think it is a display problem, but I can't be sure.. strange, no?\n\nBoth machines are running FreeBSD 7.2/amd64."]],"u":"https://bitcointalk.org/index.php?topic=432.msg3748#msg3748"},{"f":"satoshi","d":1279382772,"b":[["t","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.\n\n1.139999999999 is longer than bitcoin can internally represent.\n\ninternally, it could only be:\n1.13999999 or\n1.14000000\n\n1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000.\n\nThe code is this:\n(double)GetBalance() / (double)COIN.\n\n(I can't think of an easy way to fix it at the moment)"]],"u":"https://bitcointalk.org/index.php?topic=432.msg3769#msg3769","s":1,"n":229,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/229/"}]},{"id":"p117","k":"p","s":"bitcointalk","t":"Privacy versus Safety: handling change","u":"https://bitcointalk.org/index.php?topic=434","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/117/","m":[{"f":"Gavin Andresen","d":1279376026,"b":[["t","Here's how you can lose coins by backing up and restoring your wallet file:\n\nLets say you have one shiny 1,000 Bitcoin coin in your wallet (it's actually just a transaction for 1,000 bitcoins paid to a public key that's stored in your wallet).\n\nYou backup that file.\n\nNow you spend 1 Bitcoin.  Your shiny 1,000 BTC coin is broken into 1BTC, plus 999BTC in change.  That change is given a new, different public key.\n\nNow if you restore your wallet file, Bitcoin sees that the 1,000BTC coin has been spent-- 1BTC was sent somewhere, and the other 999BTC was sent somewhere else.  Because you don't have the key for the 999BTC, it has no idea that those coins belong to you.\n\nSo they're lost.\n\nTrying out alternative policies for handling change on the TEST network would be a good idea, in my opinion.\n\nMaybe change transactions should always get signed with the same public key, so you wouldn't lose coins when restoring your wallet... although that would give you less privacy because it would tend to tie all your transactions together.\n\nMaybe your wallet should get initially populated with 100 \"change\" addresses, with one randomly chosen as needed.  And some super-geeky way of replacing them with another, new, 100 addresses.\n\nMaybe there's an even better way of handling the \"I lost BTC when I restored my wallet\" problem; ideas?"]],"u":"https://bitcointalk.org/index.php?topic=434.msg3750#msg3750"},{"f":"Insti","d":1279376728,"b":[["t","Isn't this just a result of restoring to an out of date backup?\n\nThat aside,\n\nSimple possible change return methods:\n\na) change gets returned to the address it came from.\nb) change gets returned to a newly generated bitcoin address.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=434.msg3755#msg3755"},{"f":"satoshi","d":1279384059,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=434.msg3770#msg3770","s":1,"n":230,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/230/"}]},{"id":"p118","k":"p","s":"bitcointalk","t":"Bitcoin 0.3.2 released","u":"https://bitcointalk.org/index.php?topic=437","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/118/","m":[{"f":"satoshi","d":1279402551,"b":[["t","Download links available now on bitcoin.org.  Everyone should upgrade to this version.\n\n- Added a simple security safeguard that locks-in the block chain up to this point.\n- Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to.\n- Spanish translation by milkiway.\n- French translation by aidos.\n\nThe security safeguard makes it so even if someone does have more than 50% of the network's CPU power, they can't try to go back and redo the block chain before yesterday.  (if you have this update)\n\nI'll probably put a checkpoint in each version from now on.  Once the software has settled what the widely accepted block chain is, there's no point in leaving open the unwanted non-zero possibility of revision months later."]],"u":"https://bitcointalk.org/index.php?topic=437.msg3807#msg3807","s":1,"n":232,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/232/"},{"f":"llama","d":1279403785,"b":[["t","Satoshi,\n\nThe \"block lock\" is an interesting idea, and I'll have to think more about it.  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.\n\nInstead, you should only lock in everything except the last thousand or so blocks (the exact number should be a subject of future inquiry).  Maybe this is actually what you did?\n\nAlso, I'm assuming that the block lock means that the blocks will also come prepackaged with the client.  Is this so?"]],"u":"https://bitcointalk.org/index.php?topic=437.msg3810#msg3810"},{"f":"satoshi","d":1279407264,"b":[["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.","Quote from: llama on July 17, 2010, 09:56:25 PM"],["t","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."],["q","Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client.  Is this so?","Quote from: llama on July 17, 2010, 09:56:25 PM"],["t","Sorry, not yet, but I do want to make the initial block download faster."]],"u":"https://bitcointalk.org/index.php?topic=437.msg3825#msg3825","s":1,"n":235,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/235/"},{"f":"kiav","d":1279453245,"b":[["q","...Everyone should upgrade to this version...","Quote from: satoshi on July 17, 2010, 09:35:51 PM"],["t","I use 0.3.0 beta for Windows.\n\n• Do I need to deinstall it before 0.3.2 installation?\n\n• What about my bitcoins I already generated? Do I need to backup them and restore after installation?"]],"u":"https://bitcointalk.org/index.php?topic=437.msg3971#msg3971"},{"f":"SmokeTooMuch","d":1279454673,"b":[["q","Do I need to deinstall it before 0.3.2 installation?","Quote"],["t","No, you don't."],["q","What about my bitcoins I already generated? Do I need to backup them and restore after installation?","Quote"],["t","No, you don't, but it's always good to make a backup."]],"u":"https://bitcointalk.org/index.php?topic=437.msg3977#msg3977"},{"f":"milkiway","d":1279457008,"b":[["q","- Spanish translation by milkiway.","Quote from: satoshi on July 17, 2010, 09:35:51 PM"],["t","It looks great Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=437.msg3981#msg3981"},{"f":"Traktion","d":1279457027,"b":[["t","FYI, 0.3.2 on Linux (Ubunu 10.04) the task bar icon no longer appears. It seems to run fine though."]],"u":"https://bitcointalk.org/index.php?topic=437.msg3982#msg3982"},{"f":"AndrewBuck","d":1279462444,"b":[["t","Traktion, you could try running the client with -minimizetotray that seemed to work for me (10.04 as well).  It will start minimized there so you need to click on it to get the main window but it seems to work after that.\n\n-Buck"]],"u":"https://bitcointalk.org/index.php?topic=437.msg3991#msg3991"},{"f":"lachesis","d":1279463294,"b":[["q","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.","Quote from: satoshi on July 17, 2010, 10:54:24 PM"],["t","Cool! How exactly are you analyzing the topography of the chain?"]],"u":"https://bitcointalk.org/index.php?topic=437.msg3993#msg3993"},{"f":"Traktion","d":1279466292,"b":[["q","Traktion, you could try running the client with -minimizetotray that seemed to work for me (10.04 as well).  It will start minimized there so you need to click on it to get the main window but it seems to work after that.\n\n-Buck","Quote from: AndrewBuck on July 18, 2010, 02:14:04 PM"],["t","Ah, that sorted it! Thanks! I guess the default has changed between the versions."]],"u":"https://bitcointalk.org/index.php?topic=437.msg4000#msg4000"},{"f":"knightmb","d":1279477191,"b":[["t","Anyone know where the changelist is, I'm curious to what was fixed/changed/etc. "]],"u":"https://bitcointalk.org/index.php?topic=437.msg4031#msg4031"},{"f":"satoshi","d":1279479501,"b":[["t","The change list is basically encompassed by what's listed in the first message.  Everyone should upgrade to get the important security improvements.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=437.msg4037#msg4037","s":1,"n":241,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/241/"}]},{"id":"p119","k":"p","s":"bitcointalk","t":"Did block generation crawl to a halt?","u":"https://bitcointalk.org/index.php?topic=441","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/119/","m":[{"f":"Anonymous","d":1279412404,"b":[["t","adgf"]],"u":"https://bitcointalk.org/index.php?topic=441.msg3838#msg3838","sj":"adg"},{"f":"Anonymous","d":1279417701,"b":[["q","Say, the last 6 hours? They seem few and far between, maybe just a couple per hour? Confirmations are taking a long time. Did the super node take his computers offline?\n\nhttp://nullvoid.org/bitcoin/statistix.php\n\nThat says the last block was found over 50 minutes ago.","Quote from: davidonpda on July 18, 2010, 12:20:04 AM"],["t","Maybe he pushed the difficulty level so high it will take a bit for the remaining nodes to generate?Apparently his supernode was doing the majority of the generating at one point.I would be interested if he posts on the forum or someone gets in contact with him how his experiment went?\n\n Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=441.msg3859#msg3859"},{"f":"mtgox","d":1279417842,"b":[["t","How often does the difficulty get adjusted?"]],"u":"https://bitcointalk.org/index.php?topic=441.msg3862#msg3862"},{"f":"Quantumplation","d":1279423383,"b":[["t","The difficulty gets reevaluated and adjusted every 2016 blocks."]],"u":"https://bitcointalk.org/index.php?topic=441.msg3901#msg3901"},{"f":"MacRohard","d":1279423468,"b":[["t","I created a realtime graph of the current block generation speed here;\n\nhttp://titania.smutfairy.com/~rm/time.gif"]],"u":"https://bitcointalk.org/index.php?topic=441.msg3902#msg3902"},{"f":"mtgox","d":1279465926,"b":[["t","MacRohard: Cool graph. It would be nice if it should time on the x axis and number of blocks on the y"]],"u":"https://bitcointalk.org/index.php?topic=441.msg3998#msg3998"},{"f":"satoshi","d":1279496127,"b":[["t","Nice graph!  A moving average to smooth it out would be nice.\n\nhttp://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24 hours, or 8.8 per hour."]],"u":"https://bitcointalk.org/index.php?topic=441.msg4095#msg4095","s":1,"n":245,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/245/"}]},{"id":"p120","k":"p","s":"bitcointalk","t":"Faster SHA-256, MSVC build ","u":"https://bitcointalk.org/index.php?topic=453","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/120/","m":[{"f":"dkaparis","d":1279459730,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=453.msg3986#msg3986"},{"f":"satoshi","d":1279488249,"b":[["t","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.\n\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.\n\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\n(hope you don't mind I renamed your thread, SHA-256 optimisation is something important that I keep forgetting about)"]],"u":"https://bitcointalk.org/index.php?topic=453.msg4068#msg4068","s":1,"n":243,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/243/","sj":"Re: MSVC build & SHA-256"}]},{"id":"p121","k":"p","s":"bitcointalk","t":"Builds for Ubuntu?","u":"https://bitcointalk.org/index.php?topic=454","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/121/","m":[{"f":"ArtemZ","d":1279463238,"b":[["t","Hi,\nSince Ubuntu is most popular desktop linux distro why there are no repository or even builds of bitcoin client? I think someone should start to create something like repo with bitcoin's builds, better ppa on launchpad. It will be so cool to have native payment system in ubuntu, maybe one day bitcoin will be included in the main repository"]],"u":"https://bitcointalk.org/index.php?topic=454.msg3992#msg3992"},{"f":"d1337r","d":1279463711,"b":[["t","Well, If you can compile bitcoin and create a source DEB, you can set up a PPA."]],"u":"https://bitcointalk.org/index.php?topic=454.msg3994#msg3994"},{"f":"imnichol","d":1279641324,"b":[["t","I'm actually working on setting up a PPA for bitcoin, but it also requires the dev branch of wxWidgets, so I've got to get that up first."]],"u":"https://bitcointalk.org/index.php?topic=454.msg4475#msg4475"},{"f":"Dark_Ghost","d":1279663860,"b":[["t","keep us informed, i'm on ubuntu 10.04 64bit and i'd like to see a ubuntu specific build of bitcoin and bitcoind."]],"u":"https://bitcointalk.org/index.php?topic=454.msg4545#msg4545"},{"f":"imnichol","d":1279814604,"b":[["t","Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet.  Anyone who can throw some documentation my way would be awesome.  Right now I'm trying a different strategy."]],"u":"https://bitcointalk.org/index.php?topic=454.msg5059#msg5059"},{"f":"melvster","d":1279816469,"b":[["q","Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet.  Anyone who can throw some documentation my way would be awesome.  Right now I'm trying a different strategy.","Quote from: imnichol on July 22, 2010, 04:03:24 PM"],["t","I run ubuntu on my desktop maybe I can help ...\n\nEDIT: first time I've tried it, but I made a launch pad project here: https://launchpad.net/bitcoin  hopefully we can work out how to do ppa etc. "]],"u":"https://bitcointalk.org/index.php?topic=454.msg5069#msg5069"},{"f":"imnichol","d":1279818882,"b":[["q","I run ubuntu on my desktop maybe I can help ...\n\nEDIT: first time I've tried it, but I made a launch pad project here: https://launchpad.net/bitcoin  hopefully we can work out how to do ppa etc. ","Quote from: melvster on July 22, 2010, 04:34:29 PM"],["t","I've got a launchpad ppa set up too, but launchpad is a huge PITA from what I've tried."]],"u":"https://bitcointalk.org/index.php?topic=454.msg5078#msg5078"},{"f":"imnichol","d":1279913526,"b":[["t","I've got bitcoin compiled for AMD64 linux.  yay.\nSo now I've just got to figure out how to hack it so that I can package it as a deb."]],"u":"https://bitcointalk.org/index.php?topic=454.msg5368#msg5368"},{"f":"eugene2k","d":1280043365,"b":[["q","Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet.  Anyone who can throw some documentation my way would be awesome.  Right now I'm trying a different strategy.","Quote from: imnichol on July 22, 2010, 04:03:24 PM"],["t","If I'm not mistaken, Ubuntu's PPA requires you to have your project uploaded in source form. Launchpad then compiles it and offers debs."]],"u":"https://bitcointalk.org/index.php?topic=454.msg5649#msg5649"},{"f":"imnichol","d":1280101590,"b":[["q","If I'm not mistaken, Ubuntu's PPA requires you to have your project uploaded in source form. Launchpad then compiles it and offers debs.","Quote from: eugene2k on July 25, 2010, 07:36:05 AM"],["t","So do I have to do anything special to the source?  I know that the standard method of building a .deb doesn't work, 'make -f makefile.unix' just spits out a binary.  No chance to checkinstall or anything"]],"u":"https://bitcointalk.org/index.php?topic=454.msg5785#msg5785"},{"f":"Cdecker","d":1280499736,"b":[["q","> Quote from: imnichol on July 22, 2010, 04:03:24 PM\n> Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet.  Anyone who can throw some documentation my way would be awesome.  Right now I'm trying a different strategy.\n\nI run ubuntu on my desktop maybe I can help ...\n\nEDIT: first time I've tried it, but I made a launch pad project here: https://launchpad.net/bitcoin  hopefully we can work out how to do ppa etc.  ","Quote from: melvster on July 22, 2010, 04:34:29 PM"],["t","Would you add me to the maintainers of the project on launchpad? My username is cdecker and I have ready built deb packages from my efforts on openSuse Build Service http://bit.ly/bUqiRY"]],"u":"https://bitcointalk.org/index.php?topic=454.msg6655#msg6655"},{"f":"melvster","d":1280667643,"b":[["q","> Quote from: melvster on July 22, 2010, 04:34:29 PM\n> > Quote from: imnichol on July 22, 2010, 04:03:24 PM\n> > Well, I couldn't find any good directions on how to package a .deb for a ppa, but I haven't given up hope yet.  Anyone who can throw some documentation my way would be awesome.  Right now I'm trying a different strategy.\n>\n> I run ubuntu on my desktop maybe I can help ...\n>\n> EDIT: first time I've tried it, but I made a launch pad project here: https://launchpad.net/bitcoin  hopefully we can work out how to do ppa etc.  \n\nWould you add me to the maintainers of the project on launchpad? My username is cdecker and I have ready built deb packages from my efforts on openSuse Build Service http://bit.ly/bUqiRY","Quote from: Cdecker on July 30, 2010, 02:22:16 PM"],["t","Sure!\n\nI've created a team\n\nAdded you .."]],"u":"https://bitcointalk.org/index.php?topic=454.msg6900#msg6900"},{"f":"imnichol","d":1280763468,"b":[["t","Has anyone built a package for the GUI client yet?"]],"u":"https://bitcointalk.org/index.php?topic=454.msg7018#msg7018"},{"f":"Cdecker","d":1280763664,"b":[["q","Has anyone built a package for the GUI client yet?","Quote from: imnichol on August 02, 2010, 03:37:48 PM"],["t","GUI builds are quite a bit harder since they also require WX to be built along with it.\n\nI'll try to create a statically linked version on OBS soon."]],"u":"https://bitcointalk.org/index.php?topic=454.msg7019#msg7019"},{"f":"nimnul","d":1280857875,"b":[["t","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"]],"u":"https://bitcointalk.org/index.php?topic=454.msg7282#msg7282"},{"f":"knightmb","d":1280858086,"b":[["q","Has anyone built a package for the GUI client yet?","Quote from: imnichol on August 02, 2010, 03:37:48 PM"],["t","I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)\nNot a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way."]],"u":"https://bitcointalk.org/index.php?topic=454.msg7284#msg7284"},{"f":"imnichol","d":1280859928,"b":[["q","I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)\nNot a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way.","Quote from: knightmb on August 03, 2010, 05:54:46 PM"],["t","Yeah I've built the binaries before, I want to be able to upgrade via the update manager rather than manually downloading the binaries."]],"u":"https://bitcointalk.org/index.php?topic=454.msg7291#msg7291"},{"f":"knightmb","d":1280861549,"b":[["q","> Quote from: knightmb on August 03, 2010, 05:54:46 PM\n> I've built the client and daemon for Ubuntu 9.04 (should work in later versions ?)\n> Not a package per say, but you can just download the current Linux release and just overwrite the binaries. Not perfect, but it will get a working version for you that way.\n\nYeah I've built the binaries before, I want to be able to upgrade via the update manager rather than manually downloading the binaries.","Quote from: imnichol on August 03, 2010, 06:25:28 PM"],["t","Oh you mean official binaries in package form hosted by the Ubuntu folks?"]],"u":"https://bitcointalk.org/index.php?topic=454.msg7296#msg7296"},{"f":"satoshi","d":1280868971,"b":[["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","Quote from: nimnul on August 03, 2010, 05:51:15 PM"],["t","Yes, 0.3.7 has it.  It was in rev 112."]],"u":"https://bitcointalk.org/index.php?topic=454.msg7328#msg7328","s":1,"n":309,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/309/"}]},{"id":"p122","k":"p","s":"bitcointalk","t":"md5?","u":"https://bitcointalk.org/index.php?topic=458","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/122/","m":[{"f":"fresno","d":1279469815,"b":[["t","I don't seem to be able to find any md5s for your code downloads. Is it just me, or are there none?"]],"u":"https://bitcointalk.org/index.php?topic=458.msg4010#msg4010"},{"f":"Mionione","d":1279486339,"b":[["t","md5 checksums are still widely used but not secure"]],"u":"https://bitcointalk.org/index.php?topic=458.msg4060#msg4060"},{"f":"Mionione","d":1279488827,"b":[["t","md5 is evil, two differents files can have the same md5 checksum (http://www.coresecurity.com/content/md5-harmful)\nbut unfortunately people still use it ;("]],"u":"https://bitcointalk.org/index.php?topic=458.msg4070#msg4070"},{"f":"knightmb","d":1279489725,"b":[["q","md5 is evil, two differents files can have the same md5 checksum (http://www.coresecurity.com/content/md5-harmful)\nbut unfortunately people still use it ;(","Quote from: Mionione on July 18, 2010, 09:33:47 PM"],["t","They can, but the odds that you'll get useful exploit code that just happens to be that collision are still insanely high."]],"u":"https://bitcointalk.org/index.php?topic=458.msg4072#msg4072"},{"f":"lachesis","d":1279499801,"b":[["t","Nah, it's insanely easy nowadays. Have you seen evilize?\n\nhttp://www.mscs.dal.ca/~selinger/md5collision/"]],"u":"https://bitcointalk.org/index.php?topic=458.msg4112#msg4112"},{"f":"d1337r","d":1279523990,"b":[["t","Yeah... In earlier days, you could easily set an 8-letter Upper-Lower-Digit password and be sure no one will be interested in cracking it (which he will do for 30 days minimum). Now, we have Playstation 3's and cloud services, and cracking that MD5 is a matter of minutes or hours. Now i'll have to change every my password to something stronger.\n\nBTW, SMF FTW, cause it uses SHA-256 instead of MD5."]],"u":"https://bitcointalk.org/index.php?topic=458.msg4183#msg4183"},{"f":"fresno","d":1279647540,"b":[["t","Yeah, I guess SHA-256 will be good enough. ;-)"]],"u":"https://bitcointalk.org/index.php?topic=458.msg4496#msg4496"},{"f":"bitcoinex","d":1280092563,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=458.msg5762#msg5762","sj":"gpg!"},{"f":"satoshi","d":1280095617,"b":[["t","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.\n\nhttp://www.bitcoin.org/Satoshi_Nakamoto.asc"]],"u":"https://bitcointalk.org/index.php?topic=458.msg5772#msg5772","s":1,"n":276,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/276/","qt":["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. http://www.bitcoin.org/Satoshi_Nakamoto.asc"],"qc":["general"]}]},{"id":"p123","k":"p","s":"bitcointalk","t":"JSON-RPC password","u":"https://bitcointalk.org/index.php?topic=461","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/123/","m":[{"f":"satoshi","d":1279486162,"b":[["t","I uploaded to SVN my changes to add a password to JSON-RPC.  If you're set up to build, please test it.\n\nThe -server switch is replaced with -rpcpw=<password>, which is also used with bitcoind.\nbitcoin -rpcpw=<password>    -- runs with JSON-RPC port open\nbitcoind -rpcpw=<password>   -- daemon with password\n\nIf you have a better idea for the switch name, let me know, but keep in mind there will eventually be a password for encrypting the database too.  I'm not sure but I think they may want to use different passwords for the two.\n\nIt gives a warning if you don't set a password.\n\nAll commands now require the password as the first parameter.  It'll tell you that if you run \"bitcoind help\".\n\nThe central code:\n\n  // Check password\n  if (params.size() < 1 || params[0].type() != str_type)\n      throw runtime_error(\"First parameter must be the password.\");\n  if (params[0].get_str() != strRPCPassword)\n  {\n      if (strRPCPassword.size() < 15)\n          Sleep(50);\n      begin = strRequest.end();\n      printf(\"ThreadRPCServer incorrect password attempt\");\n      throw runtime_error(\"Incorrect password.\");\n  }\n\nAny comments on these decisions?\n\n1) if (strRPCPassword.size() < 15) Sleep(50);  -- this means if it's a short password, it'll wait 50ms after each attempt.  This might be used as a DoS attack, but I figured if it's a short password, it's more important to protect against brute force password scan.  This may tell outsiders whether the password is less than 15 characters, but less than 15 isn't all that noteworthy, most passwords are less than 15.  If you want to close the DoS possibility, just use a password 15 characters or longer.\n\n2) begin = strRequest.end();  -- if it's a single request with multiple invocations, I throw away the rest if one has a bad password.  This is so you can't stuff it with millions of password attempts in one packet.  What do you think, is this the right thing to do?  (multiple invocation is probably almost never used anyway)\n\nI also fixed the two duplicated commands listed in the help:\n\ngetaddressesbylabel <pw> <label>\ngetbalance <pw>\ngetblockcount <pw>\ngetblocknumber <pw>\ngetconnectioncount <pw>\ngetdifficulty <pw>\ngetgenerate <pw>\ngetinfo <pw>\ngetlabel <pw> <bitcoinaddress>\ngetnewaddress <pw> [label]\ngetreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]\ngetreceivedbylabel <pw> <label> [minconf=1]\nhelp <pw>\nlistreceivedbyaddress <pw> [minconf=1] [includeempty=false]\nlistreceivedbylabel <pw> [minconf=1] [includeempty=false]\nsendtoaddress <pw> <bitcoinaddress> <amount> [comment] [comment-to]\nsetgenerate <pw> <generate> [genproclimit]\nsetlabel <pw> <bitcoinaddress> <label>\nstop <pw>"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4059#msg4059","s":1,"n":242,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/242/"},{"f":"laszlo","d":1279500292,"b":[["t","I guess it's ok for remotely doing it but if your concern is that someone else on the same unix machine can steal your bitcoins this still doesn't help because they can see your command line in /proc, top, ps etc.  It could read the password on stdin or use readline or something, to guard against that particular thing at least.  Allowing it to be passed on the command line is not good, in my opinion.\n\nEven better might be to use a key file, then you can use unix permissions to make it readable to only that user, kind of like ssh does.. then the bitcoind could have an 'authorized_keys' file with the public keys.  Anyway I don't mean to be an ass but the command line thing is just a false sense of security."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4116#msg4116"},{"f":"martin","d":1279502712,"b":[["t","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 Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4131#msg4131"},{"f":"satoshi","d":1279514593,"b":[["t","Right, that is quite a bit better. \n\nCan you give me any examples of other stuff that does it that way?  (and what the command line looks like)\n\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?)"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4169#msg4169","s":1,"n":246,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/246/"},{"f":"Gavin Andresen","d":1279540959,"b":[["t","The Bitcoin Faucets (production and TEST) are now running with this change.\n\nI 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.\n\nI'll try to do some research on how other projects tackle JSON-RPC authentication."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4215#msg4215"},{"f":"Gavin Andresen","d":1279542603,"b":[["t","The Transmission BitTorrent client does authenticated JSON-RPC; see \"Remote Control\" section of:\n https://trac.transmissionbt.com/wiki/ConfigurationParameters\n\nE.g. setting.json file might look like:"],["c","{\n    \"rpc-enabled\":1\n    \"rpc-authentication-required\": 1,\n    \"rpc-password\": \"xxxxxxxxxx\",\n    \"rpc-port\": 9091,\n    \"rpc-username\": \"xxxxxxxxxx\",\n    \"rpc-whitelist-enabled\":1\n    \"rpc-whitelist\":\"127.0.0.1,192.168.*.*\"\n}"],["t","It uses HTTP 'basic' authentication <http://en.wikipedia.org/wiki/Basic_access_authentication> (Authorization: basic base64(username:password) in the HTTP headers)."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4221#msg4221"},{"f":"Gavin Andresen","d":1279552835,"b":[["t","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.\n\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.\n\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 <http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500> 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?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4248#msg4248"},{"f":"satoshi","d":1279556450,"b":[["t","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.\n\nWhat is the most popular and common settings file format?\n\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."],["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.","Quote from: gavinandresen on July 19, 2010, 12:02:39 PM"],["t","You're also confusing me, what do you mean?  Did I do something unintended?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4268#msg4268","s":1,"n":248,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/248/"},{"f":"Gavin Andresen","d":1279558728,"b":[["q","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?","Quote from: satoshi on July 19, 2010, 04:20:50 PM"],["t","You ask hard questions!  Most common: probably Windows INI <http://en.wikipedia.org/wiki/INI_file> files, because Windows is most common OS.\n\nI'd lobby for using JSON; it's (mostly) a subset of YAML (which is a common choice for config files), so any JSON or YAML parser will read it."],["q","HTTP 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?","Quote"],["t","I think the only big advantage is that it keeps authentication where it belongs in the transport layer, so if, in the future, you do want to go with full-fledged HTTPS with certificates the API doesn't have to change."],["q","> Quote from: gavinandresen on July 19, 2010, 12:02:39 PM\n> 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.\nYou're also confusing me, what do you mean?  Did I do something unintended?","Quote"],["t","No, I just confused \"command\" with \"parameter\", and did this:"],["c","> bitcoind help\nerror: First parameter must be the password.\n> bitcoind <my password> help\nerror: unknown command: <my password>\n>bitcoind help <my password>\n ... that works."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4284#msg4284"},{"f":"Vasili Sviridov","d":1279560208,"b":[["t","Should bitcoind be more of a system-wide daemon? With PAM authentication and support for all system users, not just the one running it?\nLike scanning /home/*/.bitcoin folders for a wallet file and provide access by both username and system password..."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4295#msg4295"},{"f":"laszlo","d":1279579992,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4380#msg4380"},{"f":"satoshi","d":1279670720,"b":[["t","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\n\nIs there a settings file thing in Boost?\n\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?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4577#msg4577","s":1,"n":250,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/250/"},{"f":"martin","d":1279672226,"b":[["t","You could do worse than using yaml <http://www.yaml.org/spec/1.2/spec.html> for the settings"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4582#msg4582"},{"f":"satoshi","d":1279691494,"b":[["t","I was researching config file formats, here's a comparison.\n\nYAML is massive.  I'm not sure there's a lightweight easy to build library we can integrate into our project.  Seems overkill.\n\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}\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\n\nBoost has boost::program_options.\n\nWe could read lines ourselves and feed them into a map<string, string> mapConfig.\n\nwhile (!eof)\n  read line\n  if '#' found, truncate line\n  split line at first ':' -> key, value\n  mapConfig.insert(key, value)\n\nIf we use the syntax:\n# comment\nkey : value\n\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.\n\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\"]\n\nAlthough it has to be all on one line then.\n\nI guess I'm leaning towards self parsed mapConfig:\n# comment\nkey : value"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4646#msg4646","s":1,"n":251,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/251/"},{"f":"lachesis","d":1279695163,"b":[["t","The simplest Linux config files typically have formats that look something like this:"],["c","# how often (in minutes) data is saved when all interface are offline\nOfflineSaveInterval 30\n\n# force data save when interface status changes (1 = enabled, 0 = disabled)\nSaveOnStatusChange 1\n\n# file used for logging if UseLogging is set to 1\nLogFile \"/var/log/vnstat.log\"\n\n# file used as daemon pid / lock file\nPidFile \"/var/run/vnstat.pid\""],["t","The standard extension, if there is one, is .conf. Hash (#) is the most common comment character by far. Semicolon (Wink and C-style comments crop up too.\n\nI think a good, human-manipulatable config file that ISN'T part of the wallet would be a big step forward. There are a lot of options that are currently specified on the command line (noirc, for example, or -minimizetotray) which might be better specified in a config file."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4660#msg4660"},{"f":"martin","d":1279702240,"b":[["t","Out of those options Satoshi presented, I'd go with the self parsed file with the key/value separator character being a space like lachesis suggested, especially if that's the typical format for at least one OS."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4680#msg4680"},{"f":"Gavin Andresen","d":1279714270,"b":[["t","I think there's no such thing a a \"typical\" settings file on Linux!\n\nI just did a quick survey of 20 .conf files in /etc on my debian system, and found:\n 1 file used \"key value\"\n 5 used \"key=value\"  (actually, a couple were  \"key = value\", allowing whitespace around the \"=\")\n 14 did their own thing.\n\nThe 14 that did their own thing were all over the map; from one-value-per-line to \"key:value\" to full-blown XML.  # is\nthe universal comment character in the Linux world.\n\nMy vote would be for:\n\n# comment\nkey1=value1"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4709#msg4709"},{"f":"satoshi","d":1279728477,"b":[["q","I just did a quick survey of 20 .conf files in /etc on my debian system, and found:\n 1 file used \"key value\"\n 5 used \"key=value\" ","Quote from: gavinandresen on July 21, 2010, 12:11:10 PM"],["t","Thanks for that survey!\n\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\n\nAllright then, lets go with self-parsed mapConfig, syntax:\n# comment\nkey=value\n\nfile extension .conf.  What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?   \n\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\"\n        key = value   # guess this is ok too\n  nextkey = value\n      right = justified\n\nThe normal syntax should be \"key=value\", but you can't blame people for the occasional \"key = value\"."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4758#msg4758","s":1,"n":252,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/252/"},{"f":"satoshi","d":1279733469,"b":[["t","boost::program_options has the same \"key=value\" format.  Gavin pointed out we can use it in a simple way as a parser without getting into all the esoteric c++ syntax like typed value extraction.  We can use more features if we want later.\n\nLets go ahead with HTTP basic authentication instead of password as a parameter."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4775#msg4775","s":1,"n":253,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/253/"},{"f":"Gavin Andresen","d":1279761086,"b":[["t","I volunteered to implement this, and made good progress today.  Satoshi: I should have patches for you tomorrow.\n\nDone: teach Bitcoin to read settings from {BITCOIN_DIR}/bitcoin.conf file, and added -conf=path_to_config_file.conf command-line option. \nDone: teach Bitcoin RPC to require HTTP Basic authentication, and reject requests with the wrong username/password.\n\nTODO: teach Bitcoin command-line RPC to add the Authorization: header.  You won't have to give the username/password when controlling bitcoin from the command line, it'll read them from the bitcoin.conf file and Do the Right Thing.\nTODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.\nTODO: limit password guessing attempts if the rpc.password is < 15 characters long.\nTODO: update the JSON-RPC wiki page\n\nAfter all that is done and I've sent patches to Satoshi, I'm going to add a couple more things to bitcoin.conf :\n\nport=   # to set the listen port (override default 8333)\nrpc.port= # to set the JSON-RPC port (override default 8332)\n\nWith the existing -datadir option, that'll make it easier for me to run multiple bitcoins on one box."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4908#msg4908"},{"f":"lachesis","d":1279762066,"b":[["t","Excellent Gavin. We should start a list of proposed config file options in this thread.\n\nI, for one, suggest a noirc (off by default) option and a minimizetotray option, both of which would do the same thing as the command-line switches by the same name. That'll stop the hackery of launching my Bitcoin with -minimizetotray each time. Also, maybe -server and -daemon should get similar options?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4913#msg4913"},{"f":"Gavin Andresen","d":1279763500,"b":[["t","I've implemented it so that all the command-line options can also be specified in the bitcoin.conf file.\n\nOptions given on the command line override options in the conf file.  But I need to do more testing, especially with the \"multiargs\" options like \"addnode\"."]],"u":"https://bitcointalk.org/index.php?topic=461.msg4918#msg4918"},{"f":"satoshi","d":1279766063,"b":[["q","TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.","Quote from: gavinandresen on July 22, 2010, 01:11:26 AM"],["t","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\n        MyMessageBox(\"Warning: rpc password is blank, use -rpcpw=<password>\", \"Bitcoin\", wxOK | wxICON_EXCLAMATION);\n#else\n        fprintf(stdout, \"Warning: rpc password is blank, use -rpcpw=<password>\");\n#endif"]],"u":"https://bitcointalk.org/index.php?topic=461.msg4928#msg4928","s":1,"n":254,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/254/"},{"f":"Gavin Andresen","d":1279897905,"b":[["t","I've updated the RPC wiki page <http://www.bitcoin.org/wiki/doku.php?id=api> for how the password stuff will work in Bitcoin 0.3.3.\n\nOne nice side effect: you can prepare for the changes now; create a bitcoin.conf file with a username and password and modify your JSON-RPC code to do the HTTP Basic Authentication thing.  Old code will just ignore the .conf file and the Authorization: HTTP header.\n\nQuestion 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.  I don't want to just duplicate the HTTP Basic authentication Wikipedia page."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5296#msg5296"},{"f":"satoshi","d":1279904860,"b":[["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.","Quote from: gavinandresen on July 23, 2010, 03:11:45 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5337#msg5337","s":1,"n":255,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/255/"},{"f":"satoshi","d":1279905271,"b":[["t","Gavin's changes look good.  I think everything is complete.  Here's a test build, please test it!\n\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5338#msg5338","s":1,"n":256,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/256/"},{"f":"Gavin Andresen","d":1279907793,"b":[["q","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.","Quote from: satoshi on July 23, 2010, 05:07:40 PM"],["t","OK, I did Python and PHP, and I added what I know about Java.  Can somebody who has used Java JSON-RPC update the wiki page with a working example?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5342#msg5342"},{"f":"lachesis","d":1279909328,"b":[["t","The password definitely shouldn't be required. Also, the new code chokes on \"rpcpassword=\". If there's no config file, the config file doesn't contain an rpcpassword line, or it contains \"rpcpassword=\", the password should be disabled."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5348#msg5348"},{"f":"Gavin Andresen","d":1279911094,"b":[["q","The password definitely shouldn't be required.","Quote from: lachesis on July 23, 2010, 06:22:08 PM"],["t","I strongly disagree; software should be secure by default, and running bitcoind without a password (or bitcoin -server) is definitely NOT secure.\n\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.\""]],"u":"https://bitcointalk.org/index.php?topic=461.msg5357#msg5357"},{"f":"satoshi","d":1279917543,"b":[["t","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=\"?\n\nI can see both points.\n\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?\n\nOTOH, what if there's a template conf file, with\nrpcpassword=  # fill in a password here\n\nThere are many systems that don't allow you to log in without a password.  This forum, for instance.  Gavin's point seems stronger.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5383#msg5383","s":1,"n":260,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/260/"},{"f":"Gavin Andresen","d":1279919885,"b":[["q","BTW, 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?","Quote from: satoshi on July 23, 2010, 08:39:03 PM"],["t","Yes, that's right, rpcpassword is only required if you use -server or -daemon or bitcoind (I just tested to be sure).\n\nRE: what if the programmer can't figure out how to make their legacy COBOL code do HTTP authentication?\nThen I think another config file setting to explicitly turn off RPC authentication would be better than a magical \"if you set a blank rpcpassword then that turns off authentication.\"   But I wouldn't implement that until somebody really does have a problem or until we have more than one way of doing the authentication (maybe https someday...).\n\nlachesis: is supporting HTTP Basic Authentication a problem for you?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5390#msg5390"},{"f":"lachesis","d":1279939583,"b":[["t","Gavin, no. I know my way around urllib2 so that's not a problem. I would like to see the option to disable password authentication in the bitcoin.conf. We really shouldn't be protecting (advanced) users from themselves.\n\nI was just annoyed that to even start -server (albeit on my test client), I had to edit the config file and insert a password. I can always hack my version of Bitcoin to not require a password by default if that's what I want, but I don't like the fact that bitcoin completely fails to start when I put in \"rpcpassword=\" with -server. I think the right way to do it would be to warn users (perhaps with a popup box if the GUI is starting) but still start the other stuff, even if the RPC server won't start.\n\nRunning with a password only marginally improves the security for a lot of applications anyway, since that password will have to sit in an httpd-readable file for my web server to execute JSON-RPC commands. The only user that's ever been hacked on my server? httpd. It is an important step for machines with multiple users, though, as is allowing the port number to be changed."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5434#msg5434"},{"f":"lachesis","d":1280087555,"b":[["t","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:"],["c","POST / HTTP/1.1\nUser-Agent: json-rpc/1.0\nHost: 127.0.0.1\nContent-Type: application/json\nContent-Length: 40\nAccept: application/json\nAuthorization: Basic YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93\nb3JsZGhlbGxvd29ybGRoZWxsb3dvcmxk"],["t","It 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.\n\nThis can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:"],["c","result.erase(std::remove(result.begin(), result.end(), ''), result.end());\nresult.erase(std::remove(result.begin(), result.end(), '\r'), result.end());"],["t","There's probably a more elegant solution, but that works for me. Here's a patch:\nhttp://www.alloscomp.com/bitcoin/patches/bitcoin-svn-109-rpcbug-2010-07-25.patch"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5738#msg5738"},{"f":"gazoakley","d":1280088482,"b":[["t","Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?\n\nAlso, whilst we're on the subject is bitcoind only binding to the loopback interface?"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5741#msg5741"},{"f":"lachesis","d":1280089816,"b":[["q","Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?\n\nAlso, whilst we're on the subject is bitcoind only binding to the loopback interface?","Quote from: gazoakley on July 25, 2010, 08:08:02 PM"],["t","The PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:\nhttp://username:password@localhost:8332/"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5745#msg5745"},{"f":"gazoakley","d":1280090093,"b":[["q","> Quote from: gazoakley on July 25, 2010, 08:08:02 PM\n> Whilst putting some security in is a good idea, it appears the JSON-RPC PHP doesn't support basic HTTP authentication right now. It'd have to be hacked in. Is anyone else using similar libraries going to encounter the same problem?\n>\n> Also, whilst we're on the subject is bitcoind only binding to the loopback interface?\nThe PHP library I'm using definitely supports HTTP Basic authentication. You just have to craft the URL right:\nhttp://username:password@localhost:8332/","Quote from: lachesis on July 25, 2010, 08:30:16 PM"],["t","Of course, you can specify the username and password as part of the URL Cheesy. Think a BC or two is deserved for that one Smiley - sent."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5748#msg5748"},{"f":"lachesis","d":1280090391,"b":[["q","Think a BC or two is deserved for that one Smiley - sent.","Quote from: gazoakley on July 25, 2010, 08:34:53 PM"],["t","Thank you sir. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5751#msg5751"},{"f":"The Madhatter","d":1280090432,"b":[["t","If you are using PHP+JSON+CURL you can easily specify the user/pass with a curl_setopt() line. The parameter is \"CURLOPT_USERPWD\".\n\nThanks for the basic auth patch. Before the patch I was using uid/gid firewall lines to limit the bitcoind to only my special users/IPs that ran various scraps of code on crontabs. I'll likely still leave those protections in and just add in the basic http auth as well. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5752#msg5752"},{"f":"BitLex","d":1280090738,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5753#msg5753"},{"f":"The Madhatter","d":1280091278,"b":[["t","Hmm.. shouldn't it be using digest auth instead of basic auth?\n\nI usually wrap everything into SSL or IPSec anyway, but digest auth might keep noobs from getting pwned so easily. Tongue"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5755#msg5755"},{"f":"lachesis","d":1280091605,"b":[["t","Digest auth is a fair bit harder to implement on both the client and the server side. It _should_ be using SSL and client certificates, but that's just a major PITA. Either that, or unix sockets."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5756#msg5756"},{"f":"The Madhatter","d":1280091943,"b":[["t","Hmm... I implemented digest auth into a custom webserver I wrote a decade ago. From what I remember, it was fairly easy. However, client support back then was rather shoddy. It has improved a lot since then. Smiley\n\nPerhaps we could document a simple stunnel + bitcoin configuration on the wiki then? Under a section called \"Securely using bitcoind from remote\"?\n\nJust offering my 2c as usual. Tongue"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5759#msg5759"},{"f":"satoshi","d":1280093669,"b":[["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\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.\n\nThis can be solved by removing the newlines (and maybe '\r's) from result at the end of the Base64Encode function:\n\nresult.erase(std::remove(result.begin(), result.end(), ''), result.end());\nresult.erase(std::remove(result.begin(), result.end(), '\r'), result.end());","Quote from: lachesis on July 25, 2010, 07:52:35 PM"],["t","+1 to you for having such a long password that you found this bug.\n\nUploaded to SVN as rev 110."]],"u":"https://bitcointalk.org/index.php?topic=461.msg5767#msg5767","s":1,"n":273,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/273/"},{"f":"Gavin Andresen","d":1280093899,"b":[["q","I found what appears to be a bug: with a long enough username and password combination, the base64 encoder in bitcoind ... inserts a newline every 64 characters","Quote from: lachesis on July 25, 2010, 07:52:35 PM"],["t","Great catch!  Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function:"],["c","diff --git a/rpc.cpp b/rpc.cpp\nindex 72bdc50..703b757 100644\n--- a/rpc.cpp\n+++ b/rpc.cpp\n@@ -765,13 +765,14 @@ string EncodeBase64(string s)\n     BUF_MEM *bptr;\n \n     b64 = BIO_new(BIO_f_base64());\n+    BIO_set_flags(b64, BIO_FLAGS_BASE64_NO_NL);\n     bmem = BIO_new(BIO_s_mem());\n     b64 = BIO_push(b64, bmem);\n     BIO_write(b64, s.c_str(), s.size());\n     BIO_flush(b64);\n     BIO_get_mem_ptr(b64, &bptr);\n \n-    string result(bptr->data, bptr->length-1);\n+    string result(bptr->data, bptr->length);\n     BIO_free_all(b64);\n \n     return result;"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5768#msg5768"},{"f":"satoshi","d":1280094256,"b":[["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.","Quote from: BitLex on July 25, 2010, 08:45:38 PM"],["t","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.\n\nI hope it's not going to put up this much of a fight for all PHP users.\n\nLooks like we've got the Fortran scenario already. "]],"u":"https://bitcointalk.org/index.php?topic=461.msg5769#msg5769","s":1,"n":274,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/274/"},{"f":"satoshi","d":1280094691,"b":[["q","Great catch!  Simpler fix is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 function","Quote from: gavinandresen on July 25, 2010, 09:38:19 PM"],["t","SVN rev 111"]],"u":"https://bitcointalk.org/index.php?topic=461.msg5771#msg5771","s":1,"n":275,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/275/"}]},{"id":"p124","k":"p","s":"bitcointalk","t":"Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)","u":"https://bitcointalk.org/index.php?topic=479","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/124/","m":[{"f":"satoshi","d":1279555298,"b":[["t","Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser.  It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.\n\nWe're working on a release soon that puts a password on the JSON-RPC interface, but until then, avoid using the -server switch, and don't web browse on the same machine where bitcoind is running.\n\nUpdate:\nThe JSON-RPC HTTP authentication feature in 0.3.3 solves this problem."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4263#msg4263","s":1,"n":247,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/247/"},{"f":"Quantumplation","d":1279555421,"b":[["t","satoshi: How many other developers do you have working with you?\n\nMartin (another forum member and I) were talking about writing a .Net compatible library for integrating bitcoins into other programs."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4265#msg4265","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"franzl","d":1279624072,"b":[["q","Martin (another forum member and I) were talking about writing a .Net compatible library for integrating bitcoins into other programs.","Quote from: Quantumplation on July 19, 2010, 04:03:41 PM"],["t","I think this is a very good idea! I also think it's important to have a PHP library since this is an important programming language for e-commerce sites. It would help a great deal in acceptance of bitcoin as a currency."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4440#msg4440","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"Quantumplation","d":1279645186,"b":[["t","Franzl: >_> I abhor PHP, so I can't help you there, but some day (Completely overwhelmed with projects right now, but some day...) we might write the .net library."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4487#msg4487","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"Axcella","d":1279651965,"b":[["t","this is the only computer i have at present i am working on getting a standalone for the bit coin program until then how do i retain the kash if the connection is lost?"]],"u":"https://bitcointalk.org/index.php?topic=479.msg4511#msg4511","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"fresno","d":1279676554,"b":[["q","Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser.  It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.","Quote"],["t","This sounds like something I would not like to have happen, but what does it mean? Let's face it, we're ALL generating Bitcoins on everything we can get hold of. What is the potential damage, in language my Mom might understand?"]],"u":"https://bitcointalk.org/index.php?topic=479.msg4602#msg4602","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"sirius","d":1279691611,"b":[["q","> Quote\n> Don't use the -server or -daemon switch or run bitcoind on a machine where you use a web browser.  It opens port 8332 on 127.0.0.1, the local loopback address, and you wouldn't think that web browsers could cross-site access it, but it is possible.\n\nThis sounds like something I would not like to have happen, but what does it mean? Let's face it, we're ALL generating Bitcoins on everything we can get hold of. What is the potential damage, in language my Mom might understand?","Quote from: fresno on July 21, 2010, 01:42:34 AM"],["t","Malicious websites could have a javascript that steals all your coins."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4647#msg4647","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"Gavin Andresen","d":1279724461,"b":[["t","You can still generate bitcoins, just don't run bitcoind or bitcoin -server or bitcoin -daemon on machine that you use to browse the Web.\n\nAs sirius says, if you do you could browse to a website that empties your Bitcoin wallet without your knowledge or permission."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4740#msg4740","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"fresno","d":1279726069,"b":[["t","I'm full of dumb questions today: Are there any other conceivable problems? And would the daemon be protected of it were on a VM and/or chrooted? Thanks."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4744#msg4744","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"Gavin Andresen","d":1279728632,"b":[["t","chroot: won't protect you.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=479.msg4759#msg4759","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"},{"f":"satoshi","d":1279938549,"b":[["t","The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem."]],"u":"https://bitcointalk.org/index.php?topic=479.msg5432#msg5432","s":1,"n":263,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/263/","sj":"Re: Warning: don't use -server or bitcoind on a machine where you web browse"}]},{"id":"p125","k":"p","s":"bitcointalk","t":"Bitcoin x64 for Windows","u":"https://bitcointalk.org/index.php?topic=501","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/125/","m":[{"f":"Olipro","d":1279659722,"b":[["t","So, after a lot of experimentation, pulling out of hair, cursing of the developer, I finally managed to get a build of Bitcoin compiled under MSVC.\n\nall optimizations are on including SSE2, LTCG and favouring of Intel64 (well hey, that's my processor)\n\nPerformance difference? The two builds I made (namely 32 and 64 bit) are practically equal in terms of performance - however, their performance is not equal to the stock build currently available.\n\nOn my quad-core with the stock Windows binary available from bitcoin.org I get about 1700k hashes a second. With the builds I produced under MSVC I get 2500K a second. Anyone interested?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4518#msg4518"},{"f":"Bitcoiner","d":1279659876,"b":[["t","I am... would it be even faster on SSE3?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4519#msg4519"},{"f":"ender_x","d":1279659929,"b":[["t","sure, I'd like to see if it removes my 20% difference from the linux bin's. "]],"u":"https://bitcointalk.org/index.php?topic=501.msg4520#msg4520"},{"f":"knightmb","d":1279661402,"b":[["q","So, after a lot of experimentation, pulling out of hair, cursing of the developer, I finally managed to get a build of Bitcoin compiled under MSVC.\n\nall optimizations are on including SSE2, LTCG and favouring of Intel64 (well hey, that's my processor)\n\nPerformance difference? The two builds I made (namely 32 and 64 bit) are practically equal in terms of performance - however, their performance is not equal to the stock build currently available.\n\nOn my quad-core with the stock Windows binary available from bitcoin.org I get about 1700k hashes a second. With the builds I produced under MSVC I get 2500K a second. Anyone interested?","Quote from: Olipro on July 20, 2010, 09:02:02 PM"],["t","I've got a spare server using a 8-core 64-bit Intel - 64 bit Windows 2003 server. I'd be curious if there is a difference from the stock, the machine currently does about 5000khash/s, I'd be curious if the 64bit native build would be better."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4530#msg4530"},{"f":"Olipro","d":1279661741,"b":[["q","I am... would it be even faster on SSE3?","Quote from: Bitcoiner on July 20, 2010, 09:04:36 PM"],["t","potentially yes, I compiled it with the Microsoft compiler, I'm in the process of getting the Intel compiler so that could well offer a significant performance boost given that it supports far more instruction sets than MS's does.\n\nAnyhow, I've uploaded the 2 binaries and the required DLLs to make them work and you can get them from right here <http://www.4shared.com/file/HvPZTsuM/BitCoin.html>. After a bit of testing I found that the x64 binary does outperform the 32 bit by 100-200k or so but it does depend a lot on what other crap you have running on your system.\n\nAnd if anyone feels generous... 18em7jEuKe1W74ChAZMFShUuqmwudWmpgu"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4533#msg4533"},{"f":"SmokeTooMuch","d":1279662584,"b":[["q","Anyone interested?","Quote from: Olipro on July 20, 2010, 09:02:02 PM"],["t","Yep."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4538#msg4538"},{"f":"Olipro","d":1279662788,"b":[["t","see my previous post.\n\nFeedback on performance is appreciated, bitcoins even moreso."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4539#msg4539"},{"f":"knightmb","d":1279669961,"b":[["q","see my previous post.\n\nFeedback on performance is appreciated, bitcoins even moreso.","Quote from: Olipro on July 20, 2010, 09:53:08 PM"],["t","I keep getting a \"MSVCR100.dll\" not found error when trying to start it. I copied the file over from another system into the system32 folder, but the program still can't find it for some reason. Do we need the full Microsoft dev environment installed to test it?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4571#msg4571"},{"f":"jimbobway","d":1279670065,"b":[["t","How do we know this is not a scam?  Give us your IP to donate with or something so we can make sure you are reputable.  I am scared to install it, it might steal my bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4572#msg4572"},{"f":"knightmb","d":1279670227,"b":[["q","How do we know this is not a scam?  Give us your IP to donate with or something so we can make sure you are reputable.  I am scared to install it, it might steal my bitcoins.","Quote from: jimbobway on July 20, 2010, 11:54:25 PM"],["t","I'll guinea pig, I'm running it on a test system that has no balance yet, well trying to run, it won't start."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4573#msg4573"},{"f":"martin","d":1279670276,"b":[["t","It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins Wink\n\nThis version has between 200-700 more khash per second on my machine."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4574#msg4574"},{"f":"knightmb","d":1279670480,"b":[["q","It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins Wink\n\nThis version has between 200-700 more khash per second on my machine.","Quote from: martin on July 20, 2010, 11:57:56 PM"],["t","No missing DLL errors when you try to start it?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4575#msg4575"},{"f":"Olipro","d":1279673187,"b":[["q","It's not a scam, I decided to install it and see. Unless it's a very complex scam which waits for a while before stealing my coins Wink\n\nThis version has between 200-700 more khash per second on my machine.","Quote from: martin on July 20, 2010, 11:57:56 PM"],["t","correct, it's not a scam, the code is completely vanilla, I didn't obsfusicate it so you can feel free to examine it in the disassembler of your choice.\n\nso, with my build you've gone from 5000k to 5700k?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4587#msg4587"},{"f":"Ground Loop","d":1279673373,"b":[["t","Get visual C 2010 redist from Microsoft -- pointers here:\n\nhttp://www.mydigitallife.info/2010/04/17/visual-c-2010-runtime-redistributable-package-x86-x64-ia64-free-download/\n\nThe new code is full of win.. hash rate (4 core) went from 1350 to 1880 khash/s.  Sweet!"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4588#msg4588"},{"f":"knightmb","d":1279673403,"b":[["t","For those that get the DLL error and don't want to install the full dev environment, you need to download the Visual C++ 2010 Redistributable x64 located\nhttp://www.microsoft.com/downloads/details.aspx?FamilyID=BD512D9E-43C8-4655-81BF-9350143D5867&displaylang=en"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4589#msg4589"},{"f":"Olipro","d":1279673551,"b":[["t","I recommend getting the redist from the official source:\n\nx86 here: http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84\n\nx64 here: http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867\n\nIf there's demand for it, I can compile an Itanic Itanium build... for a reasonable consideration Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4590#msg4590"},{"f":"Olipro","d":1279674072,"b":[["q","How do we know this is not a scam?  Give us your IP to donate with or something so we can make sure you are reputable.  I am scared to install it, it might steal my bitcoins.","Quote from: jimbobway on July 20, 2010, 11:54:25 PM"],["t","If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be Smiley\n\nI can assure you the code is 100% clean."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4593#msg4593"},{"f":"Olipro","d":1279674220,"b":[["q","Get visual C 2010 redist from Microsoft -- pointers here:\n\nhttp://www.mydigitallife.info/2010/04/17/visual-c-2010-runtime-redistributable-package-x86-x64-ia64-free-download/\n\nThe new code is full of win.. hash rate (4 core) went from 1350 to 1880 khash/s.  Sweet!","Quote from: Ground Loop on July 21, 2010, 12:49:33 AM"],["t","that's very interesting, what processor/frequency are you on? x86 or x64?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4595#msg4595"},{"f":"Ground Loop","d":1279674847,"b":[["t","Win7 64-bit\nIntel Xeon 5130 (2.0GHz dual-proc)\n\nI'll send you the first 50.0 it finds. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4597#msg4597"},{"f":"knightmb","d":1279675248,"b":[["t","Nice job, this is just my initial testing, but the 64 bit compile speeds up hashing by over 28% so far over the 32 bit counterpart.\n\nSo for example, my 8-core system does (600 khash/s per core =  4800 khash/s) for normally, but now averages 5700 khash/s\n\nI'll certainly be sending some bitcoins your way  Wink"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4599#msg4599"},{"f":"knightmb","d":1279680425,"b":[["t","Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4615#msg4615"},{"f":"Olipro","d":1279680760,"b":[["q","Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.","Quote from: knightmb on July 21, 2010, 02:47:05 AM"],["t","]\n\ndo you have the Visual C++ 2010 runtime installed? if not, that's why."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4618#msg4618"},{"f":"Vasiliev","d":1279680909,"b":[["q","I recommend getting the redist from the official source:\n\nx64 here: http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6","Quote from: Olipro on July 21, 2010, 12:52:31 AM"],["t","Your link is wrong; it's for the 2008 redist, not the 2010.\n\n2010 x64: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4619#msg4619"},{"f":"knightmb","d":1279681005,"b":[["q","> Quote from: Olipro on July 21, 2010, 12:52:31 AM\n> I recommend getting the redist from the official source:\n>\n> x64 here: http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6\nYour link is wrong; it's for the 2008 redist, not the 2010.\n\n2010 x64: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867","Quote from: Vasiliev on July 21, 2010, 02:55:09 AM"],["t","Does that apply for the x86 one also, since that's what I was using to test the 32bit build he had?\n\n[edit] I just checked, it was good for the 32bit  Roll Eyes"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4620#msg4620"},{"f":"Olipro","d":1279681075,"b":[["t","no, that's definitely correct.\n\nthere is another possibility however... what processor is in your XP machine? if it doesn't support SSE2, it'll crash."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4621#msg4621"},{"f":"knightmb","d":1279681149,"b":[["q","> Quote from: knightmb on July 21, 2010, 02:47:05 AM\n> Testing with the 32bit client, your build 32bit client build crashes sad to say on a stock system (Windows XP) anyway. Going to later test on Vista, 7, etc and report back.\n]\n\ndo you have the Visual C++ 2010 runtime installed? if not, that's why.","Quote from: Olipro on July 21, 2010, 02:52:40 AM"],["t","Yes, straight from the download link on the previous page for x86.\n\nI looked through the error log a little, didn't spot anything that stood out."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4622#msg4622"},{"f":"knightmb","d":1279681185,"b":[["q","no, that's definitely correct.\n\nthere is another possibility however... what processor is in your XP machine? if it doesn't support SSE2, it'll crash.","Quote from: Olipro on July 21, 2010, 02:57:55 AM"],["t","Tested it a Celeron machine (1.1 GHz)\n\nGood point, I'll see what the others do."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4623#msg4623"},{"f":"jimbobway","d":1279685674,"b":[["q","> Quote from: jimbobway on July 20, 2010, 11:54:25 PM\n> How do we know this is not a scam?  Give us your IP to donate with or something so we can make sure you are reputable.  I am scared to install it, it might steal my bitcoins.\n\nIf I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be Smiley\n\nI can assure you the code is 100% clean.","Quote from: Olipro on July 21, 2010, 01:01:12 AM"],["t","Sorry to be so skeptical, but there was a victim on this site when someone claimed to have compiled a CUDA client that used the graphics processor to hash.  One guy fell for it and lost some bitcoins.\n\nBut yes, if I get a chance I will look at the dlls I suppose before running it.\n\nOr, maybe you can release the project files and we can compile it ourselves?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4637#msg4637"},{"f":"knightmb","d":1279687956,"b":[["q","> Quote from: Olipro on July 21, 2010, 01:01:12 AM\n> > Quote from: jimbobway on July 20, 2010, 11:54:25 PM\n> > How do we know this is not a scam?  Give us your IP to donate with or something so we can make sure you are reputable.  I am scared to install it, it might steal my bitcoins.\n>\n> If I were scamming, what incentive would I have to ask for donations knowing that those who used it would have their account emptied anyway. Frankly though, my username is far more of a verification of my authenticity than my IP would ever be Smiley\n>\n> I can assure you the code is 100% clean.\n\nSorry to be so skeptical, but there was a victim on this site when someone claimed to have compiled a CUDA client that used the graphics processor to hash.  One guy fell for it and lost some bitcoins.\n\nBut yes, if I get a chance I will look at the dlls I suppose before running it.\n\nOr, maybe you can release the project files and we can compile it ourselves?","Quote from: jimbobway on July 21, 2010, 04:14:34 AM"],["t","Point well taken, but the CUDA never materialized, this one actually does what he said it does. So if it is a scam, it sure is taking a lot of effort.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4640#msg4640"},{"f":"knightmb","d":1279688640,"b":[["t","I think he should really present to this devs to get credit for it and some BC because I'm going to send some to him for raising my khash/s up and beyond the already insane levels that I have.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4642#msg4642"},{"f":"knightmb","d":1279689852,"b":[["t","For 32bit clients, this makes a huge speed increase (if your PC supports it)\n\nI was using a little netbook to test with, it could manage about 185 khash/s but his compile does 238 khash/s so over a 28% increase (what I saw in the 64 bit clients), so another thumbs up for this build. (Exe size is smaller too  Wink )"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4644#msg4644"},{"f":"Ground Loop","d":1279734030,"b":[["t","Here's a weird question.. has anyone actually generated a block with this faster version?\n\nI have a few machines that used to regularly generate, and since switching to this version -- zip.  I know these things are subject to random variation, and it could be a dry spell, and the difficulty is going up, but... could it be a bug?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4779#msg4779"},{"f":"ichi","d":1279736192,"b":[["t","Don't worry, getting BTC now requires supercomputers, clusters and/or botnets  Wink\n\nCounterexamples, with Khash/s noted, welcome  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4788#msg4788"},{"f":"Quantumplation","d":1279736255,"b":[["t","Ichi: I got 2 blocks in a row back when I was running 1200khash.  I'm up to 2500 now, as per the update, so we'll see if I get some more blocks. =)"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4789#msg4789"},{"f":"dkaparis","d":1279738230,"b":[["t","I did the same thing with VC++ 2008: http://bitcointalk.org/index.php?topic=453.0\nAs I wrote there, the results were slower than stock.\n\nHaven't yet tried x64 or 2010 because rebuilding the dependencies/setting up is a hassle. Your builds give improvement over stock on my system though.\n\nCurious.\n\nIt should be the sha.cpp module that matters. Did you modify the source in any way, or specify any special defines?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4793#msg4793"},{"f":"Bitquux","d":1279739235,"b":[["t","Hey, I just made this improvement that will vastly improve your khash/s!\n\nIn main.cpp, ~2751, change:\n   string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/1000.0);\nto:\n   string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/300.0);\n\nThen on ~2758, change:\n  printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/1000.0);\nto:\n  printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/300.0);\n\n(DISCLAIMER: THIS IS A JOKE.)"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4798#msg4798"},{"f":"Bitcoiner","d":1279739370,"b":[["q","Don't worry, getting BTC now requires supercomputers, clusters and/or botnets  Wink\n\nCounterexamples, with Khash/s noted, welcome  Smiley","Quote from: ichi on July 21, 2010, 06:16:32 PM"],["t","Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night Wink\n\nMy 300 khash laptop got lucky and produced one the first day I used Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4800#msg4800"},{"f":"ichi","d":1279739728,"b":[["q","Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night Wink\n\nMy 300 khash laptop got lucky and produced one the first day I used Bitcoin.","Quote from: Bitcoiner on July 21, 2010, 07:09:30 PM"],["t","That's good news.  Thanks  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4802#msg4802"},{"f":"Bitquux","d":1279740295,"b":[["q","Regular old BTC client running on ubuntu (2150-2500 khash/sec) managed to produce a block last night Wink\n\nMy 300 khash laptop got lucky and produced one the first day I used Bitcoin.","Quote from: Bitcoiner on July 21, 2010, 07:09:30 PM"],["t","I grabbed one on a 480-500 khash/sec machine last night too, so it's still doable. Also, that same machine is in the 530-550 range with this new build (32 bit). Sending some bit-love to Olipro right now. The effort's gotta be worth something. Nice work."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4806#msg4806"},{"f":"Ground Loop","d":1279743595,"b":[["t","So --- Bitquux, that was Olipro's binary that found the coin?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4824#msg4824"},{"f":"Bitquux","d":1279744320,"b":[["q","So --- Bitquux, that was Olipro's binary that found the coin?","Quote from: Ground Loop on July 21, 2010, 08:19:55 PM"],["t","Negative, that was before the switch. And at this rate, it will be a long time before I can tell if it will. Even if it's a dirty bin it's clever enough to earn a donation."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4828#msg4828"},{"f":"Olipro","d":1279745066,"b":[["q","> Quote from: Ground Loop on July 21, 2010, 08:19:55 PM\n> So --- Bitquux, that was Olipro's binary that found the coin?\n\nNegative, that was before the switch. And at this rate, it will be a long time before I can tell if it will. Even if it's a dirty bin it's clever enough to earn a donation.","Quote from: Bitquux on July 21, 2010, 08:32:00 PM"],["t","It shouldn't be dirty, the SHA256 is untouched and I don't think the compiler has introduced any errors."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4833#msg4833"},{"f":"Bitquux","d":1279745539,"b":[["q","It shouldn't be dirty, the SHA256 is untouched and I don't think the compiler has introduced any errors.","Quote from: Olipro on July 21, 2010, 08:44:26 PM"],["t","Yes, let me clarify. This is not a dirty bin. There is no reason so far to believe it's anything other than what Olipro says it is. The performance of my previously mentioned machine has even gone up since I first posted those numbers."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4837#msg4837"},{"f":"knightmb","d":1279745564,"b":[["q","Here's a weird question.. has anyone actually generated a block with this faster version?\n\nI have a few machines that used to regularly generate, and since switching to this version -- zip.  I know these things are subject to random variation, and it could be a dry spell, and the difficulty is going up, but... could it be a bug?","Quote from: Ground Loop on July 21, 2010, 05:40:30 PM"],["t","Yes, about 10 so far. The other \"regular\" clients acknowledge test Coin transfer between the two, so far it appears good. I also have a packet sniffer running on my test machine and it's basically doing what the other clients do, nothing out of the ordinary so far."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4838#msg4838"},{"f":"Olipro","d":1279746856,"b":[["q","This worked perfectly! On linux and windows if you compile yourself. I went from 380khash/s on one core to over 1200khash/s!","Quote from: davidonpda on July 21, 2010, 08:59:16 PM"],["t","yeah, because dividing a number by 300 instead of 1000 makes it look a lot bigger, doesn't *actually* improve performance."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4847#msg4847"},{"f":"Olipro","d":1279773230,"b":[["t","OK, I've made a new build of Bitcoin, this one is compiled using the Intel compiler which is considerably more advanced than the standard MS compiler.\n\nPlease note this build is 64-bit only since I see no reason to compile a build for 32-bit when most 32-bit processors lack the newer SSE instructions anyway.\n\nPerformance? my MSVC build averages about 2400K for me, this averages 2900K so you're looking at an improvement of about 125k per core or thereabouts although this does come at the cost of a larger EXE, improved performance is worth it in my opinion Smiley\n\nMy next goal is to see if this PolarSSL SHA256 algo really is faster. for now however, download Bitcoin x64 ICC optimised build here <http://www.4shared.com/file/mOP_WMgN/Bitcoin_IntelBuild.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4955#msg4955"},{"f":"Ground Loop","d":1279774815,"b":[["t","Runs about the same speed as the VC++ version here (Xeon, Win7 64-bit)."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4960#msg4960"},{"f":"knightmb","d":1279776464,"b":[["q","OK, I've made a new build of Bitcoin, this one is compiled using the Intel compiler which is considerably more advanced than the standard MS compiler.\n\nPlease note this build is 64-bit only since I see no reason to compile a build for 32-bit when most 32-bit processors lack the newer SSE instructions anyway.\n\nPerformance? my MSVC build averages about 2400K for me, this averages 2900K so you're looking at an improvement of about 125k per core or thereabouts although this does come at the cost of a larger EXE, improved performance is worth it in my opinion Smiley\n\nMy next goal is to see if this PolarSSL SHA256 algo really is faster. for now however, download Bitcoin x64 ICC optimised build here <http://www.4shared.com/file/mOP_WMgN/Bitcoin_IntelBuild.html>","Quote from: Olipro on July 22, 2010, 04:33:50 AM"],["t","Awesome, gives a 41% speed boost over the stock binary.\n\nMy experience so far.\n\nStock = Stock\nLast x64 Build = 28% speed increase over stock\nThis x64 Build = 41% speed increase over stock\n\nNice stuff!"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4964#msg4964"},{"f":"Olipro","d":1279782384,"b":[["q","Runs about the same speed as the VC++ version here (Xeon, Win7 64-bit).","Quote from: Ground Loop on July 22, 2010, 05:00:15 AM"],["t","which Xeon, there's quite a few.\n\nI don't think I need to point this out but here goes anyway: the significance of the performance benefit from using any of my builds will depend entirely on how many cores your computer has.\n\nAlso, in case anyone missed it: the PolarSSL algo is *not* faster.\n\nnext step... CUDA."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4972#msg4972"},{"f":"ichi","d":1279783512,"b":[["t","What would I expect for two Xeon 5570?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4976#msg4976"},{"f":"Olipro","d":1279784614,"b":[["q","What would I expect for two Xeon 5570?","Quote from: ichi on July 22, 2010, 07:25:12 AM"],["t","a 4 core processor with hyperthreading... and two of them? a pretty significant performance increase."]],"u":"https://bitcointalk.org/index.php?topic=501.msg4979#msg4979"},{"f":"Olipro","d":1279792147,"b":[["t","OK, I've made a new EXE, this one seems to get me an extra 100-200k (or about 25-50k per core).\n\nDifference? I modified the ByteSwap function to operate on 64-bit integers; it does this by using the bswap intrinsic on a 64 bit register followed by rotate right through 32 bits to put the result in the correct order. it also initializes the SHA256 vectors using unsigned 64 bit values (however, the actual hashing still uses 32-bit so I doubt this is making much of a difference) and yes, I did convert the 32 bit numbers to 64 bit correctly (i.e. 0x12345678UL 0xabcdef0UL -> 0xabcdef012345678ULL) if that appears wrong to you, think about how little endian machines store 32 bit integers in memory.\n\nanyway, grab it here <http://www.4shared.com/file/iHQA_p96/Bitcoin_Intel_x64_tweaked.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg4995#msg4995"},{"f":"Quantumplation","d":1279804570,"b":[["t","Wow, that tweaked one... I'm getting stunning rates.  I have a quad core Intel laptop.\n\nI have two different number sets, 1 while operating as usual, with other programs running, and one while everything but bitcoin (including explorer.exe) is shut down.\n\nStock:         x64 v1          x64 v2           x64 v2 Tweaked       \n\nStandard Usage:500-12001000-1800750-15002200-2700\n\nOptimized Usage:1500-18002000-25001500-20002700-3400\n\nO_O"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5014#msg5014"},{"f":"m0mchil","d":1279807533,"b":[["t","May I kindly ask you, mighty Olipro, to patch bitcoin 0.3.1 or may be 0.3.2? There were some issues in 0.3"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5027#msg5027"},{"f":"knightmb","d":1279810271,"b":[["q","OK, I've made a new EXE, this one seems to get me an extra 100-200k (or about 25-50k per core).\n\nDifference? I modified the ByteSwap function to operate on 64-bit integers; it does this by using the bswap intrinsic on a 64 bit register followed by rotate right through 32 bits to put the result in the correct order. it also initializes the SHA256 vectors using unsigned 64 bit values (however, the actual hashing still uses 32-bit so I doubt this is making much of a difference) and yes, I did convert the 32 bit numbers to 64 bit correctly (i.e. 0x12345678UL 0xabcdef0UL -> 0xabcdef012345678ULL) if that appears wrong to you, think about how little endian machines store 32 bit integers in memory.\n\nanyway, grab it here <http://www.4shared.com/file/iHQA_p96/Bitcoin_Intel_x64_tweaked.html>","Quote from: Olipro on July 22, 2010, 09:49:07 AM"],["t","I'll give this one a run, the last build would crash randomly after a few hours  Wink"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5037#msg5037"},{"f":"Olipro","d":1279811558,"b":[["q","May I kindly ask you, mighty Olipro, to patch bitcoin 0.3.1 or may be 0.3.2? There were some issues in 0.3","Quote from: m0mchil on July 22, 2010, 02:05:33 PM"],["t","my builds are from the latest SVN source code, of course, had you checked the about page, you would notice it clearly states itself as 0.3.2"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5045#msg5045"},{"f":"m0mchil","d":1279812227,"b":[["t","hmmmmm, that's strange... because I am experiencing the problem already fixed in http://bitcoin.svn.sourceforge.net/viewvc/bitcoin?view=revision&revision=102"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5051#msg5051"},{"f":"Olipro","d":1279817971,"b":[["q","hmmmmm, that's strange... because I am experiencing the problem already fixed in http://bitcoin.svn.sourceforge.net/viewvc/bitcoin?view=revision&revision=102","Quote from: m0mchil on July 22, 2010, 03:23:47 PM"],["t","then either it got re-broken or he also modified something in wxWidgets itself which I don't have.\n\non an unrelated note: I have CUDA working for SHA256 hashing... currently the host has to iterate the nonce so performance is terrible, working on moving the whole kit and kaboodle into the card and then performance should be pretty damn sexy."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5075#msg5075"},{"f":"sgtstein","d":1279819476,"b":[["t","DEFINITELY in to test CUDA!"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5083#msg5083"},{"f":"Quantumplation","d":1279819599,"b":[["t","Oli: One alternative is to start the CUDA part hashing with a nonce of MAXINT and subtract one, and the host client start at one and go upwards.  Then, either one could find a hash and you're not repeating work."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5085#msg5085"},{"f":"ichi","d":1279823417,"b":[["q","Wow, that tweaked one... I'm getting stunning rates.  I have a quad core Intel laptop.\n\nI have ... one while everything but bitcoin (including explorer.exe) is shut down.\n\nStock:         x64 v1          x64 v2           x64 v2 Tweaked       \n\n<snip>\n\nOptimized Usage:1500-18002000-25001500-20002700-3400","Quote from: Quantumplation on July 22, 2010, 01:16:10 PM"],["t","On a Quad-Core AMD Opteron 2376 server running Ubuntu 10.04 Desktop x64 (wubi) and Bitcoin 0.3.0 x64, I get ~2,200 khash/s.  With Bitcoin 0.3.0 x86, I get ~2,000 khash/s.  What would I expect running Windows Server 2008 x64 and Olipro's x64 v2 Tweaked?\n\nIs it faster than the stock Linux x64 build?  Could the Linux build be similarly tweaked?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5097#msg5097"},{"f":"Quantumplation","d":1279823626,"b":[["t","Ichi: Probably pretty fast, I saw a huge increase in performance to the tweaked version.  No tellin until you try it though."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5100#msg5100"},{"f":"BitLex","d":1279828849,"b":[["q","I'll give this one a run, the last build would crash randomly after a few hours  Wink","Quote from: knightmb on July 22, 2010, 02:51:11 PM"],["t","same here,\nMSVC build didnt work at all (missing DLL even after vcredist_x64 install),\nIntel build seems to work fine for 1-2hours and then crashes.\n\nI get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.\n\nUpdate: this one seems to crash even faster, 30minutes first run, almost 1hour second run"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5124#msg5124"},{"f":"Olipro","d":1279837673,"b":[["q","> Quote from: knightmb on July 22, 2010, 02:51:11 PM\n> I'll give this one a run, the last build would crash randomly after a few hours  Wink\n\nsame here,\nMSVC build didnt work at all (missing DLL even after vcredist_x64 install),\nIntel build seems to work fine for 1-2hours and then crashes.\n\nI get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.\n\nUpdate: this one seems to crash even faster, 30minutes first run, almost 1hour second run","Quote from: BitLex on July 22, 2010, 08:00:49 PM"],["t","the missing DLL is in my first release (libeay32.dll)"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5153#msg5153"},{"f":"kosovito","d":1279837872,"b":[["t","Vista x64 here\n\nFrom regular version ~1700khash/s to this version ~2300khash/s (last versios posted here)\n\nReally nice, but i think need to be more stable"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5154#msg5154"},{"f":"Olipro","d":1279838034,"b":[["q","Vista x64 here\n\nFrom regular version ~1700khash/s to this version ~2300khash/s (last versios posted here)\n\nReally nice, but i think need to be more stable","Quote from: kosovito on July 22, 2010, 10:31:12 PM"],["t","given that it's based on stock code and I doubt there's an issue with the compiler, it's more likely there's a bug in the SVN source, I'll make a build from the last stable production version just as soon as I've finished this CUDA code off."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5155#msg5155"},{"f":"BitLex","d":1279843369,"b":[["q","> Quote from: BitLex on July 22, 2010, 08:00:49 PM\n> > Quote from: knightmb on July 22, 2010, 02:51:11 PM\n> > I'll give this one a run, the last build would crash randomly after a few hours  Wink\n>\n> same here,\n> MSVC build didnt work at all (missing DLL even after vcredist_x64 install),\n> Intel build seems to work fine for 1-2hours and then crashes.\n>\n> I get around 1600 with the regular client, Intel build ~2150, latest Intel tweaked ~2220.\n>\n> Update: this one seems to crash even faster, 30minutes first run, almost 1hour second run\n\nthe missing DLL is in my first release (libeay32.dll)","Quote from: Olipro on July 22, 2010, 10:27:53 PM"],["t","thats not the one causing MSVC build not to work, that'd be MSVCR100.dll.\nanyway, the Intel build does work, although it crashes.  Undecided\n\nkeep coding, i'm looking forward to test a cuda-version on my gtx260.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5161#msg5161"},{"f":"knightmb","d":1279845698,"b":[["t","My experience is similar, the first release was rock solid like the original client, the other releases, while still faster, randomly crash after minutes/hours/days  so it's kind of random.\n\nSo it's a trade off between stability and speed. The faster it gets, the less stable it seems.  Grin\n\nOf course, I have mine on a batch to restart if there is a crash and to count how many times the program crashed during the day for example. So far up to about 2 crashes a day."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5164#msg5164"},{"f":"Bitcoiner","d":1279929688,"b":[["t","There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5408#msg5408"},{"f":"knightmb","d":1279930774,"b":[["q","There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S","Quote from: Bitcoiner on July 24, 2010, 12:01:28 AM"],["t","Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.\n\nMost of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5413#msg5413"},{"f":"Olipro","d":1279936594,"b":[["q","> Quote from: Bitcoiner on July 24, 2010, 12:01:28 AM\n> There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S\nYeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.\n\nMost of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.","Quote from: knightmb on July 24, 2010, 12:19:34 AM"],["t","that's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5425#msg5425"},{"f":"knightmb","d":1279942735,"b":[["q","> Quote from: knightmb on July 24, 2010, 12:19:34 AM\n> > Quote from: Bitcoiner on July 24, 2010, 12:01:28 AM\n> > There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S\n> Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.\n>\n> Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.\n\nthat's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something.","Quote from: Olipro on July 24, 2010, 01:56:34 AM"],["t","Yes, sorry, I left that part out, the Linux servers (same hardware) always generate higher khash/s than the windows machines, at least mine do. Your mileage may vary."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5444#msg5444"},{"f":"Bitcoiner","d":1279985805,"b":[["q","> Quote from: Olipro on July 24, 2010, 01:56:34 AM\n> > Quote from: knightmb on July 24, 2010, 12:19:34 AM\n> > > Quote from: Bitcoiner on July 24, 2010, 12:01:28 AM\n> > > There is a speedup for me, but it is not faster than the ubuntu 64-bit version. I am surprised; with SSE2 I expected it to fly :S\n> > Yeah, my Linux 64bit systems still have the leg up on my windows servers, even with this optimization that is made that speeds them up by 50%, seems Linux still rules the roost for coin generation speed.\n> >\n> > Most of my coin generation comes from my Linux servers more than my windows servers, it's about a 1 to 4 ratio, for every 4 blocks made by my Linux servers, 1 will be made by one of the windows servers.\n>\n> that's not an indicator of performance mind, block generation is pure luck, it's the hashes per second that mean something.\nYes, sorry, I left that part out, the Linux servers (same hardware) always generate higher khash/s than the windows machines, at least mine do. Your mileage may vary.","Quote from: knightmb on July 24, 2010, 03:38:55 AM"],["t","On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5506#msg5506"},{"f":"ichi","d":1280013253,"b":[["q","On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build.","Quote from: Bitcoiner on July 24, 2010, 03:36:45 PM"],["t","OK.  Could someone please explain the why of that, in terms that a non-programmer can understand?  Why is the stock Windows build slower than the stock Ubuntu build?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5591#msg5591"},{"f":"knightmb","d":1280019284,"b":[["q","> Quote from: Bitcoiner on July 24, 2010, 03:36:45 PM\n> On my desktop, I have a dual boot between Ubuntu and Windows 7. The SSE2 build brings Windows 7 speeds up to around the same as the Ubuntu build.\nOK.  Could someone please explain the why of that, in terms that a non-programmer can understand?  Why is the stock Windows build slower than the stock Ubuntu build?","Quote from: ichi on July 24, 2010, 11:14:13 PM"],["t","Optimizations mainly. When the program is being compiled on Windows, certainly optimizations make the program more efficient.\n\nOn Linux, we have both 32bit and 64bit builds to take advantage of the 64bit arch of the system. On windows, there was only a 32bit build."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5605#msg5605"},{"f":"ichi","d":1280021415,"b":[["t","Thank you.  I'm glad that I'm moving to Ubuntu."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5612#msg5612"},{"f":"Bitcoiner","d":1280038437,"b":[["q","Thank you.  I'm glad that I'm moving to Ubuntu.","Quote from: ichi on July 25, 2010, 01:30:15 AM"],["t","I still prefer windows 7 for many things, but I am liking Ubuntu more and more. If only some things weren't such a pain in the ass to use (Tor: Windows 7? 1 minute install. Ubuntu? WTF...)"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5640#msg5640"},{"f":"ichi","d":1280045105,"b":[["t","I really like Windows Server 2008, which is pretty close to Windows 7.  It'll be a while before I give that up.\n\nOTOH, I'm thinking very seriously re going with Ubuntu for my next primary desktop.  As a test, I've recently installed Ubuntu 10.04 Server x64 + GNOME on an old Core 2 Quad machine.  Everything except boot lives on an encrypted RAID5 array managed by LVM.  Losing Excel 2007 might be a problem, though.\n\nAlthough I don't use Tor, I'm sure that there must be many setup guides for Ubuntu.\n\nThis is way off topic.  Sorry."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5655#msg5655"},{"f":"Quantumplation","d":1280069943,"b":[["t","I absolutely hate Ubuntu, mostly because of the community surrounding it.  I much prefer gentoo, Debian, etc."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5695#msg5695"},{"f":"andy_3_913","d":1280085326,"b":[["t","mind if i ask?\nsatoshi has released a couple of updates recently, mostly about security concerns as far as i can see.\nhow are the 64bit versions keeping up with these developments? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5727#msg5727"},{"f":"Olipro","d":1280100206,"b":[["t","Here is several builds based on the latest SVN code (0.3.3), it contains the following:\n\nVisual Studio Builds in x86 and x64 flavour.\n\nIntel Builds in x64 only, one with stock code and the other with the 64bit byte reversal/state init tweak since it seems to squeeze a few more drops of speed out of it.\n\ngrab it here <http://www.4shared.com/file/SwcGqCm_/Bitcoin033.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5783#msg5783"},{"f":"Olipro","d":1280111448,"b":[["t","OK, I've made a new build now; this version uses the 64bit SHA256 Assembler code from Crypto++ which means the Byteswap function is now only used for re-ordering the resulting hash - and of course it's using 64-bit ASM to create the hash in the first place.\n\nPerformance? I've gone from an average of 2900k hashes on my previous builds up to a pretty stellar 3300k hashes (an improvement of about 100k per core) - I would be very surprised if the Linux builds outperform this.\n\nGrab x64 Asm Optimised Bitcoin here <http://www.4shared.com/file/etsKJC9d/Bitcoin_Asm_Optimized.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5803#msg5803"},{"f":"lachesis","d":1280112590,"b":[["t","Can you release the source for these builds, please? I would very much like to look over the changes that you made."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5806#msg5806"},{"f":"Olipro","d":1280113869,"b":[["t","If you want the code, get Crypto++"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5807#msg5807"},{"f":"Olipro","d":1280114247,"b":[["t","OK, so given that the SHA256 is now 100% assembler code, I figured I might as well just build it entirely using Visual Studio, so I did just that and performance was exactly the same.\n\nSo, for those of you who have found the VS builds to be more stable, click here to get it <http://www.4shared.com/file/ifaR6kVP/Bitcoin_VS_x64_asm.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5809#msg5809"},{"f":"BitLex","d":1280120916,"b":[["t","after tinkering around a bit and reinstalling the vcredist, i even got the VS build to work now.\n\non the regular client i get around 1600khash/sec, your latest VS build currently runs at ~2750khash/sec,\n+70% that's an outstanding performance!"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5813#msg5813"},{"f":"knightmb","d":1280121726,"b":[["q","OK, so given that the SHA256 is now 100% assembler code, I figured I might as well just build it entirely using Visual Studio, so I did just that and performance was exactly the same.\n\nSo, for those of you who have found the VS builds to be more stable, click here to get it <http://www.4shared.com/file/ifaR6kVP/Bitcoin_VS_x64_asm.html>","Quote from: Olipro on July 26, 2010, 03:17:27 AM"],["t","Yeah, runs every bit as fast as the Intel tweaked ones from what I could tell in testing, plus the program is half the size compiled.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5814#msg5814"},{"f":"Olipro","d":1280126357,"b":[["t","OK, now for some absolutely incredible performance.\n\nCredit 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.\n\nPerformance: 4700khash/s on 4 cores, I think that speaks for itself.\n\nI've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.\n\nGrab SHA state caching Bitcoin here <http://www.4shared.com/file/VpSQm9oo/Bitcoin_SHA_state_caching_opt.html>"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5815#msg5815"},{"f":"omegadraconis","d":1280127599,"b":[["t","Wow, all I can say is once again the magic of optimizations and asm come through again. I went from 1300khash/s with the stock 0.3.3 to 3200khash/s with this latest build. My machine is running a dual-core Celeron 3300 @ 3.8ghz."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5816#msg5816"},{"f":"Ground Loop","d":1280129423,"b":[["t","Um.. Wow.  That last one was a bit of a leap.\n\nIntel Core i7-870 (2.93 GHz) running 4950 khash/s here. (4 cores Turbo'd to 3.2 GHz)\n(Intel version)\n\nAnyone seeing a speed difference between VS and Intel?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5818#msg5818"},{"f":"ichi","d":1280130054,"b":[["t","Wow.  Thank you  Smiley\n\nWindows Server 2008 x64 VM in Hyper-V\n4 cores\n8 connections\n\nstock 0.3.0 build => ~2,250 khash/s\nIntel x64 build => ~5,600 khash/s"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5820#msg5820"},{"f":"omegadraconis","d":1280130370,"b":[["t","It was indeed a large jump, not sure how stable it will be in the long run but, we will find out. The stock client ran fine 24 on this machine so I will post back some time tomorrow. I am getting less khash/s with the vc build, around 2600khash/s. The intel build for me is pushing the most khash/s."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5821#msg5821"},{"f":"Olipro","d":1280132267,"b":[["q","It was indeed a large jump, not sure how stable it will be in the long run but, we will find out. The stock client ran fine 24 on this machine so I will post back some time tomorrow. I am getting less khash/s with the vc build, around 2600khash/s. The intel build for me is pushing the most khash/s.","Quote from: omegadraconis on July 26, 2010, 07:46:10 AM"],["t","yes, as I said, the Intel compiler produces far better code than the VS compiler does."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5824#msg5824"},{"f":"FreeMoney","d":1280144544,"b":[["t","I'm a total newb, I tried to use Olipro's file and it failed because I was missing\nMSVCR100.dll I got it, now it says \"The application was unable to start correctly.\" Should I just not mess with this? Is it supposed to be all good to go?\n\nJust say Olipro's new thread. Got it working, so sweet."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5835#msg5835"},{"f":"Olipro","d":1280145705,"b":[["t","if your OS is 64-bit then this has far superior performance, you need this runtime: http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867&displaylang=en"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5838#msg5838"},{"f":"FreeMoney","d":1280151581,"b":[["q","if your OS is 64-bit then this has far superior performance, you need this runtime: http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867&displaylang=en","Quote from: Olipro on July 26, 2010, 12:01:45 PM"],["t","OS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86. "]],"u":"https://bitcointalk.org/index.php?topic=501.msg5853#msg5853"},{"f":"Olipro","d":1280151986,"b":[["q","> Quote from: Olipro on July 26, 2010, 12:01:45 PM\n> if your OS is 64-bit then this has far superior performance, you need this runtime: http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867&displaylang=en\n\nOS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86.","Quote from: FreeMoney on July 26, 2010, 01:39:41 PM"],["t","the more cores your computer has, the more significant the performance boost, you should also use the EXE from the intel folder, the VS one is inferior but included for completeness."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5854#msg5854"},{"f":"FreeMoney","d":1280153097,"b":[["q","> Quote from: FreeMoney on July 26, 2010, 01:39:41 PM\n> > Quote from: Olipro on July 26, 2010, 12:01:45 PM\n> > if your OS is 64-bit then this has far superior performance, you need this runtime: http://www.microsoft.com/downloads/details.aspx?FamilyID=bd512d9e-43c8-4655-81bf-9350143d5867&displaylang=en\n>\n> OS is 64-bit. I loaded the runtime. It works now, but is the same khash as the x86.\n\nthe more cores your computer has, the more significant the performance boost, you should also use the EXE from the intel folder, the VS one is inferior but included for completeness.","Quote from: Olipro on July 26, 2010, 01:46:26 PM"],["t","I'm confused now, I don't see a VS or an Intel folder. When I unzipped vcredist_x64 I'm getting a bunch of numbered folders 1028, 1031, etc. I ran Setup and when I rerun it it just wants to repair Microsoft Visual C++ x64 Redistributable to it's original state each time.\n\nI've also just noticed that it's getting incoming blocks like 3 or 4 at a time. It could be they're coming in close together, but I think I'm getting them like simultaneously.\n\nEDIT: Okay, I see it now."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5861#msg5861"},{"f":"knightmb","d":1280153213,"b":[["q","OK, now for some absolutely incredible performance.\n\nCredit 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.\n\nPerformance: 4700khash/s on 4 cores, I think that speaks for itself.\n\nI've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.\n\nGrab SHA state caching Bitcoin here <http://www.4shared.com/file/VpSQm9oo/Bitcoin_SHA_state_caching_opt.html>","Quote from: Olipro on July 26, 2010, 06:39:17 AM"],["t","Wow, this is the biggest jump I've ever seen. Nearly a 250% increase in speed from the stock version, amazing.  Now let's see how stable it is  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5863#msg5863"},{"f":"FreeMoney","d":1280153593,"b":[["t","I hit 2700, up from 1250 stock.\n\nI have 7 cores, how do I tell how many it's using? Can I control it?"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5864#msg5864"},{"f":"knightmb","d":1280153765,"b":[["q","I hit 2700, up from 1250 stock.\n\nI have 7 cores, how do I tell how many it's using? Can I control it?","Quote from: FreeMoney on July 26, 2010, 02:13:13 PM"],["t","Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5866#msg5866"},{"f":"TG12","d":1280158087,"b":[["q","> Quote from: FreeMoney on July 26, 2010, 02:13:13 PM\n> I hit 2700, up from 1250 stock.\n>\n> I have 7 cores, how do I tell how many it's using? Can I control it?\nTask Manager and Yes, options in Bit Coin allows you to control how many cores it's using.","Quote from: knightmb on July 26, 2010, 02:16:05 PM"],["t","Long time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.\n\nI had to register to rebel against some of the crap I see been posted here! "]],"u":"https://bitcointalk.org/index.php?topic=501.msg5883#msg5883"},{"f":"knightmb","d":1280158414,"b":[["t","They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5885#msg5885"},{"f":"Olipro","d":1280159023,"b":[["q","> Quote from: knightmb on July 26, 2010, 02:16:05 PM\n> > Quote from: FreeMoney on July 26, 2010, 02:13:13 PM\n> > I hit 2700, up from 1250 stock.\n> >\n> > I have 7 cores, how do I tell how many it's using? Can I control it?\n> Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.\n\nLong time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.\n\nI had to register to rebel against some of the crap I see been posted here!","Quote from: TG12 on July 26, 2010, 03:28:07 PM"],["t","Every time he posts I want to poke him in the eye, the one conveniently posted to the left of his friendly well-meaning nonsense  Grin"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5887#msg5887"},{"f":"Olipro","d":1280159473,"b":[["q","They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has.","Quote from: knightmb on July 26, 2010, 03:33:34 PM"],["t","VMware only permits even numbers of processors/cores although I believe you can expose 8 cores and then configure the OS to only see 7.\n\nif he really does have this setup, I'm going to bet that he's opted for more processors/cores than his CPU actually has (yep, you can do this but it will have a pretty negative effect on performance)"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5890#msg5890"},{"f":"omegadraconis","d":1280160203,"b":[["t","This is going off topic completely but, there is a very slim theoretical chance that you could have 7 cores on an amd machine. You could disable a core on a dual quad-core system or it might be possible to get another core or two by core unlocking (using the extra cores that are some times on amd cpus but,\"locked\"). Based on how many khash/s they are getting they do not have 7 cores or a running in a vm. If they do have 7 cores they should post a cpuz screenshot because, it would seem that we have an outlier in the performance boosts and it would be good to figure out why.\n\nBack on topic, My desktop have been crunching away since last night @  06:57 am forum time (9 hours) using the intel build, no crashes, blocks are coming in, and I have 29 connections. "]],"u":"https://bitcointalk.org/index.php?topic=501.msg5893#msg5893"},{"f":"TG12","d":1280160359,"b":[["q","> Quote from: TG12 on July 26, 2010, 03:28:07 PM\n> > Quote from: knightmb on July 26, 2010, 02:16:05 PM\n> > > Quote from: FreeMoney on July 26, 2010, 02:13:13 PM\n> > > I hit 2700, up from 1250 stock.\n> > >\n> > > I have 7 cores, how do I tell how many it's using? Can I control it?\n> > Task Manager and Yes, options in Bit Coin allows you to control how many cores it's using.\n>\n> Long time visitor, First time poster. How can you possibly have 7 cores? What Processor are you running, Cores come in even numbers . . . I would check your processor is working correctly. How do you even know that you have 7 cores and you don't know how to control them. I'm guessing your a Windows user.\n>\n> I had to register to rebel against some of the crap I see been posted here!\n\nEvery time he posts I want to poke him in the eye, the one conveniently posted to the left of his friendly well-meaning nonsense  Grin","Quote from: Olipro on July 26, 2010, 03:43:43 PM"],["t","Ive only had one post . . . so far! OliPro love the work your doing with BitCoin"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5894#msg5894"},{"f":"knightmb","d":1280162694,"b":[["q","> Quote from: knightmb on July 26, 2010, 03:33:34 PM\n> They do physically, but if you use a virtual machine, you can set environments to have 3 for example. Windows will work with 3 cores or 4 cores just fine, it doesn't care how many it has.\n\nVMware only permits even numbers of processors/cores although I believe you can expose 8 cores and then configure the OS to only see 7.\n\nif he really does have this setup, I'm going to bet that he's opted for more processors/cores than his CPU actually has (yep, you can do this but it will have a pretty negative effect on performance)","Quote from: Olipro on July 26, 2010, 03:51:13 PM"],["t","I was thinking about Virtual Box when I wrote that  Wink"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5902#msg5902"},{"f":"Ground Loop","d":1280167409,"b":[["t","I've thought about dialing BitCoin down to 7 active cores on my desktop machine, just to keep one free for general lightweight UI use."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5910#msg5910"},{"f":"Olipro","d":1280167886,"b":[["q","I've thought about dialing BitCoin down to 7 active cores on my desktop machine, just to keep one free for general lightweight UI use.","Quote from: Ground Loop on July 26, 2010, 06:03:29 PM"],["t","the BitCoin threads are automatically assigned low priority; as soon as any other processes want to use the CPU it will automatically lose CPU time"]],"u":"https://bitcointalk.org/index.php?topic=501.msg5912#msg5912"},{"f":"satoshi","d":1280169691,"b":[["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.\n\nPerformance: 4700khash/s on 4 cores, I think that speaks for itself.\n\nI've included both the VS and Intel build, but there's really no comparison, the Intel build craps all over VS.","Quote from: Olipro on July 26, 2010, 06:39:17 AM"],["t","Is that still starting from Crypto++?  Lets get this into the main sourcecode."]],"u":"https://bitcointalk.org/index.php?topic=501.msg5920#msg5920","s":1,"n":279,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/279/"}]},{"id":"p126","k":"p","s":"bitcointalk","t":"JSON-RPC Multiple Invocations","u":"https://bitcointalk.org/index.php?topic=528","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/126/","m":[{"f":"lachesis","d":1279764589,"b":[["t","I noticed from a hint that Satoshi dropped in the JSON-RPC password thread about so-called \"Multiple Invocation\" support in Bitcoin's JSON-RPC.\n\nAs I run a site that polls bitcoind for payments to a large number of addresses twice a minute, I was intrigued. First of all, this isn't JSON-RPC 2.0's \"Batch\" support, where requests are submitted in an array and responses are received the same way:"],["c","request = [\n        {\"jsonrpc\": \"2.0\", \"method\": \"sum\", \"params\": [1,2,4], \"id\": \"1\"},\n        {\"jsonrpc\": \"2.0\", \"method\": \"subtract\", \"params\": [42,23], \"id\": \"2\"},\n        {\"jsonrpc\": \"2.0\", \"method\": \"get_data\", \"id\": \"9\"}\n    ]\nresponse = [\n        {\"jsonrpc\": \"2.0\", \"result\": 7, \"id\": \"1\"},\n        {\"jsonrpc\": \"2.0\", \"result\": 19, \"id\": \"2\"},\n        {\"jsonrpc\": \"2.0\", \"result\": [\"hello\", 5], \"id\": \"9\"}\n    ]"],["t","Instead, it's something different, and I can't figure out how to parse the responses in Python. Here's a screen capture of a telnet session to the Bitcoin RPC server:"],["c","$ telnet localhost 8332\nTrying 127.0.0.1...\nConnected to localhost.\nEscape character is '^]'.\nPOST / HTTP/1.1\nContent-Type: text/plain\nContent-Length: 97\n\n{\"params\":[],\"id\":1,\"method\":\"getconnectioncount\"}\n{\"params\":[],\"id\":2,\"method\":\"getdifficulty\"}\nHTTP/1.1 200 OK\nConnection: close\nContent-Length: 33\nContent-Type: application/json\nDate: Sat, 08 Jul 2006 12:04:08 GMT\nServer: json-rpc/1.0\n\n{\"result\":8,\"error\":null,\"id\":1}\nHTTP/1.1 200 OK\nConnection: close\nContent-Length: 49\nContent-Type: application/json\nDate: Sat, 08 Jul 2006 12:04:08 GMT\nServer: json-rpc/1.0\n\n{\"result\":181.5432893640505,\"error\":null,\"id\":2}\nConnection closed by foreign host."],["t","As you can see, the server replies with two complete HTTP 200 responses instead of (as I would have expected) one response with the two lines concatenated as I did in the request.\n\nI can't figure out how to parse that with anything at all semi-automated in Python. urllib2 and httplib both return after the first response and drop the second one on the floor.\n\nHas anyone encountered this problem before? Does anyone know of a Python library that can handle this strange multi-request behaviour?"]],"u":"https://bitcointalk.org/index.php?topic=528.msg4923#msg4923"},{"f":"lachesis","d":1279768716,"b":[["t","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.\n\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\n\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:"],["c","    from btcjsonrpc import Service\n    s = Service()\n    print 'preparing getbalance; id:',s.getbalance() # Each call returns its ID so you can find it later in the results\n    print 'preparing getdifficulty; id:',s.getdifficulty()\n    print 'preparing listreceivedbyaddress; id:',s.listreceivedbyaddress(10000) # Call with a parameter\n    print 'preparing getbalance; id:',s.getbalance(id='getbalance 2') # You can also specify your own ID\n    print 'executing callresults:'\n    results = s() # Get the results by calling the Service object\n    for id,value in results.iteritems():\n        print 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.\n    print 'json responses'\n    print s.responses"],["t","And here's the output, including the docstr:"],["c","$ ./btcjsonrpc.py\n Socket-based, Bitcoin-compatible JSON-RPC v1.0 client.\n By: Eric Swanson (http://www.alloscomp.com/bitcoin)\n Version 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).\n\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\n\nUsage is fairly straightforward, and a code sample can be found below the library code (in the if __name__=='__main__' clause).\n\npreparing getbalance; id: jss-1\npreparing getdifficulty; id: jss-2\npreparing listreceivedbyaddress; id: jss-3\npreparing getbalance; id: getbalance 2\n\nexecuting call\n\nresults:\njss-2 181.543289364\njss-3 []\ngetbalance 2 2345.94\njss-1 2345.94\n\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}]"]],"u":"https://bitcointalk.org/index.php?topic=528.msg4940#msg4940"},{"f":"satoshi","d":1279933148,"b":[["t","Obviously it's a bug that it repeats the header.\n\nI was trying to follow the 1.0 spec: http://json-rpc.org/wiki/specification   It called for multiple invocation.\n\nI think they mean it's like this, but I'm not sure:\n\nPost:\n{\"method\": \"postMessage\", \"params\": [\"Hello all!\"], \"id\": 99}\n{\"method\": \"postMessage\", \"params\": [\"I have a question:\"], \"id\": 101}\n\nReply:\n{\"result\": 1, \"error\": null, \"id\": 99}\n{\"result\": 1, \"error\": null, \"id\": 101}\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=528.msg5416#msg5416","s":1,"n":261,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/261/"}]},{"id":"p127","k":"p","s":"bitcointalk","t":"Scalability and transaction rate","u":"https://bitcointalk.org/index.php?topic=532","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/127/","m":[{"f":"Red","d":1279775848,"b":[["t","I'm curious about the developers feelings on scalability. For example, could the system handle a million users, doing say 5 transactions each per day. 5 million transactions per day is roughly 35,000 transactions per 10 minute period?\n\nIs there a bottle neck in propagating 35,000 transactions to a million nodes for block generation? Or has that issue been designed for?"]],"u":"https://bitcointalk.org/index.php?topic=532.msg4963#msg4963"},{"f":"jgarzik","d":1279781158,"b":[["t","Large transaction rates are a key future bottleneck of the current bitcoin system."]],"u":"https://bitcointalk.org/index.php?topic=532.msg4968#msg4968"},{"f":"Red","d":1279781685,"b":[["q","Large transaction rates are a key future bottleneck of the current bitcoin system.","Quote from: jgarzik on July 22, 2010, 06:45:58 AM"],["t","Is this a completely connected network? Or is there some sort of ordered propagation scheme? Didn't read that section of code yet."]],"u":"https://bitcointalk.org/index.php?topic=532.msg4970#msg4970"},{"f":"Hepatizon","d":1279811002,"b":[["t","As far as I can tell, it's a completely connected network.  And it kind of has to be for the security to work - the main idea is that an attacker needs nearly 50% of the computing power of the entire network to inject false transaction information into (or delete honest transactions from) the network.  If there was a propagation system, you'd only need to to have about 50%+ of whatever the lowest rung is, and then the rung would be duped into transmitting your false information, possibly beating out the other lowest rungs to dupe the next higher up rung, and so on.\n\nThe bottleneck was my first reaction when I read about bitcoin.  For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction.  So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there.  And since the blocks form a straight chain, all of those 35,000 transactions need to go into the same block (if block generation continues to average one per ten minutes).  There's currently no way to split that up and have the network work on 350 blocks with 100 transactions each simultaneously, because each block needs the hash of the previous block.  That seems particularly silly with the way bitcoin transactions are verified.  If everyone waits for one to three blocks to verify a transaction before spending their bitcoins, that means that none of the 35,000 transactions in one ten minute period can depend on each other, and most shouldn't even depend on the previous block.  And as far as I can tell, there's no way for the network to speed up block creation in response to transaction overload - if the network ever hit the point where transactions were being made faster than they were being hashed into blocks, the problem would snowball until enough people quit bitcoin out of frustration that the number of transactions dropped below block creation speed.  And if block creation were to speed up (via difficulty decrease) then the reward for hashing a new block would have to go down to maintain the planned rate of bitcoin introduction.  The nodes would have to know that during the Great Bitstorm of August 2013 blocks only netted the creator 2.5 bitcoins - and they'd have to figure it out during the Great Bitstorm of August 2013.\n\nAlso, there's a potential problem if block creation speed were to exceed the speed of information on the network.  Chains could be built faster than they would be distributed to the rest of the network, which could mean that two different network segments could work on two different chains simultaneously.\n\nAnd of course it's worse than 35,000 transactions / ten minutes - we'd probably see something like 50-60k+ transactions during peak hours (depending on how geographically distributed the network is) and much less during the off hours.  There would be a need to dynamically throttle proof-of-work difficulty and coin reward hour-by-hour.  Since bitcoin is computer based, there'll probably eventually be a fair number of automated systems buying and selling bitcoins - a sudden sharp fluctuation in stock markets or currency exchange rates could set those off all at once.  (Although the verification system might help with this, since you can't do microsecond scale trading with bitcoins.)"]],"u":"https://bitcointalk.org/index.php?topic=532.msg5040#msg5040"},{"f":"Quantumplation","d":1279811359,"b":[["t","It's not a completely connected network in the sense that every client isn't connected to every other client.  If by completely connected you mean there's x degrees of separation between everyone, then yes, that's how it is.  Data gets \"spread\" throughout the network as time goes on, not instantaneously (though it is pretty fast).\n\nThis was mostly a thought experiment for satoshi, as I understand it.  If the userbase continues to grow substantially, then obviously a great amount of work will go into optimizing and revising the algorithm to support more advanced and intelligent distribution."]],"u":"https://bitcointalk.org/index.php?topic=532.msg5043#msg5043"},{"f":"Red","d":1279816110,"b":[["t","Thank you both!\n\nI understand that all transactions and all validated blocks need to get to every node. I was just curious about the implementation of the broadcast mechanism.\n\nAt worst case a million nodes would each have a million minus one open connections (bad). A better case would have each node broadcast to log(n) nodes who relayed to log(n) node, and to complete the broadcast in log(n) time.\n\nDo you have any details of the thought experiment quantumplication?"]],"u":"https://bitcointalk.org/index.php?topic=532.msg5068#msg5068"},{"f":"Red","d":1279816964,"b":[["t","Thanks for your analysis Hepatizon! It was about what I was expecting.\n\nHowever, I don't think this is quite correct."],["q","For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction.  So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there. ","Quote from: Hepatizon on July 22, 2010, 03:03:22 PM"],["t","It appears that each new transaction has direct links to each prior transaction being used as an input. To validate a transaction you only need to validate the immediate dependancies. You don't need to validate those dependancies' dependancies as they were previously validated as part of the block chain. That means closer to constant time rather than linear.\n\nI'm new though so I could be reading it wrong. Please correct me if I did.\n\nThe rest of your critique seems well analyzed and a bit frightening. Thanks again! "]],"u":"https://bitcointalk.org/index.php?topic=532.msg5070#msg5070"},{"f":"Hepatizon","d":1279860825,"b":[["q","Thanks for your analysis Hepatizon! It was about what I was expecting.\n\nHowever, I don't think this is quite correct.\n\n> Quote from: Hepatizon on July 22, 2010, 03:03:22 PM\n> For one thing, the way the blocks are currently set up, it takes linear time with respect to the total number of transactions (and I think more than that in memory) to verify one transaction.  So after 10 years of bitcoin, you need to either go through all 10 years worth of transactions, or have a snapshot of all the account balances of every user ever and work from there. \n\nIt appears that each new transaction has direct links to each prior transaction being used as an input. To validate a transaction you only need to validate the immediate dependancies. You don't need to validate those dependancies' dependancies as they were previously validated as part of the block chain. That means closer to constant time rather than linear.","Quote from: Red on July 22, 2010, 04:42:44 PM"],["t","You're right - I keep forgetting that the actual coins are tracked rather that just the account balance.  So yeah, you only need to go back find whoever last owned the coins in question and verify that they're the same person sending them.  Which is technically linear time in that if the first coin ever was hoarded for ten years you really would need to go through the entire ten year block chain (unless you indexed it, which would be easy as all the coins are numbered) to see who had it - but in practice it would be closer to constant time because most people won't hoard bitcoins.  (Unless they figure out that deflation is all but guaranteed...)  For some reason I keep thinking that you would need to verify the account balance of the sender, and that would require verifying the account balance of everyone who has sent the sender money, and everyone who sent them money, and so forth."]],"u":"https://bitcointalk.org/index.php?topic=532.msg5198#msg5198"},{"f":"Quantumplation","d":1279889244,"b":[["t","Er, by \"thought experiment\", I meant \"proof of concept\".  Satoshi seems to be pretty intelligent, and I don't think he was naive enough to think he would come up with the final specifications for the algorithm in the first go.  In ANY project, there's always new things that crop up, and a well designed system is not one that accounts for every possibility, it's one that can adapt and change cleanly."]],"u":"https://bitcointalk.org/index.php?topic=532.msg5256#msg5256"},{"f":"Red","d":1279889622,"b":[["t","I didn't mean anything other than how does the network communicate now?\n\nWhen I run the network I see 20ish connections. I'm assuming that is not every node running. How does the algorithm decide who talks to who?\n\nThere are several know distributed hash table topologies. Was wonder if it was using one of those.\n\nGranted, it could be everyone talks to everyone at the moment, and to be optimized in the future. I'd find that a reasonable answer too.\n\nCheers!"]],"u":"https://bitcointalk.org/index.php?topic=532.msg5258#msg5258"},{"f":"Quantumplation","d":1279891136,"b":[["t","AFAIK, it chooses some random connections to connect to from the IRC bootstrapper, but I'm not sure."]],"u":"https://bitcointalk.org/index.php?topic=532.msg5263#msg5263"},{"f":"Red","d":1279908823,"b":[["q","AFAIK, it chooses some random connections to connect to from the IRC bootstrapper, but I'm not sure.","Quote from: Quantumplation on July 23, 2010, 01:18:56 PM"],["t","Actually communicating through federated irc servers would probably work as well as anything. :-)"]],"u":"https://bitcointalk.org/index.php?topic=532.msg5346#msg5346"},{"f":"bytemaster","d":1280326253,"b":[["t","Based upon my understanding of economics there is only one way to resolve the scalability problem:  the pricing system.   Internet bandwidth, CPU time, hard disk space, etc are all valuable resources and expecting individuals to \"donate time\" or make a profit in \"bit coin mining\" is to arbitrary and leaves little room for innovation. \n\nEffectively, if you want to post a transaction there must be a fee awarded to the individual who gets it posted in a block.  There should also be some kind of fee for propagating the transaction to all of the nodes to begin with.    Thus propagation isn't automatic it comes at a price.  Each node that passes along your transaction to other block creators should get a cut of the transaction fee.  In this way the network can load balance based upon economic incentive and the \"most valuable\" transactions get highest priority at a price. "]],"u":"https://bitcointalk.org/index.php?topic=532.msg6194#msg6194"},{"f":"Red","d":1280334726,"b":[["q","expecting individuals to \"donate time\" or make a profit in \"bit coin mining\" is to arbitrary and leaves little room for innovation. \n...\n\nEffectively, if you want to post a transaction there must be a fee awarded to the individual who gets it posted in a block...","Quote from: bytemaster on July 28, 2010, 02:10:53 PM"],["t","I used to have similar thoughts, but I decided I was wrong. It turns out that BitCoin is peer to peer in the sense that tier-1 internet providers are peer to peer. It is not P2P in the same sense that bittorrent is P2P.\n\nSatoshi points out that he sees the NEED for at most 100,000 nodes verifying transactions and logging blocks. Others would use those nodes in a more client/service fashion. If I was guessing that number I would put it much lower (3<X<100) independent interested parties. Anyone can choose to be one of those X parties, or can choose to validate some or all of the work of those X parties, but only a small number are really REQUIRED.\n\nBecause in effect, the entire block list is mostly a distributed notary service. And though that requires rigor, it is not a particularly hard job.\n\nSo who would choose to do that job for free?\n\nKnightmb for one. I'm have no doubt that many others like NewLibertyStandard will as well. Why Knightmb specifically? Well he has lots of coins and his business model and personal wealth relies on a well functioning honest system. Without that, his wealth and business simply evaporate. It is altruism and cooperation though self interest.\n\nIf you want a real world example consider the internet itself. At its amorphous core are about 7 tier-1 service providers. They are called tier-1 only because each has a mutually self interested \"peering agreement\" with the other six providers. That means these huge services providers move phenomenal amounts of date back and forth with zero accounting and zero payments among each other. They make all their money by selling their service to NON-tier-1 providers who make their money from selling it to you.\n\nThere is nothing to stop anyone from becoming a tier-1 provider. All you have to do is convince the others that it is in their self interest to peer with you. So for a example, Google is thought to pay zero in bandwidth to transmit youtube videos. There is enough traffic both ways, that it is in everyones self-interest to peer with them.\n\nI expect that the same will happen with BitCoin. All the internal accounting and transfers will be free. (with the exclusion of transaction fees meant to avoid spam and mischief). Value will be created at the edges where people exchange bitcoins for something else of value."]],"u":"https://bitcointalk.org/index.php?topic=532.msg6223#msg6223"},{"f":"rodin","d":1280341558,"b":[["t","Was the original question ever answered? Can the clients handle 35000 transactions per block? What about 100000? What is the bytesize of a transaction in the block? How much bandwidth is needed for the network to push these around in 10 minutes?"]],"u":"https://bitcointalk.org/index.php?topic=532.msg6245#msg6245"},{"f":"bytemaster","d":1280350782,"b":[["t","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. \n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=532.msg6269#msg6269"},{"f":"satoshi","d":1280368838,"b":[["t","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."],["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.","Quote from: bytemaster on July 28, 2010, 08:59:42 PM"],["t","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"]],"u":"https://bitcointalk.org/index.php?topic=532.msg6306#msg6306","s":1,"n":287,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/287/","qt":["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."],"qc":["nodes"]}]},{"id":"p128","k":"p","s":"bitcointalk","t":"bitcoind not responding to RPC","u":"https://bitcointalk.org/index.php?topic=548","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/128/","m":[{"f":"mtgox","d":1279888188,"b":[["t","Occasionally bitcoind will not respond to RPC I'm calling it from php and I get this error:\n\nWarning: fopen(http://127.0.0.1:8332) [function.fopen]: failed to open stream: HTTP request failed! HTTP/1.1 500 Internal Server Error\n\nIt happens a lot locally on my windows machine and less frequently on my linux server.\n\nAnyone else have this problem? "]],"u":"https://bitcointalk.org/index.php?topic=548.msg5248#msg5248"},{"f":"The Madhatter","d":1279902196,"b":[["t","Try taking the \"http://\" out of your fsockopen(). The JSON-RPC server isn't really HTTP.\n\nI've had the best luck with the curl+json php extensions, myself."]],"u":"https://bitcointalk.org/index.php?topic=548.msg5319#msg5319"},{"f":"mtgox","d":1279902359,"b":[["t","Well it works 95% of the time which is what is weird"]],"u":"https://bitcointalk.org/index.php?topic=548.msg5320#msg5320"},{"f":"The Madhatter","d":1279903140,"b":[["t","Strange. I use my bitcoind almost every day from PHP, and I haven't encountered that."]],"u":"https://bitcointalk.org/index.php?topic=548.msg5325#msg5325"},{"f":"mtgox","d":1279903656,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=548.msg5331#msg5331"},{"f":"satoshi","d":1279905827,"b":[["t","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\"}."]],"u":"https://bitcointalk.org/index.php?topic=548.msg5339#msg5339","s":1,"n":257,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/257/"},{"f":"mtgox","d":1279908888,"b":[["t","Weird I guess fopen() in php dies if the response is 500?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=548.msg5347#msg5347"},{"f":"satoshi","d":1279934158,"b":[["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=548.msg5419#msg5419","s":1,"n":262,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/262/"}]},{"id":"p129","k":"p","s":"bitcointalk","t":"Faster initial block download (5x faster)","u":"https://bitcointalk.org/index.php?topic=550","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/129/","m":[{"f":"satoshi","d":1279909496,"b":[["t","By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster.  It downloads in about 30 minutes.\n\nThe database default had it writing each block to disk synchronously, which is not necessary.  I changed the settings to let it cache the changes in memory and write them out in a batch.  Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.\n\nI only enabled this change during the initial block download.  When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.\n\nI built a test build if you'd like to start using it:\n\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz\n\nThese binaries also include Gavin Andresen's JSON-RPC HTTP authentication feature and the other important security improvements from 0.3.2.\n\nI've been running a test over the last 24 hours that kills and restarts it randomly every 2-60 seconds (poor thing) while it's trying to do an initial block download and it's been fine.\n\nThere are no changes to the way it handles wallet.dat.  This change is only for blk*.dat and the non-critical addr.dat.  You can always delete blk*.dat if it gets screwed up and let it re-download."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5349#msg5349","s":1,"n":258,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/258/","qt":["By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster.  It downloads in about 30 minutes. \n \nThe database default had it writing each block to disk synchronously, which is not necessary.  I changed the settings to let it cache the changes in memory and write them out in a batch.  Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state. \n \nI only enabled this change during the initial block download.  When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way."],"qc":["bitcoin-design"]},{"f":"knightmb","d":1279909670,"b":[["t","Are these for use with the test network you have setup or the current public network?"]],"u":"https://bitcointalk.org/index.php?topic=550.msg5350#msg5350","sj":"Re: Faster initial block download"},{"f":"NewLibertyStandard","d":1279910545,"b":[["q","Are these for use with the test network you have setup or the current public network?","Quote from: knightmb on July 23, 2010, 06:27:50 PM"],["t","This is for the regular network. The test network doesn't have enough blocks to test it effectively. From what I can tell, satoshi's builds are always for the live network unless he specifies otherwise."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5353#msg5353","sj":"Re: Faster initial block download"},{"f":"knightmb","d":1279911005,"b":[["t","Awesome, got some extra slow machines to wipe/test with then. Will be curious to see what it does on faster machines as well.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=550.msg5356#msg5356","sj":"Re: Faster initial block download"},{"f":"knightmb","d":1279911710,"b":[["t","So far, awesome increase for the Windows client. Doing about 500 blocks / second using a private node. After the timer is done, I'll try it on a wild node out on the Internet to see if the speed is just as good."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5359#msg5359","sj":"Re: Faster initial block download"},{"f":"knightmb","d":1279913578,"b":[["q","By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster.  It downloads in about 30 minutes.\n\nThe database default had it writing each block to disk synchronously, which is not necessary.  I changed the settings to let it cache the changes in memory and write them out in a batch.  Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state.\n\nI only enabled this change during the initial block download.  When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.","Quote from: satoshi on July 23, 2010, 06:24:56 PM"],["t","The first part of the 70k downloaded in about 20 minutes, the rest of the remaining 2000 blocks in about 7 minutes, so only 27 minutes from 0 to 100%, very nice! 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?\n\nIn case anyone was curious, average download speed was around 3 Mbps for each burst of download."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5369#msg5369","sj":"Re: Faster initial block download"},{"f":"knightmb","d":1279915466,"b":[["t","Blocks download just as fast in the wild (about 3 Mbps), so a big thumbs up, this will certainly get new users up and running much quicker."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5376#msg5376","sj":"Re: Faster initial block download"},{"f":"satoshi","d":1279916007,"b":[["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?","Quote from: knightmb on July 23, 2010, 07:32:58 PM"],["t","Not really.  I'll change it to 1000 next time."]],"u":"https://bitcointalk.org/index.php?topic=550.msg5378#msg5378","s":1,"n":259,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/259/","sj":"Re: Faster initial block download"}]},{"id":"p130","k":"p","s":"bitcointalk","t":"Reading/Writing Blocks and FLATDATA","u":"https://bitcointalk.org/index.php?topic=555","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/130/","m":[{"f":"Hepatizon","d":1279934852,"b":[["t","I'm trying to understand the way Bitcoin stores block data - among other things I want to run some statistics on the block chain / transaction history and check just how anonymous Bitcoin really is.  So I went to the source to see how Bitcoin reads/writes block data to file.\n\n(ETA: this is in 0.3.2)\n\nIn main.h we have:"],["c","bool WriteToDisk(bool fWriteTransactions, unsigned int& nFileRet, unsigned int& nBlockPosRet)\n{\n    // Open history file to append\n    CAutoFile fileout = AppendBlockFile(nFileRet);\n    if (!fileout)\n        return error(\"CBlock::WriteToDisk() : AppendBlockFile failed\");\n    if (!fWriteTransactions)\n        fileout.nType |= SER_BLOCKHEADERONLY;\n\n    // Write index header\n    unsigned int nSize = fileout.GetSerializeSize(*this);\n    fileout << FLATDATA(pchMessageStart) << nSize;\n\n    // Write block\n    nBlockPosRet = ftell(fileout);\n    if (nBlockPosRet == -1)\n        return error(\"CBlock::WriteToDisk() : ftell failed\");\n    fileout << *this;\n\n    // Flush stdio buffers and commit to disk before returning\n    fflush(fileout);\n#ifdef __WXMSW__\n    _commit(_fileno(fileout));\n#else\n    fsync(fileno(fileout));\n#endif\n\n    return true;\n}"],["t","and"],["c","bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)\n{\n    SetNull();\n\n    // Open history file to read\n    CAutoFile filein = OpenBlockFile(nFile, nBlockPos, \"rb\");\n    if (!filein)\n        return error(\"CBlock::ReadFromDisk() : OpenBlockFile failed\");\n    if (!fReadTransactions)\n        filein.nType |= SER_BLOCKHEADERONLY;\n\n    // Read block\n    filein >> *this;\n\n    // Check the header\n    if (CBigNum().SetCompact(nBits) > bnProofOfWorkLimit)\n        return error(\"CBlock::ReadFromDisk() : nBits errors in block header\");\n    if (GetHash() > CBigNum().SetCompact(nBits).getuint256())\n        return error(\"CBlock::ReadFromDisk() : GetHash() errors in block header\");\n\n    return true;\n}"],["t","FLATDATA is defined in serialize.h like so:"],["c","//\n// Wrapper for serializing arrays and POD\n// There's a clever template way to make arrays serialize normally, but MSVC6 doesn't support it\n//\n#define FLATDATA(obj)   REF(CFlatData((char*)&(obj), (char*)&(obj) + sizeof(obj)))\nclass CFlatData\n{\nprotected:\n    char* pbegin;\n    char* pend;\npublic:\n    CFlatData(void* pbeginIn, void* pendIn) : pbegin((char*)pbeginIn), pend((char*)pendIn) { }\n    char* begin() { return pbegin; }\n    const char* begin() const { return pbegin; }\n    char* end() { return pend; }\n    const char* end() const { return pend; }\n\n    unsigned int GetSerializeSize(int, int=0) const\n    {\n        return pend - pbegin;\n    }\n\n    template<typename Stream>\n    void Serialize(Stream& s, int, int=0) const\n    {\n        s.write(pbegin, pend - pbegin);\n    }\n\n    template<typename Stream>\n    void Unserialize(Stream& s, int, int=0)\n    {\n        s.read(pbegin, pend - pbegin);\n    }\n};"],["t","Now - and I apologize if I'm reading this wrong, this is a little more advanced C/C++ code than I'm used to - as I understand it, the FLATDATA call interprets the raw bytes of a CBlock object as an array (stream??) of characters.  The CBlock::WriteToDisk method writes the constant 4-byte message header (0xf9, 0xbe, 0xb4, 0xd9), the size of the CBlock object in bytes, and then the FLATDATA of the CBlock it's writing to disk - which is just the raw bytes of the CBlock object.  So after the header, the data written to file is byte-for-byte the same as the CBlock object represented in memory.  Also, if I'm reading it correctly, CBlock::ReadFromFile copies those bytes directly into the space allocated for a CBlock object in memory to re-create the block.  Is this correct?\n\nRelated question - I am under the impression that the exact way an instance of a C++ class is represented internally not guaranteed under standards; compiling a program with different compilers or different optimization flags can change the order in which member variables are stored in memory, and some debug mode compilers even add a few bytes between member variables to make memory inspection easier.  I'm not positive about this, it's just something I've picked up and never seriously questioned."]],"u":"https://bitcointalk.org/index.php?topic=555.msg5423#msg5423"},{"f":"Gavin Andresen","d":1279935842,"b":[["t","They key bits of code are:"],["c","fileout << FLATDATA(pchMessageStart) << nSize;\n...\nfileout << *this;"],["t","pchMessageStart are the four magic bytes, and those are written with FLATDATA.\n\nThe CBlock itself is written by << *this, and that's done by the IMPLEMENT_SERIALIZE in main.h:"],["c","    IMPLEMENT_SERIALIZE\n    (\n        READWRITE(this->nVersion);\n        nVersion = this->nVersion;\n        READWRITE(hashPrevBlock);\n        READWRITE(hashMerkleRoot);\n        READWRITE(nTime);\n        READWRITE(nBits);\n        READWRITE(nNonce);\n\n        // ConnectBlock depends on vtx being last so it can calculate offset                                             \n        if (!(nType & (SER_GETHASH|SER_BLOCKHEADERONLY)))\n            READWRITE(vtx);\n        else if (fRead)\n            const_cast<CBlock*>(this)->vtx.clear();\n    )"],["t","The READWRITE macros Do The Right Thing, reading in or writing out the members in a machine-independent way.\n\nSee http://github.com/gavinandresen/bitcointools for simplified Python code that can dump out transactions and blocks."]],"u":"https://bitcointalk.org/index.php?topic=555.msg5424#msg5424"},{"f":"Hepatizon","d":1279939985,"b":[["t","Thanks for clearing that up for me.\n\nI keep making really elementary code mistakes...."]],"u":"https://bitcointalk.org/index.php?topic=555.msg5435#msg5435"},{"f":"satoshi","d":1279944260,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=555.msg5450#msg5450","s":1,"n":265,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/265/"}]},{"id":"p131","k":"p","s":"bitcointalk","t":"Version 0.3.2.5 -- please test!","u":"https://bitcointalk.org/index.php?topic=556","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/131/","m":[{"f":"satoshi","d":1279942372,"b":[["t","Please test 0.3.2.5 in preparation for the 0.3.3 release!  This build is looking good and should be the one that goes into 0.3.3.  I encourage you to go ahead and upgrade now if you're on Windows or Linux.\n\nNew features:\n- Gavin Andresen's HTTP authentication to secure JSON-RPC\n- 5x faster initial block download, under 30 minutes\n\nDownload here:\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.zip\nhttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz\n\nThanks!"]],"u":"https://bitcointalk.org/index.php?topic=556.msg5443#msg5443","s":1,"n":264,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/264/"}]},{"id":"p132","k":"p","s":"bitcointalk","t":"a simple traffic load test run","u":"https://bitcointalk.org/index.php?topic=567","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/132/","m":[{"f":"lfm","d":1280062948,"b":[["t","I have seen some speculation about scalability and denial of service by spam transactions in the IRC channel so I thought it would be a good idea to try a test.\n\nI set up a stupid little bitcoind script on a couple of my linux machines to send 1000 tiny transaction to a third machine as quickly as they would run.\n\nI asked on IRC for any obvious reasons why I shouldn't do it and got one supporting response thinking it was a good idea to try and one reserved response saying I should ask here first. I brashly decided to go ahead with it.\n\nThe scripts just printed a countdown of the number of remaining steps in the loop and the output of the bitcoind sendtoaddress command, normally just \"sent\".\n\nThey both started out quickly till there was something like 600 transactions submitted then both senders started to slow down perceptibly. One was quite a bit faster than the other, 3 or 4 times faster, due I think to a faster CPU. I thought at first it was the clients throtteling me to save the net from overload or something but that was just speculation. We later figured maybe it was the databases getting a bit slow on my old disks.\n\nThen one of my machines suddenly seemed to speed up. But it wasn't really. It was an error, the bitcoind daemon had died. A little bit of investigation found the .bitcoin drive was full so you can't fault the program for giving up there! grin\n\nThe other machine was grinding pretty slow by then down to maybe 5 sec per transaction or so just judging by eye. It eventually finished after about 50 minutes. no errors at all.\n\nThe machine that crashed after I gave it some more disk space started right back up and showed it had only sent 424 transactions so there is an initial benchmark then - 1424 transactions in 50 minutes. It should be easy to get more.\n\nI think the main thing slowing them down was the .bitcoin/database directory. They seemed to get a lot of data written to them some 184MB on the one that ran outa disk space and 1341 MB on the one that did the full 1000 transactions.\n\nIt seems another test with more people more distributed around the net might be in order to try to shake down any potential problems.\n\nThe net seemed to shrug it off as if nothing special happened anyway so that is a positive result. The clients mostly did just what they were told and expected except for a possible performance problem with the database.\n\nThats all I can think of for now."]],"u":"https://bitcointalk.org/index.php?topic=567.msg5685#msg5685"},{"f":"lfm","d":1280063345,"b":[["t","I was able to run IRC and discus the progress of the test thruout so I don't think I was anywhere near saturating any network resources."]],"u":"https://bitcointalk.org/index.php?topic=567.msg5686#msg5686"},{"f":"theymos","d":1280063596,"b":[["t","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.\n\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"]],"u":"https://bitcointalk.org/index.php?topic=567.msg5687#msg5687"},{"f":"satoshi","d":1280069193,"b":[["t","Was that on the test network?\nhttp://bitcointalk.org/index.php?topic=363.0"]],"u":"https://bitcointalk.org/index.php?topic=567.msg5694#msg5694","s":1,"n":266,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/266/"},{"f":"theymos","d":1280070043,"b":[["q","Was that on the test network?\nhttp://bitcointalk.org/index.php?topic=363.0","Quote from: satoshi on July 25, 2010, 02:46:33 PM"],["t","No."]],"u":"https://bitcointalk.org/index.php?topic=567.msg5696#msg5696"},{"f":"satoshi","d":1280071792,"b":[["t","Please do these tests on the test network.  That's what it's for.  Thanks."]],"u":"https://bitcointalk.org/index.php?topic=567.msg5698#msg5698","s":1,"n":267,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/267/"}]},{"id":"p133","k":"p","s":"bitcointalk","t":"Bitcoin 0.3.3 released -- PLEASE UPGRADE","u":"https://bitcointalk.org/index.php?topic=570","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/133/","m":[{"f":"satoshi","d":1280076909,"b":[["t","Please upgrade to 0.3.3!  Important security improvements were made in 0.3.2 and 0.3.3.\n\nNew features:\n- Gavin Andresen's HTTP authentication to secure JSON-RPC\n- 5x faster initial block download, under 30 minutes"]],"u":"https://bitcointalk.org/index.php?topic=570.msg5707#msg5707","s":1,"n":268,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/268/"}]},{"id":"p134","k":"p","s":"bitcointalk","t":"Stealing Coins","u":"https://bitcointalk.org/index.php?topic=571","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/134/","m":[{"f":"Red","d":1280077683,"b":[["t","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.\n\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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5708#msg5708"},{"f":"knightmb","d":1280078369,"b":[["t","It's open source software, better to discuss it now than try to keep it a secret for someone else to discover and they may not be willing to share any details."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5709#msg5709"},{"f":"satoshi","d":1280079922,"b":[["t","It's best if you tell it to me privately so it can be fixed first.\n\nI just e-mailed you my e-mail address.  (or you could PM me here)"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5712#msg5712","s":1,"n":269,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/269/"},{"f":"Red","d":1280081251,"b":[["t","You stopped my post just in time! :-)"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5715#msg5715"},{"f":"Quantumplation","d":1280081380,"b":[["t","Once it's fixed or proven not to work, could you post the details here?  I'm very curious. =)"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5716#msg5716"},{"f":"knightmb","d":1280081705,"b":[["t","I think I know what he means, but I was certain that the odds of doing it a bit too random to make an attack out of it."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5719#msg5719"},{"f":"satoshi","d":1280084783,"b":[["t","Red, thanks for telling me privately first!  Please go ahead and post it (and relieve the suspense for everyone!)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5724#msg5724","s":1,"n":270,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/270/"},{"f":"Red","d":1280084983,"b":[["t","Thanks Satoshi,\n\nHere is what I sent him.\n\n-----------\n\nPublic key cryptography depends on the fact that it is hard to factor large prime numbers. Everyone knows that. If bitcoins were transfers were assigned to a well formed public key, and an associated private key signature was required for future transfer I would concede that bitcoins crypto transfers were completely secure.\n\nHowever, bitcoin transactions don't seem to work that way (by my reading). Transactions assign coin amounts to a particular \"bitcoin address\". Where the address is a hash of the public key.\n\nTo validate a transaction, nodes take the public key from the signature and use that to verify the actual signature. If the signature is valid, it then hashes the public key to confirm it matches the bitcoin address assigned in the previous transaction. If both match, by definition, the transaction is good.\n\nThe potential weakness is in associating the public key in the signature with the bitcoin address.\n\nThere is a many to one relationship between public keys and a given hash. Now, if finding a pair of prime numbers that creates a secure public/private key pair where the public key part hashes to a particular bitcoin address seems hard... it probably is.\n\nHowever, that is not required.\n\nAll you need is ANYTHING representing a public key that hash collides with a know large bitcoin account. It does NOT have to be a secure key pair based on primes. It is simply has to work once and allow the transfer of the stolen money to another account. That is potentially much easier.\n\nSome hashes are harder to collide than others. I'm not sure the strength of the hash being used. However, colliding any hash gets much easier if you don't have to care about the content being hashed.\n\nBecause of the nature of public keys they look like random data. As I understand them, you can't know if a public key is based upon secure math unless you succeed in factoring it. Therefore clients don't try. They normally just do the validation of the signature and presume the public key was generated in a secure fashion if it worked.\n\nNOTE: The following analysis needs double checking by a real cryptohacker. IANACR\n\nSo depending on the hash, you could use one of the up-and-coming hash collision algorithms to generate a colliding block of data which represents a public key. Then by reversing the public/private key math, generate an associated (but hardly secure at all) private key that would generate valid signatures.\n\nYou then take your insecure, easily factorable, key pair and generate a signed transaction that matches the target bitcoin address.\n\nSince the transaction log, can't validate the full public key the coins were intended for, it simple presumes it must have been the one presented.\n\nBy recording the full public key of the transfer target in the block list you can regain the intended strength. However, you lose the ability to pass around 34 character addresses.\n\nIf I'm off base, I apologize for wasting your time.\n\nCheers!\nRed"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5725#msg5725"},{"f":"Red","d":1280085734,"b":[["t","Satoshi pointed out that my scenario still required the hash function to be broken. That is true, but I was surprised to learn how successful some have been with that. MD4 and MD5 are obvious examples. But work is well underway at colliding SHA-1 and siblings like SHA-256.\n\nWhat hash is being used in this part of Bitcoin?\n\nHe is also skeptical that you could you could use something other than a generated keypair.\n\nOn this point, I'm pretty confident that it is a simple matter of mathematics. I didn't pay enough attention to this until I learned about \"blind signing\" of documents.\n\nIt turns out you can take a document and multiply it by a random number. Then have someone sign the jumbled file. Finally, you divide your random number out of their signature and the result is still a valid signature for the original document. Who'd figured that would work!\n\nAnyway, if keypairs are only secure if they are based upon pairs of primes. Then nothing changes any of the math if the numbers are not prime. They are just much easier to factor.\n\nI'd be perfectly happy for some crypto guy to prove me an idiot. It effects some features of a previous project I created that relied on the same association. I didn't think of this then either."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5728#msg5728"},{"f":"knightmb","d":1280086482,"b":[["t","Very nice. *another reason why I love open source*\n\nAs I understand it then, and please correct me if I'm wrong\n\nSince the hash of the public key is smaller than the actual public key itself, one need only find a collision that matches the hash and when that collision is found you'll know the public/private key combo. Then you simply spend coin using the known ones and the other clients will think it's a valid transfer because the clients are only concerned that your hash matches the hash of the victim and the transaction is recorded for all time.\n\nCurrently the hash is 35 characters long, alpha-numeric\n26 (upper case) +26 (lower case) +10 (numbers) = 62 possible per character\nSo we have 541,638,008,296,341,754,635,824,011,376,225,346,986,572,413,939,634,062,667,808,768 possible combinations.\n\nSo I think we have about half of much work to do compared to going brute force against the main private/public key. Never hurts to plan for the future  Wink"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5733#msg5733"},{"f":"knightmb","d":1280087042,"b":[["q","Satoshi pointed out that my scenario still required the hash function to be broken. That is true, but I was surprised to learn how successful some have been with that. MD4 and MD5 are obvious examples. But work is well underway at colliding SHA-1 and siblings like SHA-256.","Quote from: Red on July 25, 2010, 07:22:14 PM"],["t","What they often don't mention though is *collision generating* still takes a lot of CPU time.\n\nIf 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.\n\nBut from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5736#msg5736"},{"f":"Red","d":1280087543,"b":[["t","From what I was told, bitcoin is using one of the 160 bit hashes for generating bitcoin address.\n\nThe SHA-1 family of hash algorithms are some of the most commonly used. SHA-1 is a 160 bit hash.\n\nHere 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.\n\nhttp://www.ictlex.net/wp-content/iacrhash.pdf\n\nThe MD5 hashes can already be crashed in seconds on laptops. That was why it was retired from certificate based signatures.\n\nAnd yes what I'm saying is **I think** you can think of a public key as two secret numbers mathematically combined together. And the private key as those two numbers kept separately. The thing that make the system secure requires that the two secret numbers be really large prime numbers.\n\nBut if they are really large non-prime numbers the combination math still works, it is just must faster to break the algorithm.\n\nI'll do a little more googling and see if I can substantiate my claims. I was hoping someone could dismiss them out of hand though."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5737#msg5737"},{"f":"satoshi","d":1280088100,"b":[["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.\n\nBut from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.","Quote from: knightmb on July 25, 2010, 07:44:02 PM"],["t","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.\n\nWhen you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5740#msg5740","s":1,"n":271,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/271/"},{"f":"knightmb","d":1280089241,"b":[["q","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.\n\nWhen you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.\n\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.\n\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.","Quote from: satoshi on July 25, 2010, 08:01:40 PM"],["t","Yeah, I thought the private key had to be in the mix somewhere. It kind of adds another randomness though, you have to find the hash that collides with another public key and at the same time, the private key has to be weak enough to break. I'm not saying it's impossible, but it introduces 2 variables into the reverse collision finding.\n\nBasically, one would build a rainbow table of weak private keys and then have to compare those to public hashes and then have to hope that someone out there has a hash that happens to be a part of that attack. Not impossible of course, but how feasible even if computers were 100 times faster in 10 years?\n\n[edit] ok, re-read what you wrote, the public key is generated from the private key, not independently. So just finding a weak public key is the issue."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5743#msg5743"},{"f":"satoshi","d":1280090881,"b":[["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.","Quote"],["t","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.\n\nBitcoin Addresses are the only place where 160-bit hash is used.  Everything else is SHA-256.  They're calculated as:\n\nbitcoinaddress = RIPEMD-160(SHA-256(publickey))\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5754#msg5754","s":1,"n":272,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/272/"},{"f":"Red","d":1280091841,"b":[["q","bitcoinaddress = RIPEMD-160(SHA-256(publickey))\n\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.","Quote from: satoshi on July 25, 2010, 08:48:01 PM"],["t","I think you are correct on the analytical attack. At least a far as I understand (minimally) the mathematical genius that is analyzing them.\n\nI was worried it was the simpler:\n\nbitcoinaddress = RIPEMD-160(publickey)"]],"u":"https://bitcointalk.org/index.php?topic=571.msg5757#msg5757"},{"f":"Red","d":1280092751,"b":[["t","So the way I read it.\n\nGiven two numbers p and q. Which for RSA are supposed to be large primes.\n\nThen n = p*q\n\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.\n\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\n\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\n(That is the point where I could be totally off base though. Really interested, if a crypto geek knows better than me.)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5764#msg5764"},{"f":"satoshi","d":1280096856,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=571.msg5778#msg5778","s":1,"n":277,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/277/"}]},{"id":"p135","k":"p","s":"bitcointalk","t":"Bitcoin x86 for Windows","u":"https://bitcointalk.org/index.php?topic=572","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/135/","m":[{"f":"Olipro","d":1280132240,"b":[["t","Figured I'd make a new topic since anyone on x86 Windows probably won't even bother to read the x64 thread, however, since you're here, I suggest you read page 5 of that thread after reading this.\n\nOK, so essentially I've compiled 2 builds of Bitcoin with the new SHA caching optimisation, one build has full optimisation for the SSE instruction sets and will require a modern CPU, and the other is compiled without any SSE optimisation at all and should therefore run on pretty much any CPU capable of running XP or higher. The SSE version is a bit faster than the non-SSE version and both are inferior to the x64 builds, if you have a 64-bit OS, don't bother with these.\n\nBeware however that the libeay32.dll that I included may have SSE and therefore, if you can't get either to run on your machine, replace that DLL with the one bundled with the stock Bitcoin\n\nYou can grab the builds here <http://www.4shared.com/file/kIewrXzp/Bitcoin_x86.html>"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5823#msg5823"},{"f":"FreeMoney","d":1280144894,"b":[["t","Amazing. ~1250 up to ~2200.\n\nIs this for real? Other machine from ~600 to ~1350"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5836#msg5836"},{"f":"BlackEye","d":1280146361,"b":[["t","I don't see the source code included with any of your builds.  It would be great to be able to independently verify and compile the sources."]],"u":"https://bitcointalk.org/index.php?topic=572.msg5840#msg5840"},{"f":"Olipro","d":1280146425,"b":[["q","I don't see the source code included with any of your builds.  It would be great to be able to independently verify and compile the sources.","Quote from: BlackEye on July 26, 2010, 12:12:41 PM"],["t","If you don't trust my builds, don't use them, if you want to set up your own build environment, do the work yourself, all the source code in the app is publically available."]],"u":"https://bitcointalk.org/index.php?topic=572.msg5841#msg5841"},{"f":"BlackEye","d":1280147907,"b":[["t","No need to be hostile.  I do have a build environment set up, but I am completely unable to compile your changes without your source code.  This just sends up a big red flag for me as you've obviously modified the source for some of your builds and are unwilling to provide those changes for peer review.  I think this goes against the spirit of open source.  Modified binary only releases don't help progress the software and create an unnecessary dependency on an individual to provide those binaries."]],"u":"https://bitcointalk.org/index.php?topic=572.msg5843#msg5843"},{"f":"Olipro","d":1280149481,"b":[["q","No need to be hostile.  I do have a build environment set up, but I am completely unable to compile your changes without your source code.  This just sends up a big red flag for me as you've obviously modified the source for some of your builds and are unwilling to provide those changes for peer review.  I think this goes against the spirit of open source.  Modified binary only releases don't help progress the software and create an unnecessary dependency on an individual to provide those binaries.","Quote from: BlackEye on July 26, 2010, 12:38:27 PM"],["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5851#msg5851"},{"f":"knightmb","d":1280153721,"b":[["t","Thanks for thinking about those still on the 32bit chips  Grin"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5865#msg5865"},{"f":"sgtstein","d":1280154505,"b":[["t","Or those with servers stuck on 32-bit OSes. :-D\nQuad core Xeon@1.6GHz <mailto:Xeon@1.6GHz>\nStock: 1100kh/s\nFull Opt: 2600kh/s\n\nTHANKS!"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5869#msg5869"},{"f":"BitCoinPurse","d":1280156007,"b":[["t","More than doubled my khash/sec from 800 to 1900.\n\nAMD Phenon II X2 550"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5874#msg5874"},{"f":"Olipro","d":1280158921,"b":[["q","Or those with servers stuck on 32-bit OSes. :-D\nQuad core Xeon@1.6GHz <mailto:Xeon@1.6GHz>\nStock: 1100kh/s\nFull Opt: 2600kh/s\n\nTHANKS!","Quote from: sgtstein on July 26, 2010, 02:28:25 PM"],["t","BitCoins are always appreciated, address in my sig"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5886#msg5886"},{"f":"satoshi","d":1280194182,"b":[["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)","Quote from: Olipro on July 26, 2010, 01:04:41 PM"],["t","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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5978#msg5978","s":1,"n":280,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/280/"},{"f":"knightmb","d":1280196071,"b":[["q","> Quote from: sgtstein on July 26, 2010, 02:28:25 PM\n> Or those with servers stuck on 32-bit OSes. :-D\n> Quad core Xeon@1.6GHz <mailto:Xeon@1.6GHz>\n> Stock: 1100kh/s\n> Full Opt: 2600kh/s\n>\n> THANKS!\n\nBitCoins are always appreciated, address in my sig","Quote from: Olipro on July 26, 2010, 03:42:01 PM"],["t","I just sent you a wad of coin  Wink"]],"u":"https://bitcointalk.org/index.php?topic=572.msg5982#msg5982"},{"f":"dkaparis","d":1280224746,"b":[["q","I 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?","Quote from: satoshi on July 27, 2010, 01:29:42 AM"],["t","I recently also made an attempt to use Crypto++ 5.6.0 (as an external library) instead of the old integrated code, with the same result - it crashed on the first invocation of CryptoPP::SHA256::Transform. Only I built everything with VC++ 2008. I haven't investigated in depth, but someone mentioned Crypto++'s routine required aligned input - maybe that's the reason, or we may have other bug we don't figure."]],"u":"https://bitcointalk.org/index.php?topic=572.msg6014#msg6014"},{"f":"BlackEye","d":1280234615,"b":[["t","You need to change the assembly instructions that require aligned input to unaligned - http://bitcointalk.org/index.php?topic=453.msg5774#msg5774, or make the blocks that are being hashed aligned.  I haven't tried yet, but this assembly code combined with the state caching modification should make this blazing fast."]],"u":"https://bitcointalk.org/index.php?topic=572.msg6030#msg6030"},{"f":"satoshi","d":1280255250,"b":[["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.\n\nI think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now.","Quote from: BlackEye on July 25, 2010, 10:12:23 PM"],["t","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.\n\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.\n\nI guess it's using SSE2.  It automatically sets its build configuration at compile time based on the compiler environment.\n\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.\n\nThis is SVN rev 114."]],"u":"https://bitcointalk.org/index.php?topic=572.msg6069#msg6069","s":1,"n":282,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/282/"},{"f":"knightmb","d":1280255763,"b":[["q","...\nI guess it's using SSE2.  It automatically sets its build configuration at compile time based on the compiler environment.\n\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 do 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.","Quote from: satoshi on July 27, 2010, 06:27:30 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=572.msg6071#msg6071"},{"f":"satoshi","d":1280260062,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=572.msg6083#msg6083","s":1,"n":283,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/283/"}]},{"id":"p136","k":"p","s":"bitcointalk","t":"bitcoind without wxWidgets","u":"https://bitcointalk.org/index.php?topic=576","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/136/","m":[{"f":"satoshi","d":1280165013,"b":[["t","I replaced the last of the few wxBase dependencies in bitcoind.\n\nbitcoind now compiles without wxWidgets or wxBase in SVN rev 112.\n\nmain(int argc, char* argv[]) is added to init.cpp.  CMyApp and the Startup folder stuff are moved to ui.cpp.  ui.cpp and uibase.cpp aren't linked by bitcoind.\n\nThe makefiles have -DGUI to control whether the GUI is used.\n\nI test compiled MinGW, VC and Ubuntu.  I don't know if I broke the Mac OSX build, someone will need to check that."]],"u":"https://bitcointalk.org/index.php?topic=576.msg5904#msg5904","s":1,"n":278,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/278/"}]},{"id":"p137","k":"p","s":"bitcointalk","t":"Bitcoin does NOT violate Mises' Regression Theorem","u":"https://bitcointalk.org/index.php?topic=583","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/137/","m":[{"f":"xc","d":1280196567,"b":[["t","The Money Regression and Emergence of Money from the Barter Economy\nThe entire purpose of the regression theorem was to help explain an apparent paradox of money: how does money have value as a medium of exchange if it is valued because it serves as a medium of exchange?  Menger and Mises helped break this apparent circularity by explaining the essential time component missing from the phrasing of the paradox.\n\nAs Rothbard explains in Man, Economy, and State (p 270),\n\"...a money price at the end of day X is determined by the marginal utilities of money and the good as they existed at the beginning of day X. But the marginal utility of money is based, as we have seen above, on a previously existing array of money prices. Money is demanded and considered useful because of its already existing money prices. Therefore, the price of a good on day X is determined by the marginal utility of the good on day X and the marginal utility of money on day X, which last in turn depends on the prices of goods on day X – 1. The economic analysis of money prices is therefore not circular. If prices today depend on the marginal utility of money today, the latter is dependent on money prices yesterday.\" [all emphasis added]\n\nRothbard then goes on to explain that in order for money to emerge from a barter economy, it must have a preexisting commodity value.  This commodity value arises from barter demand for the potential money in direct consumption (i.e. ornamentation).  This value seeds future estimations of the value of the money as a medium of exchange.  The natural market emergence of money is thus fully explained.\n\nThe Monetary Economy\nHowever, once an economy has been monetized and a memory of price ratios for goods and services has been established, a money may lose its direct commodity value and still be used as a money (medium of indirect exchange).  Rothbard explains (p 275):\n\"On the other hand, it does not follow from this analysis that if an extant money were to lose its direct uses, it could no longer be used as money. Thus, if gold, after being established as money, were suddenly to lose its value in ornaments or industrial uses, it would not necessarily lose its character as a money. Once a medium of exchange has been established as a money, money prices continue to be set. If on day X gold loses its direct uses, there will still be previously existing money prices that had been established on day X – 1, and these prices form the basis for the marginal utility of gold on day X. Similarly, the money prices thereby determined on day X form the basis for the marginal utility of money on day X + 1. From X on, gold could be demanded for its exchange value alone, and not at all for its direct use. Therefore, while it is absolutely necessary that a money originate as a commodity with direct uses, it is not absolutely necessary that the direct uses continue after the money has been established.\"\n\nThis explains the history of fiat currencies.  They originally started off as simple names for weights of commodity money (silver) that developed out of the pre-monetary barter economy.  Despite later losing their ties to direct commodity value through state interference, paper currency retained status as money because of memory of previous money prices.  This factor is so strong that the relationship between gold and the USD, for example, is somewhat inverted.  Gold no longer circulates as a common medium of exchange.   Prices are set in USD, not in gold.  Most individuals wishing to trade in gold do so based on their knowledge of USD/gold price ratios.  (\"Hey, let me buy that $100 couch from you in gold?\"  \"Ok, USD/gold is $1000/oz. Give me 1/10oz of gold.\")  Legal tender laws, state taxation, and the entire financial regulatory environment maintain this inertia of USD prices and make it challenging to return to gold money directly, despite the destructive inflationary nature of fiat currencies.\n\nThe Emergence of the Bitcoin Economy\nThe very first businesses in the Bitcoin economy were exchangers (NewLibertyStandard, BitcoinMarket, BitcoinExchange,....).  This is not an accident, but flows from the analysis above.  In order for Bitcoins to serve as a medium of exchange without commodity value for uses besides indirect exchange, there must be a translated knowledge of money prices.  Market exchangers fill this gap and give Bitcoin users access to this knowledge.  Bitcoins may therefore currently serve as a money intermediary for paypal dollars\\pecunix\\euros.  But why is there demand for Bitcoin over USD??  This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.\n\nThe essential point is that once exchange can occur between a money (USD) and Bitcoins, providers of goods have a means by which to value Bitcoins as a potential medium of exchange.  The money regression is satisfied, because taken back far enough we reach traditional commodity money: BITCOINS -> USD -> MONETIZED GOLD & SILVER [start monetary economy] -> [end barter economy] COMMODITY GOLD & SILVER.  \n\nOf course, if a major meltdown occurred and knowledge of all price ratios was wiped out, Bitcoin probably would NOT directly emerge as a money (assuming Bitcoins have limited value outside of exchange).  Fiat currencies with zero direct barter value certainly would not.  Commodities such as gold and silver that have widely recognized direct value in barter would likely emerge first.  The economy would then be monetized with price ratios in gold and silver.  Bitcoins then, being valued for intrinsic properties amenable to exchange, might then become prevalent in trade.  Initially, creators of value would continue to make their price value ratios in terms of the true money (gold oz/BTC ratio), but with time Bitcoin prices (BTC) can emerge (see vekja.net as example).  We are in this initial phase now.  \n\nTherefore, so long as exchange of BTC and USD/Euros/etc… occurs, knowledge of existing price ratios can be utilized in the Bitcoin economy.  In time as Bitcoins become increasingly marketable, these fiat<->BTC price ratios will seed direct BTC price ratios.  The Bitcoin Economy thus emerges.  The Misean regression theorem is satisfied.\n\nXC\n\nedit: clarified possibility of direct emergence of bitcoin as money from barter economy."]],"u":"https://bitcointalk.org/index.php?topic=583.msg5984#msg5984"},{"f":"kiba","d":1280203516,"b":[["t","YOU WIN 20 BTC!  Grin\n\nNow all I need is your address for you to claim Kiba's AWESOME POST prize.\n\nEdit: got it."]],"u":"https://bitcointalk.org/index.php?topic=583.msg5997#msg5997"},{"f":"Red","d":1280204794,"b":[["t","Yes, quite an impressive analysis! Alas I have no coins to send.\n\nWhy is there no PPC build for the Mac? I really need new hardware."]],"u":"https://bitcointalk.org/index.php?topic=583.msg6001#msg6001"},{"f":"Anonymous","d":1280224876,"b":[["t","Excellent economic breakdown.\n\nA hash cookie for you!"]],"u":"https://bitcointalk.org/index.php?topic=583.msg6015#msg6015"},{"f":"joechip","d":1280253988,"b":[["t","Excellent breakdown.  That helps satisfy my worries about the process by which one type of money can supplant another.  I have not read Man, Economy and State (though I really should) and therefore, missed that portion of Rothbard's analysis. \n\nThanks again.\n\nTa,"]],"u":"https://bitcointalk.org/index.php?topic=583.msg6065#msg6065"},{"f":"hugolp","d":1281094754,"b":[["q","But why is there demand for Bitcoin over USD??  This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.","Quote from: xc on July 27, 2010, 02:09:27 AM"],["t","Exactly this. Bitcoins have value because they offer some qualities, and some people value them. Also, I would add ideological value."]],"u":"https://bitcointalk.org/index.php?topic=583.msg7839#msg7839"},{"f":"Anonymous","d":1281150865,"b":[["q","> Quote from: xc on July 27, 2010, 02:09:27 AM\n> But why is there demand for Bitcoin over USD??  This is a subjective valuation arising from properties such as anonymity, decentralized system of clearance, cryptographic trust, predetermined and defined rate of growth, built in deflation, divisibility, low transaction fees, etc.... inherent to the Bitcoin system.\n\nExactly this. Bitcoins have value because they offer some qualities, and some people value them. Also, I would add ideological value.","Quote from: hugolp on August 06, 2010, 11:39:14 AM"],["t","What if someone wants to buy something and they dont want it showing on their credit card statement? Bitcoins are the ultimate thing for it. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=583.msg8042#msg8042"},{"f":"aurelian","d":1282371871,"b":[["t","The simpler answer is that Rothbard is wrong here.   Not a statement about Rothbard in general, but on this particular point he's off.  There need be no preexisting \"direct\" value for money, where the value of money itself is artificially deemed as of some second-class \"indirect\" sort.   The value of a commodity _as money_, because it more securely scarce (and portable, hard to steal, etc.) than an alternative commodity, is quite sufficient to make it valuable as money and thus to get it going as money.    Enabling exchange, i.e. lowering transaction costs, is a form of economically useful consumption just as much as satisfying hunger, decoration, or some other \"direct\" use is a form of economic consumption.    In the same way, a stock exchange doesn't have to satisfy your hunger or make a good decoration or have any other \"direct consumption\" value, it just has to be good at exchanging stocks.\n\nThis is well explained here (interestingly enough by the guy who originally came up with the bit gold idea):\nhttp://szabo.best.vwh.net/shell.html"]],"u":"https://bitcointalk.org/index.php?topic=583.msg10552#msg10552"},{"f":"FreeMoney","d":1282373316,"b":[["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=583.msg10553#msg10553"},{"f":"satoshi","d":1282930327,"b":[["t","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\n\nand one special, magical property:\n- can be transported over a communications channel\n\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.\n\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.\n\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\n(I'm using the word scarce here to only mean limited potential supply)"]],"u":"https://bitcointalk.org/index.php?topic=583.msg11405#msg11405","s":1,"n":428,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/428/","qt":["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\n\nand one special, magical property:\n- can be transported over a communications channel\n\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.\n\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.\n\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\n(I'm using the word scarce here to only mean limited potential supply)"],"qc":["economics"]}]},{"id":"p138","k":"p","s":"bitcointalk","t":"Difficulty","u":"https://bitcointalk.org/index.php?topic=587","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/138/","m":[{"f":"mizerydearia","d":1280225511,"b":[["t","http://nullvoid.org/bitcoin/difficultiez.php"],["c","<?\n header(\"Content-type: text/html\");\n require_once 'jsonRPCClient.php';\n $data=new jsonRPCClient('http://127.0.0.1:8332');\n $blockcount = $data->getblockcount();\n $now = date(\"U\");\n $blockfile = \"blockdata\";\n $data = file($blockfile, FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES); array_pop($data);\n?><html>\n <head>\n  <meta http-equiv=\"refresh\" content=\"100000\">\n </head>\n <body>\n  <pre>\n<?\n function humantime($secs) {\n  if ($secs<0) return false;\n  $m = (int)($secs / 60); $s = $secs % 60; $s = ($s <= 9) ? \"0$s\" : $s;\n  $h = (int)($m / 60); $m = $m % 60; $m = ($m <= 9) ? \"0$m\" : $m;\n  $d = (int)($h / 24); $h = $h % 24; $h = ($h <= 9) ? \"0$h\" : $h;\n  $d = ($d <= 9) ? \"0$d\" : $d;\n  return $d.\"d $h:$m:$s\";\n }\n\n // Converted from ArtForz's python code http://bitcointalk.org/index.php?topic=464.msg4080#msg4080\n function uint256_from_compact($c) {\n  $nbytes = ($c >> 24) & 0xFF;\n  return bcmul($c & 0xFFFFFF,bcpow(2,8 * ($nbytes - 3)));\n }\n\n $tblock = 0;\n $nTargetTimespan = 60 * 60 * 24 * 14;\n bcscale(256);\n foreach ($data as $line) {\n  $blocks = strtok($line, \" \");\n  $date = strtok(\" \");\n  $avghash = strtok(\" \");\n  $bits = strtok(\" \");\n  if ($blocks == 0 || $blocks == $tblock) {\n   $tblock = $blocks + 2016;\n   $blocknum = str_repeat(\" \", 6 - strlen($blocks)).$blocks;\n   echo \"Block $blocknum was generated at $date (\".date(\"r\", $date).\")\";\n   if ($blocks != 0) {\n    $intervalnum = $date - $lastdate;\n    $interval = str_repeat(\" \", 9 - strlen($intervalnum)).$intervalnum;\n    echo \"    $interval seconds interval (\".humantime($intervalnum).\")\";\n    echo \"   Difficulty: \".bcdiv(bcdiv(bcmul(uint256_from_compact(0x1D00FFFF),1000), uint256_from_compact($bits)), 1000);\n    $lastdate = $date;\n   }\n   echo \"<br>\";\n  }\n }\n?>\n  </pre>\n </body>\n</html>"]],"u":"https://bitcointalk.org/index.php?topic=587.msg6018#msg6018"},{"f":"mpkomara","d":1280241162,"b":[["t","nice precision! latest difficulty = 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 17840402922938076799906\n  "]],"u":"https://bitcointalk.org/index.php?topic=587.msg6036#msg6036"},{"f":"mizerydearia","d":1280242324,"b":[["t","Hehe, thanks. I could provide more accurate precision, but I think that is good enough."]],"u":"https://bitcointalk.org/index.php?topic=587.msg6040#msg6040"},{"f":"Insti","d":1280245503,"b":[["t","I'm just thankful the difficulty isn't 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 17840402922938076799907\n\nJust imagine how hard it would be to win a block then!!!!!"]],"u":"https://bitcointalk.org/index.php?topic=587.msg6048#msg6048"},{"f":"mizerydearia","d":1280277091,"b":[["t","Actually, calculating with another digit comes out to 244.213223092375323881335701184896212407930361873708113773326734402748260502489 1554339282075169582811726687822061777635447902413461818393548574922122914786456 6654051064077556842993973623686279076537890477160907158869253835628402573582928 178404029229380767999068 and thus could be rounded up to the value you suggested Insti."]],"u":"https://bitcointalk.org/index.php?topic=587.msg6122#msg6122"},{"f":"mizerydearia","d":1280281468,"b":[["t","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)."],["c"," -7017 seconds to find block 70719\n  8153 seconds to find block 70718\n    49 seconds to find block 70717\n   524 seconds to find block 70716"],["c","block timestamp\n70715 1280275621\n70716 1280276145\n70717 1280276194\n70718 1280284347\n70719 1280277330"],["t","This 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."]],"u":"https://bitcointalk.org/index.php?topic=587.msg6130#msg6130"},{"f":"satoshi","d":1280366183,"b":[["t","You were looking at the wrong code.  Here's the code that applies:"],["c","bool CBlock::CheckBlock() const\n{\n...\n    // Check timestamp\n    if (nTime > GetAdjustedTime() + 2 * 60 * 60)\n        return error(\"CheckBlock() : block timestamp too far in the future\");\n...\n\nbool CBlock::AcceptBlock()\n{\n   ...\n    // Check timestamp against prev\n    if (nTime <= pindexPrev->GetMedianTimePast())\n        return error(\"AcceptBlock() : block's timestamp is too early\");"],["t","The 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."]],"u":"https://bitcointalk.org/index.php?topic=587.msg6301#msg6301","s":1,"n":286,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/286/"}]},{"id":"p139","k":"p","s":"bitcointalk","t":"Running on a port other than 8333","u":"https://bitcointalk.org/index.php?topic=589","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/139/","m":[{"f":"Gavin Andresen","d":1280239697,"b":[["t","I've been working on adding -port= / -rpcport=  command line / config file options to bitcoin.  The idea is to let you run multiple copies of bitcoind on one machine; I need this because I'm planning on having at least two Bitcoin-related web services (the Bitcoin Faucet and a service to be named later), I want them to have completely separate wallets, but I don't want to rent multiple servers to host them.\n\nUsage looks like this:"],["c","$ ./bitcoind getbalance  # The TEST network Faucet bitcoind\n40616.66159265000\n$ ./bitcoind -datadir=/home/bitcoin/.bitcoinTEST2 getbalance\n1000.000000000000\n$ cat /home/bitcoin/.bitcoinTEST2/bitcoin.conf\nrpcpassword=.....\nport=18666\nrpcport=18665"],["t","Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database.  To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes).\n\nIssues that came up as I was doing this:\n\nI left a call to wxSingleInstanceChecker in the Windows GUI code, so no multiple-gui-bitcoins-listening-on-different-ports on Windows.  I don't do Windows...\n\nI didn't bother making the error handling graceful if you point two bitcoins at the same datadir (you get a runtime exception \"Cannot lock db.log, is bitcoin already running?\").\n\nPatches are at http://pastebin.com/2e4hfXSS; I've only tested on Linux so far, anybody willing to try this on Windows?"]],"u":"https://bitcointalk.org/index.php?topic=589.msg6034#msg6034"},{"f":"NewLibertyStandard","d":1280241743,"b":[["t","If I was a C++ programmer, I would make multiple instances of Bitcoin automatically talk to each other. But then again, I don't know how hard it is to do cross platform interprocess communication. If a data directory was already being used by one instance, then the new instance would be required to use a different data directory. Sure, you probably can make multiple instances share some or all the files in a data directory, but I think it's a bad idea since it the likelihood for little bugs is high, but the likelihood of the likelihood of those being discovered, researched, reported and fixed is low since the feature wouldn't get much exposure. Imagine the mess it will make if somebody starts half a dozen instances. Shocked"]],"u":"https://bitcointalk.org/index.php?topic=589.msg6038#msg6038"},{"f":"mizerydearia","d":1280242426,"b":[["q","Satoshi pointed out that allowing bitcoin/bitcoind to run on a non-standard port could be dangerous, because if misconfigured two bitcoins might both open and write to the same database.  To prevent that, the <datadir>/db.log file is used as a lock so only one bitcoin can access the same datadir at a time (uses boost::interprocess::file_lock, which is purported to be cross-platform and well-behaved, even if bitcoin crashes).","Quote from: gavinandresen on July 27, 2010, 02:08:17 PM"],["t","Additionally you could run each client as a different system user."]],"u":"https://bitcointalk.org/index.php?topic=589.msg6041#msg6041"},{"f":"agaumoney","d":1280257215,"b":[["q","I've been working on adding -port= / -rpcport=  command line / config file options to bitcoin","Quote from: gavinandresen on July 27, 2010, 02:08:17 PM"],["t","Nice.  In addition it would be good to have an -ip= option for what address to bind the port.  (rpcport binds to 127.0.0.1 but currently port binds to 0.0.0.0 which is all IP addresses on the machine.  On my multi-homed system I'd like to bind bitcoin to the external address different from the bitcoin(s) that binds to the internal address(es).)"]],"u":"https://bitcointalk.org/index.php?topic=589.msg6078#msg6078"},{"f":"lachesis","d":1281453895,"b":[["t","Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests."]],"u":"https://bitcointalk.org/index.php?topic=589.msg8544#msg8544"},{"f":"jgarzik","d":1281460035,"b":[["q","Do you have an updated version of this patch for SVN revision 125? Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.","Quote from: lachesis on August 10, 2010, 03:24:55 PM"],["t","It does open with DB_PRIVATE.\n\nhttp://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/C/envopen.html"]],"u":"https://bitcointalk.org/index.php?topic=589.msg8552#msg8552"},{"f":"satoshi","d":1284313220,"b":[["q","Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock?It does not -- did my own tests.","Quote from: lachesis on August 10, 2010, 03:24:55 PM"],["t","Is there a way to open BerkeleyDB exclusive?\n\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.\n\nI've dropped the DB_PRIVATE flag in rev 153."]],"u":"https://bitcointalk.org/index.php?topic=589.msg12483#msg12483","s":1,"n":449,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/449/"}]},{"id":"p140","k":"p","s":"bitcointalk","t":"Having problems specifing -datadir","u":"https://bitcointalk.org/index.php?topic=601","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/140/","m":[{"f":"psyvenrix","d":1280324280,"b":[["t","Whilst not amazingly critical, i find it strange that i consistently get the below error messages from the console and debug.log when i try to specify the datadir option with anything other than the period char (current directory).\nThis is using the bitcoind program on an archlinux terminal session, im not using the GUI at all (headless box accessed via ssh)\n\nFrom Console:\n************************\nEXCEPTION: 22DbRunRecoveryException\nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery\nbitcoin in AppInit()\n\nterminate called after throwing an instance of 'DbRunRecoveryException'\n  what():  DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery\n\nand from the debug.log inside the datadir : -\n\nBitcoin version 0.3.4.0 beta\nDefault data directory /home/psyvenrix/.bitcoin\nBound to port 8333\nLoading addresses...\ndbenv.open strLogDir=./datadir2/database strErrorFile=./datadir2/db.log\n\n************************\nEXCEPTION: 22DbRunRecoveryException\nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery\nbitcoin in AppInit()\n\nYes, that is a SVN build, as the tar.gz from the main site is linked against openssl ver 0.9.8 i think and my arch linux system has 1.0.0 i think, so i just grabed the latest SVN source and built that (aside from a makefile tweak it compiled ok).\n\nive checked the permissions on both the directory containing the binaries and the aforementioned datadir, all are writable by my login (& no other ACL/SELinux trickery in the background either)\n\nI have only just started using bitcoin, so i find it strange that it's throwing a recovery type error when the contents of that directory are freshly generated (i.e. i can rm -rf the lot, then start bitcoind with a new non-existent directory, watch it create the files needed then bomb out)\n\nThoughts anyone? Huh"]],"u":"https://bitcointalk.org/index.php?topic=601.msg6188#msg6188"},{"f":"Gavin Andresen","d":1280324457,"b":[["t","Does it work if you specify the full path?  e.g. -datadir=/home/psyvenrix/datadir2  ?"]],"u":"https://bitcointalk.org/index.php?topic=601.msg6190#msg6190"},{"f":"satoshi","d":1280350706,"b":[["t","It was able to reproduce this.  The database doesn't like the relative path.\n\n\"bitcoind -datadir=./subdir getinfo\" works against a running daemon, but trying to start the daemon as \"bitcoind -datadir=./subdir\" gets that exception.\n\nI guess we should resolve the full path before passing it to the database.\n\nIt looks like you were the first one to ever use -datadir with a relative path."]],"u":"https://bitcointalk.org/index.php?topic=601.msg6268#msg6268","s":1,"n":284,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/284/"},{"f":"Tilka","d":1280992056,"b":[["t","+1 for quick bug fix. I'd like to be able to do that, too."]],"u":"https://bitcointalk.org/index.php?topic=601.msg7644#msg7644"},{"f":"lachesis","d":1281549523,"b":[["q","It was able to reproduce this.  The database doesn't like the relative path.\n\n\"bitcoind -datadir=./subdir getinfo\" works against a running daemon, but trying to start the daemon as \"bitcoind -datadir=./subdir\" gets that exception.\n\nI guess we should resolve the full path before passing it to the database.\n\nIt looks like you were the first one to ever use -datadir with a relative path.","Quote from: satoshi on July 28, 2010, 08:58:26 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=601.msg8773#msg8773"},{"f":"satoshi","d":1281649409,"b":[["t","Fixed in SVN rev 130."]],"u":"https://bitcointalk.org/index.php?topic=601.msg8924#msg8924","s":1,"n":351,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/351/"}]},{"id":"p141","k":"p","s":"bitcointalk","t":"Build error SVN r115 on my Mac: workaround","u":"https://bitcointalk.org/index.php?topic=604","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/141/","m":[{"f":"Gavin Andresen","d":1280330305,"b":[["t","I get:"],["c","/var/folders/n7/n7Do3Krz2RWPeE+1YxvhUU+++TM/-Tmp-//cc8PgHsQ.s:879:suffix or operands invalid for `call'"],["t","... compiling cryptopp/sha.cpp (latest SVN source) on my Mac (gcc version 4.2.1).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=604.msg6206#msg6206"},{"f":"satoshi","d":1280352203,"b":[["t","Was that the only thing I broke in the OSX build?!  Does it actually work after just that one change?\n\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.\n\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.\n\nThe Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).\n\nI uploaded this makefile.osx change to SVN.  (let me know if that compiles now)"]],"u":"https://bitcointalk.org/index.php?topic=604.msg6273#msg6273","s":1,"n":285,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/285/"}]},{"id":"p142","k":"p","s":"bitcointalk","t":"[PATCH] implement 'xlisttransactions'","u":"https://bitcointalk.org/index.php?topic=611","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/142/","m":[{"f":"jgarzik","d":1280363693,"b":[["t","Here is a patch against SVN 117, implementing 'xlisttransactions' RPC: http://pastebin.ca/1910553   At present, the options are ignored, and it dumps all transactions it finds.\n\nRaw patch: http://pastebin.ca/raw/1910553\n\nEdit: Patch's current home is http://yyz.us/bitcoin/patch.bitcoin-listtransactions\n\nEdit2: RPC command has been renamed to 'xlisttransactions'"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6295#msg6295"},{"f":"jgarzik","d":1280364514,"b":[["t","Here's an updated version, that sorts by number of confirmations:  http://pastebin.ca/1910564\n\nRaw patch:  http://pastebin.ca/raw/1910564"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6297#msg6297","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280372424,"b":[["t","OK, here's version 4.  Output now matches what you see in the UI, and gives you information on debits/credit/generated/etc.  The 'count' and 'includegenerated' parameters are now honored.\n\nPatch: http://pastebin.ca/1910623\nRaw patch: http://pastebin.ca/raw/1910623\n\nHere's sample output from my dev box:"],["c","$ /usr/local/src/bitcoin/bitcoind -datadir=/usr/local/bitcoin/data listtransactions\n[\n    {\n        \"address\" : \"15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5\",\n        \"label\" : \"\",\n        \"class\" : \"credit\",\n        \"amount\" : 0.02000000000000000,\n        \"confirmations\" : 160\n    },\n    {\n        \"address\" : \"15uyjNbNzizz5r8UgWpF1ZayV82Pq3FHQ5\",\n        \"label\" : \"\",\n        \"class\" : \"credit\",\n        \"amount\" : 0.01000000000000000,\n        \"confirmations\" : 162\n    },\n    {\n        \"address\" : \"1GKgKYtV79jYHR2mr1SSDp9EjXQuLTmUTw\",\n        \"label\" : \"\",\n        \"class\" : \"debit\",\n        \"amount\" : 0.02000000000000000,\n        \"confirmations\" : 1525\n    },\n    {\n        \"address\" : \"191ALqREPdXCGE6mhfS7HqRZCeQB2AHT6y\",\n        \"label\" : \"\",\n        \"class\" : \"credit\",\n        \"amount\" : 0.02000000000000000,\n        \"confirmations\" : 1531\n    },\n    {\n        \"address\" : \"1HVYQQ5K489fMx5Aqt48M5oTJPsmUhrpkx\",\n        \"label\" : \"\",\n        \"class\" : \"debit\",\n        \"amount\" : 0.01000000000000000,\n        \"confirmations\" : 1572\n    },\n    {\n        \"address\" : \"1KTpPjGWyhTBC5NNYFwNzkyjW6UDL9jKPG\",\n        \"label\" : \"Your Address\",\n        \"class\" : \"credit\",\n        \"amount\" : 0.01000000000000000,\n        \"confirmations\" : 1587\n    }\n]"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6309#msg6309","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280438526,"b":[["t","Added a couple small cleanups, and verified it still works under 0.3.6 / SVN r119.\n\nVersion 5 of listtransactions: http://pastebin.ca/1911295\nRaw patch: http://pastebin.ca/raw/1911295\n\nFAQ:\n\nQ1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?\n\nA1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves...  the output changes accordingly."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6491#msg6491","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"lachesis","d":1280443129,"b":[["t","Very nice! Send Satoshi an email and ask him to add it to trunk.\n\nBy the way, anyone having trouble applying this on unix can use:"],["c","curl http://pastebin.ca/raw/1911295 | awk 'sub(\"$\", \"\r\")' | patch"],["t","That'll make the line endings on the removed parts match the Windows line endings in the code files."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6525#msg6525","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280443526,"b":[["q","Very nice! Send Satoshi an email and ask him to add it to trunk.","Quote from: lachesis on July 29, 2010, 10:38:49 PM"],["t","He is welcome to pick it up now.\n\nBut I didn't want to push the patch to him until the two FIXME's are resolved.  Those FIXMEs are for 0.01% cases, but still..."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6530#msg6530","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"lachesis","d":1280443980,"b":[["t","Could you make count=0 return all transactions?"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6532#msg6532","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280444569,"b":[["q","Could you make count=0 return all transactions?","Quote from: lachesis on July 29, 2010, 10:53:00 PM"],["t","Returning all transactions is pretty easy, sure.\n\nI wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified.  ie.  make your \"count=0\" the default."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6537#msg6537","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"lachesis","d":1280451063,"b":[["q","I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified.  ie.  make your \"count=0\" the default.","Quote from: jgarzik on July 29, 2010, 11:02:49 PM"],["t","Perhaps. In that case, you should switch the order of includegenerated and count. Perhaps even make includegenerated true? Generations are included by default in the UI, after all."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6559#msg6559","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280468663,"b":[["t","Version 6 of listtransactions: http://pastebin.ca/1911570\nRaw patch: http://pastebin.ca/raw/1911570\n\nlisttransactions implementation should be complete at this point.  The following command syntax is used:"],["c","listtransactions [count=10] [minconf=1] [includegenerated=true]"],["t","As lachesis suggested, count=0 will dump all transactions.\n\nFAQ:\n\nQ1) How does 'listtransactions' behave if tail of the block chain changes, eg. 0 confirmations -> 1 confirmation -> 0 confirmations?\n\nA1) 'listtransactions' behaves the same way 'listreceivedbyaddress' behaves...  the output changes accordingly."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6602#msg6602","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"Gavin Andresen","d":1280495886,"b":[["t","Couple of quick suggestions:\n\nUsing the key name \"class\" will cause problems for, at least, JavaScript, and probably other languages where \"class\" is a reserved word.  \"type\" or \"variety\" or some other synonym will cause fewer problems later.\n\nOr, maybe better, get rid of that field and just report credits as positive numbers and debits as negative.  And add a separate \"generated\" field (boolean true or false).\n\nSince each entry refers to a transaction, I'd suggest adding a \"tx_id\" SHA256 hex-encoded transaction id.  Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).\n\nCode to get that would look something like:"],["c","            uint256 tx_hash = transaction.GetHash();\n            string tx_id = tx_hash.GetHex();\n            mapJSONResponse.push_back(Pair(\"tx_id\", tx_id));"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6642#msg6642","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280514640,"b":[["q","Couple of quick suggestions:\n\nUsing the key name \"class\" will cause problems for, at least, JavaScript, and probably other languages where \"class\" is a reserved word.  \"type\" or \"variety\" or some other synonym will cause fewer problems later.","Quote from: gavinandresen on July 30, 2010, 01:18:06 PM"],["t","Can you be more specific?  All mainstream programming language seem sensibly insensitive to abitrary string contents, JS included.  String content can certainly include language-reserved keywords and parsing tokens."],["q","Since each entry refers to a transaction, I'd suggest adding a \"tx_id\" SHA256 hex-encoded transaction id.  Then listtransactions would play nicely with the refundtransaction JSON-RPC extension (and maybe a future gettransactiondetails that let you get transaction parents, which block the transaction was in, and so on).\n\nCode to get that would look something like:\n\n            uint256 tx_hash = transaction.GetHash();\n            string tx_id = tx_hash.GetHex();\n            mapJSONResponse.push_back(Pair(\"tx_id\", tx_id));","Quote from: gavinandresen on July 30, 2010, 01:18:06 PM"],["t","Added, thanks for the suggestion."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6687#msg6687","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"jgarzik","d":1280515417,"b":[["t","Here is 'listtransaction' version 7:\nhttp://gtf.org/garzik/bitcoin/patch.bitcoin-listtransactions\n\nThis adds the suggested txn_id field -- very nice suggestion, gavin!  I wanted a unique transaction id, and now I have one Smiley"]],"u":"https://bitcointalk.org/index.php?topic=611.msg6694#msg6694","sj":"Re: [PATCH] implement 'listtransactions'"},{"f":"satoshi","d":1280518854,"b":[["t","What are you needing to use listtransactions for?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=611.msg6706#msg6706","s":1,"n":299,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/299/","sj":"Re: [PATCH] implement 'listtransactions'"}]},{"id":"p143","k":"p","s":"bitcointalk","t":"Linux distribution download","u":"https://bitcointalk.org/index.php?topic=612","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/143/","m":[{"f":"Odin","d":1280373757,"b":[["t","Hi,\n\nI am a software developer and while I am well versed with building things on Linux I thought I might provide some pointers to making like easier for others.\n\nThere is one aspect with distributing a single download package for Linux that is dynamically linked, \"You should use the oldest versions of glibc/libstdc++ you can get away with.  i.e. unless you know you need a new feature or a bug fix take is as a given that the libraries at runtime will be newer and contain those fixes.\"\n\nThe problem with linking against the bleeding edge versions of glibc/libstdc++ is that you force the users to have a bleeding edge system also (to run these binaries).  Which should not be a necessary pre-requisite unless you know of specific cause for it to be so.  Such causes should be explained in documentation. Where as if you simply linked on an older system it would work both on that older system and on the bleeding edge system.\n\nIf there are areas of C code which you really-really need some new and recent GCC optimization to be enabled, consider providing the dumped out ASM file *.s which you generate once from your bleeding edge GCC version but include in the source to allow anyone to complile (even on older GCC versions).\n\nHere are some recomendations:\n * Use the oldest base distribution you can get away with to build the binaries.  For example the most recent copy of the _PREVIOUS_ release of debian.  Not the most update to date copy of the current release of debian.\n * Provide a download containing static binaries (use the \"-static\" option to linking and maybe add this so the name of the executables \"bitcoind-static\"). Provide this in a seperate download file.\n * Make the source distribution build work from working copies of the libraries they need.  In particular boost and wxWidgets, if you know you need very recent versions of these to build against, then make building and linking work right out of their respective build tree (so you don't have to install them).  Installing them in /usr/local maybe an issue (it certainly is for me) but having themin the current working directory just for bitcoin's use would be fine.  At the end of the day all bincoin needs is access to header filer and DSOs or *.a to build and access to the DSOs at runtime.\n\nI can put a 24/7 headless bitcoind up but because of these issues, until I find/make time to resolve them I can not at this time."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6312#msg6312"},{"f":"Odin","d":1280375050,"b":[["t","Sorry to post to my own post.\n\nOne possible solution would be to create a project on the OpenSUSE OBS platform http://wiki.meego.com/Build_Infrastructure .\n\nThis platform is an auto-builder anyone can use (by creating your own account and home area).\n\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.\n\nThe result will be a *.deb or *.rpm or whatever your platform uses."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6317#msg6317"},{"f":"satoshi","d":1280441844,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6516#msg6516","s":1,"n":296,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/296/"},{"f":"Odin","d":1280445015,"b":[["q","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.","Quote from: satoshi on July 29, 2010, 10:17:24 PM"],["t","Fair enough.  I've not found any version of bitcoin that works with any enterprise version of Linux I have found.  Often enterprise linux uses older tried and trusted versions several years old.  This has parity with the LTS series of Ubuntu.\n\nI think you'd be better doing your distribution with http://releases.ubuntu.com/hardy/  (8.04.4 LTS Hardy Heron).  If you really must use Ubuntu.  This being the _PREVIOUS_ release of their LTS series, once 10.4 LTS passes the 18months old test consider a release engineering rebase.\n\nMaybe you can setup a 2Gb \"8.04.4 LTS\" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6540#msg6540"},{"f":"jgarzik","d":1280445774,"b":[["q","Maybe you can setup a 2Gb \"8.04.4 LTS\" disk image using VirtualBox or Xen (just for rolling releases) and keep whatever version you want for desktop/development use.","Quote from: Odin on July 29, 2010, 11:10:15 PM"],["t","Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.\n\nConstantly reformatting your main dev machine is for the birds Smiley\n\nI have to support OpenSolaris and FreeBSD in my cloud computing project, in addition to the primary target, Linux.  Virtual machines are a life-saver (and cost-saver)."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6545#msg6545"},{"f":"Odin","d":1280449486,"b":[["q","Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.","Quote from: jgarzik on July 29, 2010, 11:22:54 PM"],["t","Just to clear up any (potential) misconception, from the use of the phrase \"for older distro support\".  Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way.\n\nWhen they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries.  Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC.\n\nI am somewhat asserting that, if it is indeed possible to compile with older versions (because the features the newer versions add are not actually required by the application) then this version that should be made available via a single binary download (since it will work with the widest audience).\n\nAlso to repeat, that the OpenSUSE Build Service is like a remote virtualized service which you can use compile your application on multiple major distributions and the output is a bunch of packages tailored to suit each distro.\n\nThe clear problem I see is not with the support for aux lbiraries (Xlib,GTK+,OpenSSL,freetype) but with basic GLIBC and GCC libstdc++.  The problem with this is that you can't expect to simply place the DLLs you need in the same directory as the bitcoin executable and fix up LD_LIBRARY_PATH (man ld.so) so it can see them.\n\nFor example lets say that it was compiled with an older GTK+ than is available for your distribution of choice (a DSO major release change, this is indicated in the 2nd \"0\" in the /usr/lib{,64}/libgtk+-x11-2.0.so.0.1800.9) - note it is still zero, this indicates long term stability re-backward compatibility.  Well it is possible to easily fix this problem without installing the libraries by fixing them up with LD_LIBRARY_PATH.  But for glibc solving the problem in this way is not so straightforward."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6554#msg6554"},{"f":"Odin","d":1280449570,"b":[["q","Make him a virtual box container and upload it or mail him a disk. Then all he needs to do is install vbox and run it.","Quote from: davidonpda on July 29, 2010, 11:40:06 PM"],["t","Google found me http://virtualboxes.org/images/ubuntu/\n\nMaybe head for item 3 for http://downloads.sourceforge.net/virtualboximage/ubuntu-8.04-x86.7z (505Mb download, for a 2.67Gb uncompressed image)"]],"u":"https://bitcointalk.org/index.php?topic=612.msg6555#msg6555"},{"f":"jgarzik","d":1280455557,"b":[["q","> Quote from: jgarzik on July 29, 2010, 11:22:54 PM\n> Yeah, some sort of virtual machine like qemu/KVM is really the best way to go, for older distro support.\n\nJust to clear up any (potential) misconception, from the use of the phrase \"for older distro support\".  Just because you compiled your application with an older distro doesn't mean it doesn't work on a newer distro many libraries are backwardly compatible in that way.\n\nWhen they do change major DSO version (incompatible or breaking changes) some distributions still provide the ability to install the older compat libraries.  Its easier for a new distro to find older compat libraries than it is for an older distro to use a newer GLIBC.","Quote from: Odin on July 30, 2010, 12:24:46 AM"],["t","Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs.  Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version.  That practice makes glibc the primary compatibility worry."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6579#msg6579"},{"f":"Odin","d":1280538240,"b":[["q","Most of what you say is true, but, bitcoin tends to be built against very specific versions of its dependent libs.  Due to that, one tends to build bitcoin against custom compiled libs, regardless of underlying OS version.  That practice makes glibc the primary compatibility worry.","Quote from: jgarzik on July 30, 2010, 02:05:57 AM"],["t","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).\n\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.\n\nI believe this can be confirmed by the use of -Bstatic in \"src/makefile.unix\".\n\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.\n\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...).\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6758#msg6758"},{"f":"satoshi","d":1280587132,"b":[["t","It can be built with Boost 1.37 or later."]],"u":"https://bitcointalk.org/index.php?topic=612.msg6822#msg6822","s":1,"n":304,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/304/"}]},{"id":"p144","k":"p","s":"bitcointalk","t":"Transaction disappeared in the void...","u":"https://bitcointalk.org/index.php?topic=615","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/144/","m":[{"f":"Brre","d":1280402433,"b":[["t","I did a transaction about 2 hours ago and it is staying at 0/unconfirmed, the recipient has no credit showing or even an unconfirmed line... The coins seems to disapeared in the void...\nShould I wait is this just a transaction that is going to take exceptionally long?"]],"u":"https://bitcointalk.org/index.php?topic=615.msg6361#msg6361"},{"f":"Quantumplation","d":1280406823,"b":[["t","The transaction will be accepted into a solved block if the person who solves said block chooses to incorporate your transaction into his solution.  That means it needs to propagate across the network.  Is your \"Connections\" greater than 0?"]],"u":"https://bitcointalk.org/index.php?topic=615.msg6371#msg6371"},{"f":"Brre","d":1280409197,"b":[["t","Yep 4 connections...\nI just restarted.\nWas the transaction not sent for some reason, is there a way to force the client to rebroadcast the transaction... if there is some glitch/bug?"]],"u":"https://bitcointalk.org/index.php?topic=615.msg6376#msg6376"},{"f":"FreeMoney","d":1280411317,"b":[["t","If your client says 0/unconfirmed then afaik that means it knows that it needs to continue to be broadcast until it gets into a block. I don't know why it would take 2 hours though, maybe someone else knows. Do you normally only have 4 connections?"]],"u":"https://bitcointalk.org/index.php?topic=615.msg6385#msg6385"},{"f":"Quantumplation","d":1280413244,"b":[["t","Brre: Your client will relentlessly broadcast that transaction into infinity until it's accepted.  It's VERY persistent.\n\nA block just probably hasn't been solved in two hours.  The difficulty's up there, I know that."]],"u":"https://bitcointalk.org/index.php?topic=615.msg6392#msg6392"},{"f":"knightmb","d":1280416812,"b":[["t","Yeah, a block is being solved every 10 minutes or less, it shouldn't take 2 hours unless the client has somehow lost connection to the rest of the network."]],"u":"https://bitcointalk.org/index.php?topic=615.msg6404#msg6404"},{"f":"Gavin Andresen","d":1280420915,"b":[["q","I did a transaction about 2 hours ago and it is staying at 0/unconfirmed, the recipient has no credit showing or even an unconfirmed line... The coins seems to disapeared in the void...\nShould I wait is this just a transaction that is going to take exceptionally long?","Quote from: Brre on July 29, 2010, 11:20:33 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=615.msg6418#msg6418"},{"f":"satoshi","d":1280441311,"b":[["t","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.\n\nI'll shorten that length of time in a future version.\n\nYou do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms.  Same with the recipient."]],"u":"https://bitcointalk.org/index.php?topic=615.msg6512#msg6512","s":1,"n":295,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/295/"}]},{"id":"p145","k":"p","s":"bitcointalk","t":"*** ALERT *** Upgrade to 0.3.6","u":"https://bitcointalk.org/index.php?topic=626","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/145/","m":[{"f":"satoshi","d":1280430786,"b":[["t","Please upgrade to 0.3.6 ASAP!  We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted.  Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6!\n\nIf you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.\n\nAlso in 0.3.6, faster hashing:\n- midstate cache optimisation thanks to tcatm\n- Crypto++ ASM SHA-256 thanks to BlackEye\nTotal generating speedup 2.4x faster.\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.6/\n\nWindows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6451#msg6451","s":1,"n":289,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/289/"},{"f":"Olipro","d":1280431538,"b":[["t","is this in the SVN?"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6453#msg6453","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"knightmb","d":1280431599,"b":[["t","I appreciate the quickness of this security update, but unfortunately none of the Linux builds work (32bit or 64 bit) because the file is missing. I'm assuming if I go find the file it will work, not sure what luck others will have though using the new build.\n\nError"],["c","./bitcoin: error while loading shared libraries: libjpeg.so.62: cannot open shared object file: No such file or directory"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6455#msg6455","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"andy_3_913","d":1280431842,"b":[["t","are satoshi and Olipro working together?\nif not, any chance you could? Smiley\n\ni'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6457#msg6457","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"jgarzik","d":1280431857,"b":[["q","Please upgrade to 0.3.5 ASAP!  We fixed an implementation bug where it was possible that bogus transactions could be accepted.  Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.5!","Quote from: satoshi on July 29, 2010, 07:13:06 PM"],["t","Like Olipro, got a lot of people doing custom builds out there -- in fact, I must use a custom build on several machines.\n\nMay we assume SVN has all necessary updates?"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6458#msg6458","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"knightmb","d":1280432062,"b":[["q","are satoshi and Olipro working together?\nif not, any chance you could? Smiley\n\ni'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!","Quote from: andy_3_913 on July 29, 2010, 07:30:42 PM"],["t","So far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6459#msg6459","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"Bitquux","d":1280432386,"b":[["q","> Quote from: andy_3_913 on July 29, 2010, 07:30:42 PM\n> are satoshi and Olipro working together?\n> if not, any chance you could? Smiley\n>\n> i'm well pleased with the speed enhancements Olipro is making, but i would like bc to be secure!\nSo far, the new build (stock) has given a 100% speed increase on my Celeron Machines that couldn't run those custom builds before. I'll compare the new release to the older *optimized* builds to see what the speed difference is just out of curiosity.  Grin","Quote from: knightmb on July 29, 2010, 07:34:22 PM"],["t","So far I'm seeing a comparable hashing rate to the most recent of the Olipro 32-bit binaries. It might even be slightly faster."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6461#msg6461","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"jgarzik","d":1280432535,"b":[["t","With the official Linux-64bit build, run on Fedora 13, I see it failing badly:"],["c","************************\nEXCEPTION: 22DbRunRecoveryException       \nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       \nbitcoin in AppInit()       \n\n************************\nEXCEPTION: 22DbRunRecoveryException       \nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       \nbitcoin in CMyApp::OnUnhandledException()       \n\nterminate called after throwing an instance of 'DbRunRecoveryException'\n  what():  DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery"],["t","Praying my bitcoins aren't eaten..."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6462#msg6462","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"knightmb","d":1280432857,"b":[["q","With the official Linux-64bit build, run on Fedora 13, I see it failing badly:\n\n************************\nEXCEPTION: 22DbRunRecoveryException       \nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       \nbitcoin in AppInit()       \n\n************************\nEXCEPTION: 22DbRunRecoveryException       \nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       \nbitcoin in CMyApp::OnUnhandledException()       \n\nterminate called after throwing an instance of 'DbRunRecoveryException'\n  what():  DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery\n\nPraying my bitcoins aren't eaten...","Quote from: jgarzik on July 29, 2010, 07:42:15 PM"],["t","I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release  Wink"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6464#msg6464","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"jgarzik","d":1280432972,"b":[["q","With the official Linux-64bit build, run on Fedora 13, I see it failing badly:","Quote from: jgarzik on July 29, 2010, 07:42:15 PM"],["t","Same result on another machine.  BDB errors, and death.  0.3.5 on 64bit Linux is questionable.  You didn't mix up the builds with 32-bit Linux, did you?\n\ndebug.log says:"],["c","Bitcoin version 0.3.5 beta\nDefault data directory /g/g/.bitcoin\nBound to port 8333\nLoading addresses...\ndbenv.open strLogDir=/garz/bitcoin/data/database strErrorFile=/garz/bitcoin/data/db.log\n\n************************\nEXCEPTION: 22DbRunRecoveryException      \nDbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery      \nbitcoin in AppInit()      "]],"u":"https://bitcointalk.org/index.php?topic=626.msg6465#msg6465","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"jgarzik","d":1280433165,"b":[["q","I think you'll be ok, it blew up on me too. Run the older version, you should still see all your coins. Backup first for the next Linux release  Wink","Quote from: knightmb on July 29, 2010, 07:47:37 PM"],["t","Double-ACK Smiley\n\nolder version (SVN 117 + listtransactions + getinfo KHPS) works fine, all bitcoins there.  And yes, I should back up before following \"please upgrade\" instructions...   Smiley"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6467#msg6467","sj":"Re: *** ALERT *** Upgrade to 0.3.5 ASAP"},{"f":"knightmb","d":1280433267,"b":[["q","Can windows users upgrade to the 3.5 for now?","Quote from: davidonpda on July 29, 2010, 07:51:38 PM"],["t","Yes, I've tested on Windows XP, 2003, and 7 all went through just fine. You'll enjoy the speed increase as well.  Wink\n\n[err, wait I guess, new version about to spawn]"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6468#msg6468","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"satoshi","d":1280433351,"b":[["t","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.  "]],"u":"https://bitcointalk.org/index.php?topic=626.msg6469#msg6469","s":1,"n":290,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/290/","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"satoshi","d":1280435415,"b":[["t","SVN is updated with version 0.3.6.\n\nUploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6480#msg6480","s":1,"n":291,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/291/","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"RudeDude","d":1280435754,"b":[["t","Ha! One of the changes in there is updated some v \"0.3.3\" stuff to \"0.3.6\" but that isn't the important part of the update. :-)"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6485#msg6485","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"jgarzik","d":1280436515,"b":[["t","SVN r119 seems to work fine here.  No BDB explosion."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6486#msg6486","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"knightmb","d":1280436689,"b":[["t","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.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6487#msg6487","sj":"Re: *** ALERT *** version 0.3.6"},{"f":"satoshi","d":1280438438,"b":[["t","0.3.6 Linux build is back to the old makefile.unix.  It static links libjpeg so that shouldn't be a problem.\n\nIs that working better?\n\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*\n\nWindows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6490#msg6490","s":1,"n":292,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/292/","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280438601,"b":[["t","Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?\n\n64bit Client Error, will try out 32bit client and see if the error is similar."],["c","./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)"],["t","The machine I tested this on uses nothing but the stock builds, no modified builds were used prior.\n\nSame error for 32bit client"],["c","./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)"],["t","Linux - Mandriva 2010.0 [64bit and 32bit] OS systems setup"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6492#msg6492","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"bitcoinex","d":1280438835,"b":[["t","0.3.6 binaries for linux works fine on two my machines (64 and 32 bits) with Debian squeeze/sid"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6493#msg6493","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280438935,"b":[["q","0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)","Quote from: bitcoinex on July 29, 2010, 09:27:15 PM"],["t","That's good to know, might just need to update mine, checking to see what versions I have currently installed."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6494#msg6494","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"dwdollar","d":1280438981,"b":[["q","Still a no go on the Linux build though, this is the console error I get. I checked to make sure the file was there, but the versions don't match I guess?\n\n64bit Client Error, will try out 32bit client and see if the error is similar.\n\n./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)\n\nThe machine I tested this on uses nothing but the stock builds, no modified builds were used prior.\n\nSame error for 32bit client\n\n./bitcoin: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)","Quote from: knightmb on July 29, 2010, 09:23:21 PM"],["t","I'm getting this too on 32-bit Ubuntu 9.10.\n\nIt works fine on 32-bit and 64-bit Ubuntu 10.04."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6495#msg6495","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"jgarzik","d":1280439008,"b":[["q","0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)","Quote from: bitcoinex on July 29, 2010, 09:27:15 PM"],["t","If you (and others) are willing, please post your OS + OS version, when posting success/failure reports.\n\nI will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds)."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6497#msg6497","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280439024,"b":[["t","Ah, mine is linked to 2.10.1, I'll bring my system up to bleeding edge to see if that solves it  Grin\n\n[edit] Well turns out I can't package wise as they top out at 2.10 for now"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6498#msg6498","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280439167,"b":[["q","> Quote from: bitcoinex on July 29, 2010, 09:27:15 PM\n> 0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)\n\nIf you (and others) are willing, please post your OS + OS version, when posting success/failure reports.\n\nI will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).","Quote from: jgarzik on July 29, 2010, 09:30:08 PM"],["t","I would agree, would help those of us not on the bleeding edge of distro packages.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6499#msg6499","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"bitcoinex","d":1280439327,"b":[["q","> Quote from: bitcoinex on July 29, 2010, 09:27:15 PM\n> 0.3.6 binaries for linux works fine on two my machines (64 and 32 bits)\n\nIf you (and others) are willing, please post your OS + OS version, when posting success/failure reports.\n\nI will echo a recommendation to satoshi from another forum member:  build linux binaries on an older Linux OS, to ensure wider compatibility.  Maybe something as old as CentOS 5 (caveat: requires custom openssl, boost, db4 and wx builds).","Quote from: jgarzik on July 29, 2010, 09:30:08 PM"],["t","sorry. I'm checked binaries on Debian GNU/Linux squeeze/sid"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6500#msg6500","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"satoshi","d":1280439795,"b":[["t","\"./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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6502#msg6502","s":1,"n":293,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/293/","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"The Madhatter","d":1280439842,"b":[["t","v0.3.6 works on FreeBSD/i386 7.2,7.3 and on FreeBSD/amd64 8.0\n\nCompiles cleanly without any warnings, and appears to be working fine."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6503#msg6503","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Odin","d":1280439906,"b":[["t","Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.\n\nGetting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6504#msg6504","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"SmokeTooMuch","d":1280440061,"b":[["t","0.3.6 works great on Win7 Pro 64-Bit."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6505#msg6505","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Gooffy","d":1280441294,"b":[["t","Ubuntu Linux 9.10\n\nError:\n\n/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found       Cry "]],"u":"https://bitcointalk.org/index.php?topic=626.msg6511#msg6511","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"bitcoinex","d":1280441475,"b":[["q","Ubuntu Linux 9.10\n\nError:\n\n/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found       Cry","Quote from: WMFrend on July 29, 2010, 10:08:14 PM"],["t","$ dpkg -l|grep -i glibc\nii  libdb1-compat                            2.1.3-9                         The Berkeley database routines [glibc 2.0/2.\n\n?"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6514#msg6514","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"lachesis","d":1280441676,"b":[["t","On Debian testing 32-bit, I get a few build errors, all resembling:"],["c","script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope"],["t","I 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.\n\nIf anyone else gets this error, the simplest solution is to \"make clean\" and retry the build."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6515#msg6515","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"dwdollar","d":1280444028,"b":[["q","\"./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.\n\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.","Quote from: satoshi on July 29, 2010, 09:43:15 PM"],["t","That's strange, 0.3.3 worked fine on it.  It's no biggie, I need to upgrade that machine anyway."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6533#msg6533","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Odin","d":1280444235,"b":[["q","Ubuntu Linux 9.10\n\nError:\n\n/lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found       Cry ","Quote from: WMFrend on July 29, 2010, 10:08:14 PM"],["t","dpkg -l | egrep \"(libc6|glibc)\"\n# This will display what version you currently have installed\n\n# I guess you have glibc version 2.10 or older installed.\n\napt-get update\napt-cache showpkg libc6 | less\n# Look (near the bottom) for the versions available for a 2.11 version\n\n#Maybe you can just upgrade with:\napt-get upgrade libc6\n\n# Above instruction for a real debian system, they might work with Ubuntu"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6534#msg6534","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"satoshi","d":1280445132,"b":[["q","On Debian testing 32-bit, I get a few build errors, all resembling:\n\nscript.cpp:114: error: ‘OP_NOP1’ was not declared in this scope\nI 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.\n\nIf anyone else gets this error, the simplest solution is to \"make clean\" and retry the build.","Quote from: lachesis on July 29, 2010, 10:14:36 PM"],["t","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.\n\nDamn that GLIBC_2.11.  I thought I'd been careful not to accept any of the updates."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6542#msg6542","s":1,"n":297,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/297/","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280449647,"b":[["q","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.\n\nDamn that GLIBC_2.11.  I thought I'd been careful not to accept any of the updates.","Quote from: satoshi on July 29, 2010, 11:12:12 PM"],["t","I was going to compile a GLIBC_2.10 version until I noticed that I had to keep installing more and more to get through the check errors, LOL. Looks like I just need to fire up a Virtual Box with all the dev packages loaded to do this in a virtual machine to make life easier."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6556#msg6556","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"bytemaster","d":1280451940,"b":[["t","Could someone help me understand why it matters that hashing is 2x faster?  If everyone were to upgrade the coin inflation rate would still remain the same.  Thus there is a \"slight\" advantage to early adopters.  I guess some could say it gives \"honest nodes\" more time and thus makes it even harder for dishonest nodes to gain an edge.\n\nThe #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy.  So I would think we would want to focus on aspects other than \"generation speed\" first."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6566#msg6566","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280453148,"b":[["q","Could someone help me understand why it matters that hashing is 2x faster?  If everyone were to upgrade the coin inflation rate would still remain the same.  Thus there is a \"slight\" advantage to early adopters.  I guess some could say it gives \"honest nodes\" more time and thus makes it even harder for dishonest nodes to gain an edge.\n\nThe #1 aspect if a currency is divisibility and fixed supply and the relative value of the coins will adjust automatically relative to the supply of goods available to buy.  So I would think we would want to focus on aspects other than \"generation speed\" first.","Quote from: bytemaster on July 30, 2010, 01:05:40 AM"],["t","Quite simply to level the playing field for coin generation and to help maintain block generation at a stable rate. If everyone was limited to just 100 khash/s by the client, someone would just compile a client that does not have the limit and load it up on a server farm where they could generate 10,000 khash/s per machine. It would put the coin generation supply in the hands of who ever had a large amount of money to invest in servers and discourage everyone else from trying to mint coin. If we could trust that clients would only act as transaction nodes and that everyone would get a fair shot at coin generation then no one would care if the client was generating at 5 khash/s all the time.\n\nSo in a perfect world, no one would care that they can generate 2 or 3 times faster than someone else, but we don't live in a perfect world.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6572#msg6572","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Anonymous","d":1280469094,"b":[["t","My khash rate went from 700 to 1700.Sweet!"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6603#msg6603","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Cdecker","d":1280498036,"b":[["q","Maybe the points listed in http://bitcointalk.org/index.php?topic=612.0 would help making the Linux binary distribution works for the widest audience.\n\nGetting the project to build under the OpenSUSE OBS service should allow the maintainer to get distribution specific compliation for free.","Quote from: Odin on July 29, 2010, 09:45:06 PM"],["t","Great point. I got the bitcoind (without the wx GUI) compiling for Ubuntu 10.04 Cheesy\n\nI'll try to get the other version to work too, but it's quite annoying that BC needs such a new version of libdb and wx...\n\nhttps://build.opensuse.org/package/show?package=bitcoind&project=home:cdecker"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6645#msg6645","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"BitLex","d":1280498545,"b":[["t","0.3.6 up and running on w2k/xp32/xp64/w7\n\nnice speed-updates on all systems,\nguess we can prepare for another major step up in difficulty, now that all nodes do 2-3times the hashes they did before.\nis that a good or a bad thing?"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6648#msg6648","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"m0mchil","d":1280499368,"b":[["t","Fastest possible stock build removes any advantage other 'special' builds would have. Which is good because generation will be more uniformly distributed. It's important for the official build to be always the fastest available. It should use any known optimization (including CUDA, OpenCL, ability to work on the Cell proc etc).\n\nThe one and only effect for now - another difficulty adjustment, still same chance to generate until more users/cores came in."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6653#msg6653","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"andy_3_913","d":1280505891,"b":[["t","would an auto-update function built into bc be possible?"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6667#msg6667","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"HostFat","d":1280508565,"b":[["q","would an auto-update function built into bc be possible?","Quote from: andy_3_913 on July 30, 2010, 04:04:51 PM"],["t","It's something that I have already suggested here :|\nhttp://bitcointalk.org/index.php?topic=259.0"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6673#msg6673","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"andy_3_913","d":1280508672,"b":[["q","> Quote from: andy_3_913 on July 30, 2010, 04:04:51 PM\n> would an auto-update function built into bc be possible?\nIt's something that I have already suggested here :|\nhttp://bitcointalk.org/index.php?topic=259.0","Quote from: Joozero on July 30, 2010, 04:49:25 PM"],["t","sorry! Smiley"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6674#msg6674","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"Cdecker","d":1280515199,"b":[["t","32Bit and 64Bit versions for Ubuntu 10.04 are available on the openSuse Build Service: https://www.bitcoin.org/smf/index.php?topic=644.0"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6693#msg6693"},{"f":"knightmb","d":1280517847,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6702#msg6702","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"satoshi","d":1280519586,"b":[["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.","Quote from: knightmb on July 30, 2010, 07:24:07 PM"],["t","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:\n\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)\n\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\n\nadded a comment in makefile.unix:\n\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"]],"u":"https://bitcointalk.org/index.php?topic=626.msg6711#msg6711","s":1,"n":300,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/300/","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"knightmb","d":1280520259,"b":[["q","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:\n\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)","Quote from: satoshi on July 30, 2010, 07:53:06 PM"],["t","That part I highlighted is what got me. You can't install all the libboost packages with that command (I tried to cheat with a * also), but part of my issue is I took it too literal like install *everything* that had to do with libboost, LOL.\n\nReally, all that was needed was the libboost1.37-dev package and that made all the compile errors go away. Everything else worked out just fine as far as compiling your own wxWidgets, compiling Boost 1.4, etc.\n\nSo that last command should simply be\nsudo apt-get install libboost1.37-dev\n\nOn a side note, I compiled mine on a Ubuntu 64bit system, so the finished program came out 64bit aware. I'm testing it out on some 64bit systems to see how well things go."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6713#msg6713","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"},{"f":"satoshi","d":1280526244,"b":[["q","So that last command should simply be\nsudo apt-get install libboost1.37-dev","Quote from: knightmb on July 30, 2010, 08:04:19 PM"],["t","Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.\n\nSeems they changed everything around in Boost recently, \"-mt\" and all that, makes it hard.\n\nBTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.\n\nMac OSX version is available now.  See bitcoin.org or the SourceForge link."]],"u":"https://bitcointalk.org/index.php?topic=626.msg6728#msg6728","s":1,"n":301,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/301/","sj":"Re: *** ALERT *** Upgrade to 0.3.6 ASAP!"}]},{"id":"p146","k":"p","s":"bitcointalk","t":"Implementation bug prior to 0.3.6","u":"https://bitcointalk.org/index.php?topic=628","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/146/","m":[{"f":"Anonymous","d":1280433787,"b":[["t","adg"]],"u":"https://bitcointalk.org/index.php?topic=628.msg6470#msg6470","sj":"sg"},{"f":"knightmb","d":1280434322,"b":[["t","In this forum, I don't see why not. Basically, the implementation bug means that the client wasn't following it's own rules. Someone may have found a way to double-spend coin for example that the Client doesn't catch because of how it processes the rules to counter this kind of action."]],"u":"https://bitcointalk.org/index.php?topic=628.msg6472#msg6472"},{"f":"jgarzik","d":1280434334,"b":[["q","Is it too early to discuss what happened until more users upgrade?","Quote from: davidonpda on July 29, 2010, 08:03:07 PM"],["t","I am interested in the meta-discussion, about security policy.\n\nIn other open source projects, representatives of \"key parties\" tend to gather on a \"vendor security\" mailing list that is closed to the public.  Vulnerabilities that might have real world consequences are discussed there, and then a coordinated release occurs, where all key players publish the security fixes at the same time."]],"u":"https://bitcointalk.org/index.php?topic=628.msg6473#msg6473"},{"f":"knightmb","d":1280434437,"b":[["t","Since we mostly communicate by forum here, the closest would be a member group that has access to a special forum here just for that issue that the public can't normally see. I'm fairly certain the simple machines forum supports that feature?"]],"u":"https://bitcointalk.org/index.php?topic=628.msg6474#msg6474"},{"f":"knightmb","d":1280434756,"b":[["q","I'd support the idea. More trusted members and programmers could post security risks or exploits. Maybe the better way is just to message the developer if they are discovered.","Quote from: davidonpda on July 29, 2010, 08:17:31 PM"],["t","Both can work, but a members forum would help to keep out the noise; otherwise everyone will end up messaging the lead developer with every possible thing they here in the news and end up taking his/her time to filter it out on whether it's really a risk or not."]],"u":"https://bitcointalk.org/index.php?topic=628.msg6476#msg6476"},{"f":"jgarzik","d":1280434979,"b":[["t","BTW, an important feature of these mailing lists is that anyone can post...  but only the \"vendor security\" group can read the posts.\n\nThus, it is easy for an outsider with a real security issue to provide detailed information to vendor-sec@myopensourceproject.org <mailto:vendor-sec@myopensourceproject.org>, while preventing unscrupulous people from reading the sensitive information.\n\nI suppose a PM to <somebody>, plus discussion on a closed forum, is the best this forum software can handle."]],"u":"https://bitcointalk.org/index.php?topic=628.msg6478#msg6478"},{"f":"satoshi","d":1280441055,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=628.msg6508#msg6508","s":1,"n":294,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/294/","qt":["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."],"qc":["bitcoin-design"]}]},{"id":"p147","k":"p","s":"bitcointalk","t":"Protocol Buffers for Bitcoin","u":"https://bitcointalk.org/index.php?topic=632","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/147/","m":[{"f":"martin","d":1280446171,"b":[["t","There has been a discussion going on elsewhere <http://bitcointalk.org/index.php?topic=557.msg5789#msg5789> about using protocol buffers for bitcoin. To summarise the advantages:\n\n-> Small encoding\n-> Very fast\n-> Implementations in loads of languages (So writing new clients become a lot simpler)\n-> Forwards compatible (indeed, this is most of the point of protocol buffers)\n-> Extremely simpleto use in code\n\nSo initially I would suggest storing the wallet file using protocol buffers, this isn't a breaking change and immediately makes the wallet file easier for other programs to parse. Eventually I would hope that bitcoin could use protocol buffers for networking.\n\nSome people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers. To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6547#msg6547"},{"f":"lachesis","d":1280451846,"b":[["q","Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.","Quote from: martin on July 29, 2010, 11:29:31 PM"],["t","I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like."],["q","To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?","Quote from: martin on July 29, 2010, 11:29:31 PM"],["t","That would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully:\nhttp://bitcointalk.org/index.php?topic=231.msg6250#msg6250"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6565#msg6565"},{"f":"martin","d":1280474995,"b":[["q","> Quote from: martin on July 29, 2010, 11:29:31 PM\n> Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.\nI agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.","Quote from: lachesis on July 30, 2010, 01:04:06 AM"],["t","That too, although the counter argument people always make to that is that we could do away with reserved bytes anyway. No matter how impractical that would be :/"],["q","> Quote from: martin on July 29, 2010, 11:29:31 PM\n> To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?\nThat would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully:\nhttp://bitcointalk.org/index.php?topic=231.msg6250#msg6250","Quote from: lachesis on July 30, 2010, 01:04:06 AM"],["t","I was hoping for a transaction packet or something, but I'll give it a go with that for now. I could also test with the wallet file if anyone has decoded that?\n\nAddendum:\n\nOk, Working from this summary of the version packet layout:"],["q","version\n    * {0xf9,0xbe,0xb4,0xd9}\n    * \"version\" (0x00 padded)\n    * 4 byte message size\n    * 4 byte checksum\n    * 8 byte nLocalServices (always 1 if !fClient, no idea either what that means)\n    * 8 byte timestamp (remember to use network byte order)\n    * Remote address (the address this Node thinks he is):\n          o nServices - uint64 (8b), still cryptic, don't know the meaning yet\n          o pchReserved - (12b): some reserved space, apparently for later IPv6\n          o ip - uint (4b)\n          o port - unsigned short (2b)\n    * Local address (the address this Node sees you under):\n          o nServices - uint64 (8b), still cryptic, don't know the meaning yet\n          o pchReserved - (12b): some reserved space, apparently for later IPv6\n          o ip - uint (4b)\n          o port - unsigned short (2b)\n    * 8 byte nLocalHostNonce (needed for a handshake, if I'm not mistaken)\n    * A subversion string \".0\" in my case\n    * nBestHeight - int (4b): appears to be the last block number","Quote"],["t","I created this protocol buffer definition:"],["q","message version\n{\n   message AddressInfo\n   {\n      required unint64 nServices;\n      required fixed32 ip;\n      required uint32 port;\n   }\n\n   required uint32 magic = 2045;         //0xf9 | 0xbe << 1 | 0xb4 << 2 | 0xd9 << 3\n   required uint32 version;\n   required int64 checksum;\n   required uint64 timestamp;\n        required uint64 nLocalServices;\n\n   required AddressInfo Remote;      //the address this node thinks he is\n   required AddressInfo Local;      //the address this node sees you under\n\n   required fixed64 nLocalHostNonce;\n   required string SubversionString;\n   required uint32 nBestHeight;\n}","Quote"],["t","Does that look correct? The only changes I've made are that the indented things in the bullet point list are nested message types, and I've completely dropped the 12 bytes of reserved ipv6 space (since that can easily be added in later, which is the point of protocol buffers). I should point out that I probbaly haven't picked the best encoding types for all these fields, that depends upon the values they're likely to store, so in practice the packet will probably be a little smaller than my tests indicate"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6622#msg6622"},{"f":"martin","d":1280489879,"b":[["t","I used the above protocol buffer (as I said before, it's probably not optimal) and data obtained via http://www.alloscomp.com/bitcoin/version.pys as test data."],["q","Version: 306\nnLocalServices: 1\nnTime: 1280487684\naddrYou: #.#.#.#:#### (nServices: 1)\naddrMe: #.#.#.#:#### (nServices: 1)\nnLocalHostNonce: 2359069617775922941\nvSubStr: \"\"\nnBestHeight: 71137","Quote"],["t","The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is over half the size of the hand built layout!"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6636#msg6636"},{"f":"Quantumplation","d":1280493023,"b":[["q","> Quote from: martin on July 29, 2010, 11:29:31 PM\n> Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.\nI agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like.","Quote from: lachesis on July 30, 2010, 01:04:06 AM"],["t","Not only does it allow it to drop reserved fields, but it uses ZigZag encoding and some other tricks to keep integers and the like as absolutely small as possible.  So yea, it uses clever encoding. =P  It's also blazingly fast to process!"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6637#msg6637"},{"f":"RHorning","d":1280499207,"b":[["q","The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is half the size of the hand built layout!","Quote from: martin on July 30, 2010, 11:37:59 AM"],["t","I realize that you are evangelizing for protocol buffers (and you seem to be doing a very good job of it too, I might add), but I will challenge that hand built data layouts are always bad.\n\nStill, I hope this does give some food for thought and on a practical basis any improvement in the network protocol that shaves off a few bytes is always better.  This doesn't seem to sacrifice too much in terms of the overhead either.  More significantly, you are calling attention to an area of efficiency that needs to be addressed and is very helpful to the project.  Thank you for doing that.  I'm hoping to get caught up to where you are at now on this protocol business."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6650#msg6650"},{"f":"Gavin Andresen","d":1280500103,"b":[["t","Speaking of the network...\n... is there any really robust, generic, low-latency, open source p2p network \"middleware\" out there?\n\nI think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers \"buys\" enough to be worth the effort (at least not now, when transaction volume is low).\n\nI'd like to see some experimenting with running bitcoin on top of a different networking layer (and use protocol buffers, too).  Is there a p2p network that is designed to be extremely highly reliable and difficult to infiltrate or attack with malicious nodes?"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6656#msg6656"},{"f":"jgarzik","d":1280504853,"b":[["t","FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet.  Packets are padded up to 60 bytes, if they are smaller."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6664#msg6664"},{"f":"martin","d":1280508867,"b":[["q","> Quote from: martin on July 30, 2010, 11:37:59 AM\n> The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is half the size of the hand built layout!\n\nI realize that you are evangelizing for protocol buffers (and you seem to be doing a very good job of it too, I might add), but I will challenge that hand built data layouts are always bad.\n\nStill, I hope this does give some food for thought and on a practical basis any improvement in the network protocol that shaves off a few bytes is always better.  This doesn't seem to sacrifice too much in terms of the overhead either.  More significantly, you are calling attention to an area of efficiency that needs to be addressed and is very helpful to the project.  Thank you for doing that.  I'm hoping to get caught up to where you are at now on this protocol business.","Quote from: RHorning on July 30, 2010, 02:13:27 PM"],["t","They're not always bad. However, if you put in so much effort that your hand built packet was smaller than a protocol buffer then you're probably putting too much effort into a micro optimisation Wink\n\nI'll be happy to help anyone catch up with the protocol buffers. If someone is willing to work with me I'd even work on a patch, I have very little C++ experience so I can't do it alone unfortunately."],["q","I think using protocol buffers as the serialization format is a good idea, but I don't think just switching to protocol buffers \"buys\" enough to be worth the effort (at least not now, when transaction volume is low).","Quote from: gavinandresen on July 30, 2010, 02:28:23 PM"],["t","I would disagree, protocol buffers are smaller which is nice, but it's not their main advantage - they're forwards compatible which is a hugely important thing in a p2p network, they're also something which can easily be used in many languages, which make implementing new clients in new languages easier, which in my opinion is vital for bitcoin."],["q","FYI, it is pointless to make a packet smaller than 60 bytes -- the minimum size of an Ethernet packet.  Packets are padded up to 60 bytes, if they are smaller.","Quote from: jgarzik on July 30, 2010, 03:47:33 PM"],["t","Indeed, but the version packet is probably the smallest packet of all the ones sent, so we'll gain more elsewhere. Also, keep an eye on the main point. The fact that protocol buffers are smaller is a nice aside to the fact that they're Forwards compatible and make bitcoin portable between languages."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6675#msg6675"},{"f":"lachesis","d":1280583923,"b":[["q","The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is over half the size of the hand built layout!","Quote from: martin on July 30, 2010, 11:37:59 AM"],["t","The \"0x00\" groups each represent one byte. The length of the standard version packet is 87 bytes plus 20 for the header. The header could be massively optimized as well:"],["c","message start \"magic bytes\" - 0xF9 0xBE 0xB4 0xD9\ncommand - name of command, 0 padded to 12 bytes \"version\\0\\0\\0\\0\\0\"\nsize - 4 byte int\nchecksum (absent for messages without data and version messages) - 4 bytes"],["t","Obviously using proto buffers here, while absolutely a breaking change, would save a fair bit of space, especially because the \"I've created a transaction\" packet has the name \"tx\" meaning that there's at least 10 bytes of overhead in every one of those packets."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6811#msg6811"},{"f":"martin","d":1280585465,"b":[["q","The \"0x00\" groups each represent one byte.","Quote from: lachesis on July 31, 2010, 01:45:23 PM"],["t","Oops Embarrassed"],["q","breaking change","Quote from: lachesis on July 31, 2010, 01:45:23 PM"],["t","I think the best way to phase in protocol bufferswould to avoid breaking changes to start with, instead start with protocol buffers for the local files (like the wallet), which would gain us a little bit of size on disk, ease of reading the wallet file in other software, and get some experience using protocol buffers. Then is the time to start phasing in protocol buffers for networking in my opinion.\n\nDoes the current version of bitcoin have any handling for ignoring chunks of a packet? If so, phasing in protocol buffers could be as simple as writing the current packet AND writing the protocol buffer (as an ignored field for older clients), then once enough people have upgraded get rid of the old encoding."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6816#msg6816"},{"f":"andrew","d":1280717023,"b":[["t","Why do you consider it a breaking change? There's no reason you couldn't first try with the new protocol and then retry using the old bitcoin serialization technique. Also I think this is a change that should be made sooner rather then later while the BitCoin community is still small. It's already been a major blocker in making new clients and delaying it is going to hamper bitcoin's adoption."]],"u":"https://bitcointalk.org/index.php?topic=632.msg6958#msg6958"},{"f":"martin","d":1280749053,"b":[["q","Why do you consider it a breaking change? There's no reason you couldn't first try with the new protocol and then retry using the old bitcoin serialization technique.","Quote from: andrew on August 02, 2010, 02:43:43 AM"],["t","That's a very good idea, and I would say it's the way to go with this."],["q","Also I think this is a change that should be made sooner rather then later while the BitCoin community is still small. It's already been a major blocker in making new clients and delaying it is going to hamper bitcoin's adoption.","Quote from: andrew on August 02, 2010, 02:43:43 AM"],["t","Since it's a non breaking change, it should be done as soon as possible in my opinion, for those very reasons.\n\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 Wink"]],"u":"https://bitcointalk.org/index.php?topic=632.msg6992#msg6992"},{"f":"satoshi","d":1280780528,"b":[["t","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.\n\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.\n\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)\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=632.msg7090#msg7090","s":1,"n":308,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/308/"}]},{"id":"p148","k":"p","s":"bitcointalk","t":"Building initial transaction trust through \"coin ripping\"","u":"https://bitcointalk.org/index.php?topic=635","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/148/","m":[{"f":"chaord","d":1280462575,"b":[["t","I'm certainly not a cryptographer by trade or anything so I'm not sure if this idea holds any water.  As I browse the forums I am noticing that perhaps one of the bigger issues when transacting with BC is building reputation between the transacting parties.  In particular, the very first transaction seems to be critical.\n\nI'm wondering if a solution, similar to what Professor Markus Jakobsson proposed in his paper could work? See http://romualdogrillo.net/index.php?option=com_content&view=article&id=48&Itemid=54   for an overview.  In a nutshell, the goal with \"coin ripping\" is similar to what could be done with traditional paper money. \n\n• If A is going to perform $5 of service for B, they each can take out a $5 bill and rip them in half.\n\n• Now A and B would each have 2 halve's of a $5 bill, but neither would have the correct halves.\n\n• Therefore A is incentivized to actually perform the service for B, since this is the only way for him to receive both the missing half from his original $5bill back and the missing half of B's original $5 bill.\n\n• The result is a transfer of $5 to A from B (as originally planned) in exchange for service.\n\nOf course, if A or B is a scammer, with this scenario both of them would lose.  In other words, it wouldn't pay to be a scammer.\n\nI don't know if this is something that would qualify for design consideration, but if all transactions were \"ripped\" by default, it might set people's minds at ease.  Additionally, it could possibly be algorithmically implemented unlike a staffed escrow account.\n\nWhat do you guys think?"]],"u":"https://bitcointalk.org/index.php?topic=635.msg6588#msg6588"},{"f":"xc","d":1280464992,"b":[["t","That's very clever. Satoshi has implied that there is great flexibility in the way transactions could work: http://bitcointalk.org/index.php?topic=195.msg1611#msg1611. I think he may have had such ideas in mind.\n\nIn time, hopefully, numerous such arrangements can be used to fully develop the idea of 'smart' contracts (http://en.wikipedia.org/wiki/Smart_contracts). The current Bitcoin implementation already represents a working example of smart contracts: software encoded rules governing digital property. Rothbard in Ethics of Liberty talks about how powerful the simple penal bond was to medieval commerce (http://mises.org/rothbard/ethics/nineteen.asp). Given the right contract tools, the Bitcoin economy will be able to flourish without relying on the expense and ethical contradictions of state courts.\n\nXC"]],"u":"https://bitcointalk.org/index.php?topic=635.msg6592#msg6592"},{"f":"Red","d":1280465329,"b":[["t","To make that work in bitcoin you would need to be able to create a private key that both of you know, but a public key that each of you only know *half* of. In the crypto sense of half, where there are two secrets that can be combined together mathematically to make a third secret.\n\nYou would both transfer 5 BTC to the bitcoin address matching the public key. Then neither could retrieve the coins until one surrendered his half to the other.\n\nA proxy comes to mine, but that is cheating. If you used a proxy to generate the private key and split it, they would know the private key and in that case you might as well trust them to hold the money without splitting the key.\n\nI don't know enough about how elliptic curve based keys are generated to propose an algorithm. But stranger things have happened in crypto than that. In some cases, you can do math with two unknown encrypted numbers and have and have the answer decrypt correctly.\n\nGo figure."]],"u":"https://bitcointalk.org/index.php?topic=635.msg6593#msg6593"},{"f":"martin","d":1280477604,"b":[["t","One possibility would be to ask a algorithmically selected node from the network as intermediary. It would be possible, I suspect, to make the system work in such a way that nobody can get the money unless the two parties and the intermediary cooperate (so the intermediary cannot steal the money)"]],"u":"https://bitcointalk.org/index.php?topic=635.msg6627#msg6627"},{"f":"bytemaster","d":1280881053,"b":[["t","I think that Red's idea is great if it can be properly designed.\n\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. "]],"u":"https://bitcointalk.org/index.php?topic=635.msg7374#msg7374"},{"f":"satoshi","d":1280882440,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=635.msg7385#msg7385","s":1,"n":316,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/316/"}]},{"id":"p149","k":"p","s":"bitcointalk","t":"Bug: \"Immature\" coins lost in wallet.dat during transaction","u":"https://bitcointalk.org/index.php?topic=642","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/149/","m":[{"f":"Dybbuk","d":1280507956,"b":[["t","Howdy,\n\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.\n\nHere is the relevant bit from my debug.log:\n\nThreadRPCServer method=sendtoaddress\nCommitTransaction:\nCTransaction(hash=cf3bee, ver=1, vin.size=1, vout.size=2, nLockTime=0)\n    CTxIn(COutPoint(e9894c, 0), scriptSig=0x014866DE7A1889014BAC9A)\n    CTxOut(nValue=20.00000000, scriptPubKey=OP_DUP OP_HASH160 0x01BA)\n    CTxOut(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\n\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!\n\nErik"]],"u":"https://bitcointalk.org/index.php?topic=642.msg6672#msg6672"},{"f":"satoshi","d":1280517545,"b":[["t","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.\n\nHow many blocks did it say it had left to mature when you sent?\n\nThere's a chance it might still go through.\n\nHave you copied or moved your wallet.dat in any way?"]],"u":"https://bitcointalk.org/index.php?topic=642.msg6701#msg6701","s":1,"n":298,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/298/"}]},{"id":"p150","k":"p","s":"bitcointalk","t":"Automated nightly builds","u":"https://bitcointalk.org/index.php?topic=644","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/150/","m":[{"f":"Cdecker","d":1280514708,"b":[["t","I finally managed to get the openSuse Build Service (OBS) to build working nightly packages of bitcoind (the client without the wx GUI). openSuse and SLE will follow soon.\n\nTo install the Ubuntu packages add the following line to your /etc/apt/sources.list:"],["c","deb http://download.opensuse.org/repositories/home:/cdecker/xUbuntu_10.04/ ./"],["t","Next update:"],["c","sudo aptitude update\nsudo aptitude install bitcoind"],["t","If you get a warning about not being able to verify the validity of the packages, just ignore them, I wasn't able to find the public key yet :-)\n\nThen just create a config file ~/.bitcoin/bitcoin.conf to configure the RPC password:"],["c","rpcpassword=<yourpassword>"],["t","After this just start the daemon via"],["c","bitcoind"],["t","and control it using the JSON interface.\n\nI'll be trying to create openSuse and SLE packages too, Debian would be possible too, but compiling wx, boost and libdb sounds a bit excessive to me, anyone interested in helping?"]],"u":"https://bitcointalk.org/index.php?topic=644.msg6688#msg6688"},{"f":"Gavin Andresen","d":1291912993,"b":[["q","I'll be trying to create openSuse and SLE packages too, Debian would be possible too, but compiling wx, boost and libdb sounds a bit excessive to me, anyone interested in helping?","Quote from: Cdecker on July 30, 2010, 06:31:48 PM"],["t","Nightly builds are a great idea; does the build service do an automatic svn update?  Anybody else willing to help get GUI-bitcoin building (or anybody know somebody on the wxWidgets team?)"]],"u":"https://bitcointalk.org/index.php?topic=644.msg28593#msg28593"},{"f":"Cdecker","d":1291914201,"b":[["t","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.\n\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 ^^"]],"u":"https://bitcointalk.org/index.php?topic=644.msg28612#msg28612"},{"f":"satoshi","d":1291919325,"b":[["t","Thanks for setting this up Cdecker. \n\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?"]],"u":"https://bitcointalk.org/index.php?topic=644.msg28643#msg28643","s":1,"n":531,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/531/"}]},{"id":"p151","k":"p","s":"bitcointalk","t":"A proposal for a semi-automated Escrow mechanism","u":"https://bitcointalk.org/index.php?topic=645","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/151/","m":[{"f":"Olipro","d":1280518148,"b":[["t","So, the basic escrow works by two people working through a third party to exchange (usually money) for some other form of goods or services.\n\nIn a transaction where both people are honest, the escrow business can essentially be automatic since the buyer gets his goods and approves release of funds, only when there is a dispute does human interaction become necessary. Therefore, I propose the following system:\n\n1) you create an escrow transaction for the amount, authorised by your key and containing the recipient's key/data etc - this block cannot be claimed until a subsequent block is issued by the buyer to approve it, it's also impossible for the buyer to reclaim it without the seller approving it to be returned.\n\n2) it enters the network, gets verified and the seller sends the goods, once the buyer gets them, he creates a release transaction and the seller gets his bitcoins.\n\n3) if a dispute occurs and both parties are refusing to release the money one way or the other, clearly it's now necessary to get a third party to arbitrate - in this situation, a signature from both the buyer and seller authorising a third party is required which will give that third party ownership of the original escrow transaction and they can then arbitrate the matter"]],"u":"https://bitcointalk.org/index.php?topic=645.msg6704#msg6704"},{"f":"knightmb","d":1280524191,"b":[["t","Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special \"all clear\" message to that server that then knows to \"release\" what it has to whoever it's suppose to go to.\n\nProgramming wise, should be possible with direct IP payments for example, where the \"From\" and \"Comment\" fields can be used to \"reserve\" the BTC until later.\n\nOne could send a transaction and in the comment field put something like \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\".\n\nWhen the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.\n\nVery doable from a programming standpoint."]],"u":"https://bitcointalk.org/index.php?topic=645.msg6721#msg6721"},{"f":"Olipro","d":1280537810,"b":[["q","Basically a specialized bitcoind that the buyer sends a payment to and when everything is good, the buyer sends a special \"all clear\" message to that server that then knows to \"release\" what it has to whoever it's suppose to go to.\n\nProgramming wise, should be possible with direct IP payments for example, where the \"From\" and \"Comment\" fields can be used to \"reserve\" the BTC until later.\n\nOne could send a transaction and in the comment field put something like \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\".\n\nWhen the buyer gets the stuff and he/she is happy, they send a 0.01 payment to the same escrow server \"Escrow=<public hash of seller> Amount=1000.00 Release=<some encrypted string>\" and the server sees the match, knows it's ok to send payment to that address, for that amount, etc.\n\nVery doable from a programming standpoint.","Quote from: knightmb on July 30, 2010, 09:09:51 PM"],["t","kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party."]],"u":"https://bitcointalk.org/index.php?topic=645.msg6757#msg6757"},{"f":"Cdecker","d":1280586556,"b":[["q","kind of, the point of this system is that you can leverage the network for escrow transactions so long as everything goes to plan, thereby ensuring a low cost. in instances of dispute, you will pay a third party.","Quote from: Olipro on July 31, 2010, 12:56:50 AM"],["t","I'd go too with websites offering escrow services. The network is quiet complex as it is, without having to add all the confirmation, delay and dispute stuff.\nCurrently when a transaction is broadcast it'll sooner or later be added to the block chain, what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.\nAlso who do you think will be the third party moderating the dispute? There is no real advantage in adding it to the protocol itself."]],"u":"https://bitcointalk.org/index.php?topic=645.msg6821#msg6821"},{"f":"FreeMoney","d":1280604892,"b":[["q","  what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.","Quote from: Cdecker on July 31, 2010, 02:29:16 PM"],["t","I don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up."]],"u":"https://bitcointalk.org/index.php?topic=645.msg6844#msg6844"},{"f":"Olipro","d":1281025607,"b":[["q","> Quote from: Cdecker on July 31, 2010, 02:29:16 PM\n>   what you are asking for is a mechanism to tentatively add a transaction and then dispute it later.\n\nI don't think that's what he means. The transaction will be made completely, but both will hold part of the key required to spend that money. If they are satisfied they ship the money to the appropriate person. There is not disputing with the block chain. They either work it out and use the code like everyone else does for all transactions, or they don't work it out and the money stays locked up.","Quote from: FreeMoney on July 31, 2010, 07:34:52 PM"],["t","if the buyer refuses to finalise the transaction and the seller refuses to permit a refund, they have 2 choices.\n\n1) be spiteful and nobody will get anything\n\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.\n\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:\n\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.\n\nif everything goes to plan, the buyer OKs the release of the funds and the seller gets the payment + his \"trust deposit\" returned.\n\nif the buyer wishes to cancel, the seller authorises the cancellation and both parties get their original funds back.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=645.msg7693#msg7693"},{"f":"satoshi","d":1281031710,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=645.msg7712#msg7712","s":1,"n":325,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/325/"},{"f":"Red","d":1281033035,"b":[["q","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.","Quote from: satoshi on August 05, 2010, 06:08:30 PM"],["t","That is really quite clever!\n\nDo you simply assign the transaction to two bitcoin addresses and transmit it to the network for inclusion in the block list?\nCan you do more than two? Is it a one-or-more situation?\n\nIs this feature in the GUI yet?"]],"u":"https://bitcointalk.org/index.php?topic=645.msg7718#msg7718"},{"f":"jgarzik","d":1281034830,"b":[["q","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.","Quote from: satoshi on August 05, 2010, 06:08:30 PM"],["t","Due to that recourse, it is unlikely to be used as an escrow mechanism Smiley"]],"u":"https://bitcointalk.org/index.php?topic=645.msg7723#msg7723"},{"f":"satoshi","d":1281211499,"b":[["q","Due to that recourse, it is unlikely to be used as an escrow mechanism Smiley","Quote from: jgarzik on August 05, 2010, 07:00:30 PM"],["t","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.)"]],"u":"https://bitcointalk.org/index.php?topic=645.msg8137#msg8137","s":1,"n":328,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/328/"}]},{"id":"p152","k":"p","s":"bitcointalk","t":"4 hashes parallel on SSE2 CPUs for 0.3.6","u":"https://bitcointalk.org/index.php?topic=648","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/152/","m":[{"f":"tcatm","d":1280524990,"b":[["t","This patch will calculate four hashes on one core using vector instructions. There's a test programm included that validates the new hash function against the old one so it should be correct.\n\nThe patch is against 0.3.6. Improves khash/s by roughly 115%.\n\nhttp://pastebin.com/XN1JDb53"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6722#msg6722"},{"f":"knightmb","d":1280525609,"b":[["t","I take it that you've already tested the hash limit before performance starts to suffer against the stock code? I'm just curious myself."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6725#msg6725"},{"f":"tcatm","d":1280526442,"b":[["t","Performance of stock code (as measured by my test/benchmark program) is about 1500khash/s.\nMy code does 3500khash/s. Both figures are for one core. It scales well because I do 128 hashes at once and keep the datastructures small enough to fit in the CPU cache.\n\nI have two local collision attacks which will squeeze another 300khash/s out, but they are not stable yet."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6730#msg6730"},{"f":"knightmb","d":1280526670,"b":[["t","Awesome, I'll have to give it a try myself then.  Shocked"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6732#msg6732"},{"f":"tcatm","d":1280527224,"b":[["t","Tell me if it works Smiley\nDonations are welcome. 17asVKkzRGTFvvGH9dMGQaHe78xzfvgSSA "]],"u":"https://bitcointalk.org/index.php?topic=648.msg6736#msg6736"},{"f":"satoshi","d":1280536160,"b":[["t","That's amazing...\n\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."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6751#msg6751","s":1,"n":302,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/302/"},{"f":"knightmb","d":1280551773,"b":[["t","Darn, it means the next release, the difficulty is going to have to increase to 1000 or so to keep up, LOL  Grin"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6777#msg6777"},{"f":"tcatm","d":1280571158,"b":[["q","That's amazing...\n\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.","Quote from: satoshi on July 31, 2010, 12:29:20 AM"],["t","That's how it works. Four 32 bit values in a 128 bit vector. They're calculated independently, but at the same time.\n\nBtw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6797#msg6797"},{"f":"em3rgentOrdr","d":1280583768,"b":[["t","hmm...I wasn't able to apply the patch (I'm a noobie). Here's the command I ran from bitcoin-0.3.6/src # patch < XN1JDb53.txt\n\nOutput:\n\n1 out of 1 hunk ignored\n(Stripping trailing CRs from patch.)\npatching file main.cpp\nHunk #1 FAILED at 2555.\nHunk #2 FAILED at 2701.\n2 out of 2 hunks FAILED\n(Stripping trailing CRs from patch.)\npatching file makefile.unix\nHunk #1 FAILED at 45.\nHunk #2 FAILED at 58.\n\nWhat's the proper command to type into linux?  Or do you have linux binaries?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6810#msg6810"},{"f":"tcatm","d":1280585883,"b":[["t","the mean client would send all generated bitcoins to a certain address Wink\n\n@em3rgent0rder: i don't know why it fails, but it should be easy to patch it manually..."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6817#msg6817"},{"f":"jgarzik","d":1280596710,"b":[["q","hmm...I wasn't able to apply the patch (I'm a noobie). Here's the command I ran from bitcoin-0.3.6/src # patch < XN1JDb53.txt\n\nOutput:\n\n1 out of 1 hunk ignored\n(Stripping trailing CRs from patch.)\npatching file main.cpp\nHunk #1 FAILED at 2555.\nHunk #2 FAILED at 2701.\n2 out of 2 hunks FAILED\n(Stripping trailing CRs from patch.)\npatching file makefile.unix\nHunk #1 FAILED at 45.\nHunk #2 FAILED at 58.","Quote from: em3rgentOrdr on July 31, 2010, 01:42:48 PM"],["t","It definitely does not apply to the SVN trunk.  Maybe tcatm could post the main.cpp itself?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6830#msg6830"},{"f":"tcatm","d":1280598027,"b":[["t","Looks like pastebin.com messes up the patch..."],["c","diff --git a/cryptopp/sha256.cpp b/cryptopp/sha256.cpp\nnew file mode 100644\nindex 0000000..15f8be1\n--- /dev/null\n+++ b/cryptopp/sha256.cpp\n@@ -0,0 +1,443 @@\n+#include <string.h>\n+#include <assert.h>\n+\n+#include <xmmintrin.h>\n+#include <stdint.h>\n+#include <stdio.h>\n+\n+#define NPAR 32\n+\n+static const unsigned int sha256_consts[] = {\n+ 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, /*  0 */\n+ 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,\n+ 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, /*  8 */\n+ 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,\n+ 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, /* 16 */\n+ 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,\n+ 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, /* 24 */\n+ 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,\n+ 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, /* 32 */\n+ 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,\n+ 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, /* 40 */\n+ 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,\n+ 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, /* 48 */\n+ 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,\n+ 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, /* 56 */\n+ 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2\n+};\n+\n+\n+static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {\n+ return (b & c) ^ (~b & d);\n+}\n+\n+static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {\n+ return (b & c) ^ (b & d) ^ (c & d);\n+}\n+\n+static inline __m128i ROTR(__m128i x, const int n) {\n+ return _mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n);\n+}\n+\n+static inline __m128i SHR(__m128i x, const int n) {\n+ return _mm_srli_epi32(x, n);\n+}\n+\n+/* SHA256 Functions */\n+#define BIGSIGMA0_256(x) (ROTR((x), 2) ^ ROTR((x), 13) ^ ROTR((x), 22))\n+#define BIGSIGMA1_256(x) (ROTR((x), 6) ^ ROTR((x), 11) ^ ROTR((x), 25))\n+#define SIGMA0_256(x)  (ROTR((x), 7) ^ ROTR((x), 18) ^ SHR((x), 3))\n+#define SIGMA1_256(x)  (ROTR((x), 17) ^ ROTR((x), 19) ^ SHR((x), 10))\n+\n+static inline __m128i load_epi32(const unsigned int x0, const unsigned int x1, const unsigned int x2, const unsigned int x3) {\n+ return _mm_set_epi32(x0, x1, x2, x3);\n+}\n+\n+static inline unsigned int store32(const __m128i x, int i) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x;\n+ return box.ret[i];\n+}\n+\n+static inline void store_epi32(const __m128i x, unsigned int *x0, unsigned int *x1, unsigned int *x2, unsigned int *x3) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x;\n+ *x0 = box.ret[3]; *x1 = box.ret[2]; *x2 = box.ret[1]; *x3 = box.ret[0];\n+}\n+\n+static inline __m128i SHA256_CONST(const int i) {\n+ return _mm_set1_epi32(sha256_consts[i]);\n+}\n+\n+#define add4(x0, x1, x2, x3) _mm_add_epi32(_mm_add_epi32(_mm_add_epi32(x0, x1), x2), x3)\n+#define add5(x0, x1, x2, x3, x4) _mm_add_epi32(add4(x0, x1, x2, x3), x4)\n+\n+#define SHA256ROUND(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+d = _mm_add_epi32(d, T1);                                           \\\n+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \\\n+h = _mm_add_epi32(T1, T2);\n+\n+#define SHA256ROUND_lastd(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+d = _mm_add_epi32(d, T1);                                           \n+//T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \n+//h = _mm_add_epi32(T1, T2);\n+\n+#define SHA256ROUND_last(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \\\n+h = _mm_add_epi32(T1, T2);\n+\n+static inline unsigned int swap(unsigned int value) {\n+ __asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));\n+ return value;\n+}\n+\n+static inline unsigned int SWAP32(const void *addr) {\n+ unsigned int value = (*((unsigned int *)(addr)));\n+ __asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));\n+ return value;\n+}\n+\n+static inline void dumpreg(__m128i x, char *msg) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x ;\n+ printf(\"%s %08x %08x %08x %08x\", msg, box.ret[0], box.ret[1], box.ret[2], box.ret[3]);\n+}\n+\n+#if 1\n+#define dumpstate(i) printf(\"%s: %08x %08x %08x %08x %08x %08x %08x %08x %08x\", \\\n+  __func__, store32(w0, i), store32(a, i), store32(b, i), store32(c, i), store32(d, i), store32(e, i), store32(f, i), store32(g, i), store32(h, i));\n+#else\n+#define dumpstate()\n+#endif\n+void Double_BlockSHA256(const void* pin, void* pad, const void *pre, unsigned int thash[8][NPAR], const void *init)\n+{\n+ unsigned int* In = (unsigned int*)pin;\n+ unsigned int* Pad = (unsigned int*)pad;\n+ unsigned int* hPre = (unsigned int*)pre;\n+ unsigned int* hInit = (unsigned int*)init;\n+ unsigned int i, j, k;\n+\n+ /* vectors used in calculation */\n+ __m128i w0, w1, w2, w3, w4, w5, w6, w7;\n+ __m128i w8, w9, w10, w11, w12, w13, w14, w15;\n+ __m128i T1, T2;\n+ __m128i a, b, c, d, e, f, g, h;\n+\n+ /* nonce offset for vector */\n+ __m128i offset = load_epi32(0x00000003, 0x00000002, 0x00000001, 0x00000000);\n+\n+\n+ for(k = 0; k<NPAR; k+=4) {\n+  w0 = load_epi32(In[0], In[0], In[0], In[0]);\n+  w1 = load_epi32(In[1], In[1], In[1], In[1]);\n+  w2 = load_epi32(In[2], In[2], In[2], In[2]);\n+  w3 = load_epi32(In[3], In[3], In[3], In[3]);\n+  w4 = load_epi32(In[4], In[4], In[4], In[4]);\n+  w5 = load_epi32(In[5], In[5], In[5], In[5]);\n+  w6 = load_epi32(In[6], In[6], In[6], In[6]);\n+  w7 = load_epi32(In[7], In[7], In[7], In[7]);\n+  w8 = load_epi32(In[8], In[8], In[8], In[8]);\n+  w9 = load_epi32(In[9], In[9], In[9], In[9]);\n+  w10 = load_epi32(In[10], In[10], In[10], In[10]);\n+  w11 = load_epi32(In[11], In[11], In[11], In[11]);\n+  w12 = load_epi32(In[12], In[12], In[12], In[12]);\n+  w13 = load_epi32(In[13], In[13], In[13], In[13]);\n+  w14 = load_epi32(In[14], In[14], In[14], In[14]);\n+  w15 = load_epi32(In[15], In[15], In[15], In[15]);\n+\n+  /* hack nonce into lowest byte of w3 */\n+  __m128i k_vec = load_epi32(k, k, k, k);\n+  w3 = _mm_add_epi32(w3, offset);\n+  w3 = _mm_add_epi32(w3, k_vec);\n+\n+  a = load_epi32(hPre[0], hPre[0], hPre[0], hPre[0]);\n+  b = load_epi32(hPre[1], hPre[1], hPre[1], hPre[1]);\n+  c = load_epi32(hPre[2], hPre[2], hPre[2], hPre[2]);\n+  d = load_epi32(hPre[3], hPre[3], hPre[3], hPre[3]);\n+  e = load_epi32(hPre[4], hPre[4], hPre[4], hPre[4]);\n+  f = load_epi32(hPre[5], hPre[5], hPre[5], hPre[5]);\n+  g = load_epi32(hPre[6], hPre[6], hPre[6], hPre[6]);\n+  h = load_epi32(hPre[7], hPre[7], hPre[7], hPre[7]);\n+\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);   \n+  SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);\n+\n+#define store_load(x, i, dest) \\\n+  w8 = load_epi32((hPre)[i], (hPre)[i], (hPre)[i], (hPre)[i]); \\\n+  dest = _mm_add_epi32(w8, x);\n+\n+  store_load(a, 0, w0);\n+  store_load(b, 1, w1);\n+  store_load(c, 2, w2);\n+  store_load(d, 3, w3);\n+  store_load(e, 4, w4);\n+  store_load(f, 5, w5);\n+  store_load(g, 6, w6);\n+  store_load(h, 7, w7);\n+\n+  w8 = load_epi32(Pad[8], Pad[8], Pad[8], Pad[8]);\n+  w9 = load_epi32(Pad[9], Pad[9], Pad[9], Pad[9]);\n+  w10 = load_epi32(Pad[10], Pad[10], Pad[10], Pad[10]);\n+  w11 = load_epi32(Pad[11], Pad[11], Pad[11], Pad[11]);\n+  w12 = load_epi32(Pad[12], Pad[12], Pad[12], Pad[12]);\n+  w13 = load_epi32(Pad[13], Pad[13], Pad[13], Pad[13]);\n+  w14 = load_epi32(Pad[14], Pad[14], Pad[14], Pad[14]);\n+  w15 = load_epi32(Pad[15], Pad[15], Pad[15], Pad[15]);\n+\n+  a = load_epi32(hInit[0], hInit[0], hInit[0], hInit[0]);\n+  b = load_epi32(hInit[1], hInit[1], hInit[1], hInit[1]);\n+  c = load_epi32(hInit[2], hInit[2], hInit[2], hInit[2]);\n+  d = load_epi32(hInit[3], hInit[3], hInit[3], hInit[3]);\n+  e = load_epi32(hInit[4], hInit[4], hInit[4], hInit[4]);\n+  f = load_epi32(hInit[5], hInit[5], hInit[5], hInit[5]);\n+  g = load_epi32(hInit[6], hInit[6], hInit[6], hInit[6]);\n+  h = load_epi32(hInit[7], hInit[7], hInit[7], hInit[7]);\n+\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);   \n+  SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);\n+\n+  /* store resulsts directly in thash */\n+#define store_2(x,i)  \\\n+  w0 = load_epi32((hInit)[i], (hInit)[i], (hInit)[i], (hInit)[i]); \\\n+  *(__m128i *)&(thash)[i][0+k] = _mm_add_epi32(w0, x);\n+\n+  store_2(a, 0);\n+  store_2(b, 1);\n+  store_2(c, 2);\n+  store_2(d, 3);\n+  store_2(e, 4);\n+  store_2(f, 5);\n+  store_2(g, 6);\n+  store_2(h, 7);\n+ }\n+\n+}\ndiff --git a/main.cpp b/main.cpp\nindex ddc359a..d30d642 100755\n--- a/main.cpp\n+++ b/main.cpp\n@@ -2555,8 +2555,10 @@ inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)\n     CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);\n }\n \n+// !!!! NPAR must match NPAR in cryptopp/sha256.cpp !!!!\n+#define NPAR 32\n \n-\n+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[8][NPAR], const void *init2);\n \n \n void BitcoinMiner()\n@@ -2701,108 +2703,123 @@ void BitcoinMiner()\n         uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();\n         uint256 hashbuf[2];\n         uint256& hash = *alignup<16>(hashbuf);\n+\n+        // Cache for NPAR hashes\n+        unsigned int thash[8][NPAR];\n+\n+        unsigned int j;\n         loop\n         {\n-            SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);\n-            SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);\n+          Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);\n \n-            if (((unsigned short*)&hash)[14] == 0)\n+          for(j = 0; j<NPAR; j++) {\n+            if (thash[7][j] == 0)\n             {\n-                // Byte swap the result after preliminary check\n-                for (int i = 0; i < sizeof(hash)/4; i++)\n-                    ((unsigned int*)&hash)[i] = ByteReverse(((unsigned int*)&hash)[i]);\n-\n-                if (hash <= hashTarget)\n+              // Byte swap the result after preliminary check\n+              for (int i = 0; i < sizeof(hash)/4; i++)\n+                ((unsigned int*)&hash)[i] = ByteReverse((unsigned int)thash[i][j]);\n+\n+              if (hash <= hashTarget)\n+              {\n+                // Double_BlocSHA256 might only calculate parts of the hash.\n+                // We'll insert the nonce and get the real hash.\n+                //pblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n+                //hash = pblock->GetHash();\n+\n+                pblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n+                assert(hash == pblock->GetHash());\n+\n+                //// debug print\n+                printf(\"BitcoinMiner:\");\n+                printf(\"proof-of-work found    hash: %s  target: %s\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());\n+                pblock->print();\n+                printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n+                printf(\"generated %s\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());\n+\n+                SetThreadPriority(THREAD_PRIORITY_NORMAL);\n+                CRITICAL_BLOCK(cs_main)\n                 {\n-                    pblock->nNonce = ByteReverse(tmp.block.nNonce);\n-                    assert(hash == pblock->GetHash());\n-\n-                        //// debug print\n-                        printf(\"BitcoinMiner:\");\n-                        printf(\"proof-of-work found    hash: %s  target: %s\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());\n-                        pblock->print();\n-                        printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n-                        printf(\"generated %s\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());\n-\n-                    SetThreadPriority(THREAD_PRIORITY_NORMAL);\n-                    CRITICAL_BLOCK(cs_main)\n-                    {\n-                        if (pindexPrev == pindexBest)\n-                        {\n-                            // Save key\n-                            if (!AddKey(key))\n-                                return;\n-                            key.MakeNewKey();\n-\n-                            // Track how many getdata requests this block gets\n-                            CRITICAL_BLOCK(cs_mapRequestCount)\n-                                mapRequestCount[pblock->GetHash()] = 0;\n-\n-                            // Process this block the same as if we had received it from another node\n-                            if (!ProcessBlock(NULL, pblock.release()))\n-                                printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\");\n-                        }\n-                    }\n-                    SetThreadPriority(THREAD_PRIORITY_LOWEST);\n-\n-                    Sleep(500);\n-                    break;\n+                  if (pindexPrev == pindexBest)\n+                  {\n+                    // Save key\n+                    if (!AddKey(key))\n+                      return;\n+                    key.MakeNewKey();\n+\n+                    // Track how many getdata requests this block gets\n+                    CRITICAL_BLOCK(cs_mapRequestCount)\n+                      mapRequestCount[pblock->GetHash()] = 0;\n+\n+                    // Process this block the same as if we had received it from another node\n+                    if (!ProcessBlock(NULL, pblock.release()))\n+                      printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\");\n+\n+                  }\n                 }\n-            }\n+                SetThreadPriority(THREAD_PRIORITY_LOWEST);\n \n-            // Update nTime every few seconds\n-            const unsigned int nMask = 0xffff;\n-            if ((++tmp.block.nNonce & nMask) == 0)\n+                Sleep(500);\n+                break;\n+              }\n+            }\n+          }\n+\n+          // Update nonce\n+          tmp.block.nNonce += NPAR;\n+\n+          // Update nTime every few seconds\n+          const unsigned int nMask = 0xffff;\n+          if ((tmp.block.nNonce & nMask) == 0)\n+          {\n+            // Meter hashes/sec\n+            static int64 nTimerStart;\n+            static int nHashCounter;\n+            if (nTimerStart == 0)\n+              nTimerStart = GetTimeMillis();\n+            else\n+              nHashCounter++;\n+            if (GetTimeMillis() - nTimerStart > 4000)\n             {\n-                // Meter hashes/sec\n-                static int64 nTimerStart;\n-                static int nHashCounter;\n-                if (nTimerStart == 0)\n-                    nTimerStart = GetTimeMillis();\n-                else\n-                    nHashCounter++;\n+              static CCriticalSection cs;\n+              CRITICAL_BLOCK(cs)\n+              {\n                 if (GetTimeMillis() - nTimerStart > 4000)\n                 {\n-                    static CCriticalSection cs;\n-                    CRITICAL_BLOCK(cs)\n-                    {\n-                        if (GetTimeMillis() - nTimerStart > 4000)\n-                        {\n-                            double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);\n-                            nTimerStart = GetTimeMillis();\n-                            nHashCounter = 0;\n-                            string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/1000.0);\n-                            UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));\n-                            static int64 nLogTime;\n-                            if (GetTime() - nLogTime > 30 * 60)\n-                            {\n-                                nLogTime = GetTime();\n-                                printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n-                                printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/1000.0);\n-                            }\n-                        }\n-                    }\n+                  double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);\n+                  nTimerStart = GetTimeMillis();\n+                  nHashCounter = 0;\n+                  string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/1000.0);\n+                  UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));\n+                  static int64 nLogTime;\n+                  if (GetTime() - nLogTime > 30 * 60)\n+                  {\n+                    nLogTime = GetTime();\n+                    printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n+                    printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/1000.0);\n+                  }\n                 }\n-\n-                // Check for stop or if block needs to be rebuilt\n-                if (fShutdown)\n-                    return;\n-                if (!fGenerateBitcoins)\n-                    return;\n-                if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)\n-                    return;\n-                if (vNodes.empty())\n-                    break;\n-                if (tmp.block.nNonce == 0)\n-                    break;\n-                if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)\n-                    break;\n-                if (pindexPrev != pindexBest)\n-                    break;\n-\n-                pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());\n-                tmp.block.nTime = ByteReverse(pblock->nTime);\n+              }\n             }\n+\n+            // Check for stop or if block needs to be rebuilt\n+            if (fShutdown)\n+              return;\n+            if (!fGenerateBitcoins)\n+              return;\n+            if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)\n+              return;\n+            if (vNodes.empty())\n+              break;\n+            if (tmp.block.nNonce == 0)\n+              break;\n+            if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)\n+              break;\n+            if (pindexPrev != pindexBest)\n+              break;\n+\n+            pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());\n+            tmp.block.nTime = ByteReverse(pblock->nTime);\n+          }\n         }\n     }\n }\ndiff --git a/makefile.unix b/makefile.unix\nindex 597a0ea..8fb0aa6 100755\n--- a/makefile.unix\n+++ b/makefile.unix\n@@ -45,7 +45,8 @@ OBJS= \\\n     obj/rpc.o \\\n     obj/init.o \\\n     cryptopp/obj/sha.o \\\n-    cryptopp/obj/cpu.o\n+    cryptopp/obj/cpu.o \\\n+  cryptopp/obj/sha256.o\n \n \n all: bitcoin\n@@ -58,18 +59,20 @@ obj/%.o: %.cpp $(HEADERS) headers.h.gch\n  g++ -c $(CFLAGS) -DGUI -o $@ $<\n \n cryptopp/obj/%.o: cryptopp/%.cpp\n- g++ -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_SSE2 -o $@ $<\n+ g++ -c $(CFLAGS) -frename-registers -funroll-all-loops -fomit-frame-pointer  -march=native -msse2 -msse3  -ffast-math -O3 -o $@ $<\n \n bitcoin: $(OBJS) obj/ui.o obj/uibase.o\n  g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)\n \n-\n obj/nogui/%.o: %.cpp $(HEADERS)\n  g++ -c $(CFLAGS) -o $@ $<\n \n bitcoind: $(OBJS:obj/%=obj/nogui/%)\n  g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(LIBS)\n \n+test: cryptopp/obj/sha.o cryptopp/obj/sha256.o test.cpp\n+   g++ $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)\n+\n \n clean:\n  -rm -f obj/*.o\ndiff --git a/test.cpp b/test.cpp\nnew file mode 100755\nindex 0000000..7cab332\n--- /dev/null\n+++ b/test.cpp\n@@ -0,0 +1,237 @@\n+// Copyright (c) 2009-2010 Satoshi Nakamoto\n+// Distributed under the MIT/X11 software license, see the accompanying\n+// file license.txt or http://www.opensource.org/licenses/mit-license.php.\n+#include <assert.h>\n+#include <openssl/ecdsa.h>\n+#include <openssl/evp.h>\n+#include <openssl/rand.h>\n+#include <openssl/sha.h>\n+#include <openssl/ripemd.h>\n+#include <db_cxx.h>\n+#include <stdio.h>\n+#include <stdlib.h>\n+#include <math.h>\n+#include <limits.h>\n+#include <float.h>\n+#include <assert.h>\n+#include <memory>\n+#include <iostream>\n+#include <sstream>\n+#include <string>\n+#include <vector>\n+#include <list>\n+#include <deque>\n+#include <map>\n+#include <set>\n+#include <algorithm>\n+#include <numeric>\n+#include <boost/foreach.hpp>\n+#include <boost/lexical_cast.hpp>\n+#include <boost/tuple/tuple.hpp>\n+#include <boost/fusion/container/vector.hpp>\n+#include <boost/tuple/tuple_comparison.hpp>\n+#include <boost/tuple/tuple_io.hpp>\n+#include <boost/array.hpp>\n+#include <boost/bind.hpp>\n+#include <boost/function.hpp>\n+#include <boost/filesystem.hpp>\n+#include <boost/filesystem/fstream.hpp>\n+#include <boost/algorithm/string.hpp>\n+#include <boost/interprocess/sync/interprocess_mutex.hpp>\n+#include <boost/interprocess/sync/interprocess_recursive_mutex.hpp>\n+#include <boost/date_time/gregorian/gregorian_types.hpp>\n+#include <boost/date_time/posix_time/posix_time_types.hpp>\n+#include <sys/resource.h>\n+#include <sys/time.h>\n+using namespace std;\n+using namespace boost;\n+#include \"cryptopp/sha.h\"\n+#include \"strlcpy.h\"\n+#include \"serialize.h\"\n+#include \"uint256.h\"\n+#include \"bignum.h\"\n+\n+#undef printf\n+ template <size_t nBytes, typename T>\n+T* alignup(T* p)\n+{\n+ union\n+ {   \n+  T* ptr;\n+  size_t n;\n+ } u;\n+ u.ptr = p;\n+ u.n = (u.n + (nBytes-1)) & ~(nBytes-1);\n+ return u.ptr;\n+}\n+\n+int FormatHashBlocks(void* pbuffer, unsigned int len)\n+{\n+ unsigned char* pdata = (unsigned char*)pbuffer;\n+ unsigned int blocks = 1 + ((len + 8) / 64);\n+ unsigned char* pend = pdata + 64 * blocks;\n+ memset(pdata + len, 0, 64 * blocks - len);\n+ pdata[len] = 0x80;\n+ unsigned int bits = len * 8;\n+ pend[-1] = (bits >> 0) & 0xff;\n+ pend[-2] = (bits >> 8) & 0xff;\n+ pend[-3] = (bits >> 16) & 0xff;\n+ pend[-4] = (bits >> 24) & 0xff;\n+ return blocks;\n+}\n+\n+using CryptoPP::ByteReverse;\n+static int detectlittleendian = 1;\n+\n+#define NPAR 32\n+\n+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[8][NPAR], const void *init2);\n+\n+using CryptoPP::ByteReverse;\n+\n+static const unsigned int pSHA256InitState[8] = {0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19};\n+\n+inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)\n+{\n+ memcpy(pstate, pinit, 32);\n+ CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);\n+}\n+\n+void BitcoinTester(char *filename)\n+{\n+ printf(\"SHA256 test started\");\n+\n+ struct tmpworkspace\n+ {\n+  struct unnamed2\n+  {\n+   int nVersion;\n+   uint256 hashPrevBlock;\n+   uint256 hashMerkleRoot;\n+   unsigned int nTime;\n+   unsigned int nBits;\n+   unsigned int nNonce;\n+  }\n+  block;\n+  unsigned char pchPadding0[64];\n+  uint256 hash1;\n+  unsigned char pchPadding1[64];\n+ };\n+ char tmpbuf[sizeof(tmpworkspace)+16];\n+ tmpworkspace& tmp = *(tmpworkspace*)alignup<16>(tmpbuf);\n+\n+\n+ char line[180];\n+ ifstream fin(filename);\n+ char *p;\n+ unsigned long int totalhashes= 0;\n+ unsigned long int found = 0;\n+ clock_t start, end;\n+ unsigned long int cpu_time_used;\n+ unsigned int tnonce;\n+ start = clock();\n+\n+ while( fin.getline(line, 180))\n+ {\n+  string in(line);\n+  //printf(\"%s\", in.c_str());\n+  tmp.block.nVersion       = strtol(in.substr(0,8).c_str(), &p, 16);\n+  tmp.block.hashPrevBlock.SetHex(in.substr(8,64));\n+  tmp.block.hashMerkleRoot.SetHex(in.substr(64+8,64));\n+  tmp.block.nTime          = strtol(in.substr(128+8,8).c_str(), &p, 16);\n+  tmp.block.nBits          = strtol(in.substr(128+16,8).c_str(), &p, 16);\n+  tnonce = strtol(in.substr(128+24,8).c_str(), &p, 16);\n+  tmp.block.nNonce         = tnonce;\n+\n+  unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));\n+  unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));\n+\n+  // Byte swap all the input buffer\n+  for (int i = 0; i < sizeof(tmp)/4; i++)\n+   ((unsigned int*)&tmp)[i] = ByteReverse(((unsigned int*)&tmp)[i]);\n+\n+  // Precalc the first half of the first hash, which stays constant\n+  uint256 midstatebuf[2];\n+  uint256& midstate = *alignup<16>(midstatebuf);\n+  SHA256Transform(&midstate, &tmp.block, pSHA256InitState);\n+\n+\n+  uint256 hashTarget = CBigNum().SetCompact(ByteReverse(tmp.block.nBits)).getuint256();\n+  // printf(\"target %s\", hashTarget.GetHex().c_str());\n+  uint256 hash;\n+  uint256 hashbuf[2];\n+  uint256& refhash = *alignup<16>(hashbuf);\n+\n+  unsigned int thash[8][NPAR];\n+  int done = 0;\n+  unsigned int i, j;\n+\n+  /* reference */\n+  SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);\n+  SHA256Transform(&refhash, &tmp.hash1, pSHA256InitState);\n+  for (int i = 0; i < sizeof(refhash)/4; i++)\n+   ((unsigned int*)&refhash)[i] = ByteReverse(((unsigned int*)&refhash)[i]);\n+\n+  //printf(\"reference nonce %08x:%s\", tnonce, refhash.GetHex().c_str());\n+\n+  tmp.block.nNonce = ByteReverse(tnonce) & 0xfffff000;\n+\n+\n+  for(;;)\n+  {\n+\n+   Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);\n+\n+   for(i = 0; i<NPAR; i++) {\n+    /* fast hash checking */\n+    if(thash[7][i] == 0) {\n+   //  printf(\"found something... \");\n+\n+     for(j = 0; j<8; j++) ((unsigned int *)&hash)[j] = ByteReverse((unsigned int)thash[j][i]);\n+    // printf(\"%s\", hash.GetHex().c_str());\n+\n+     if (hash <= hashTarget)\n+     {\n+      found++;\n+      if(tnonce == ByteReverse(tmp.block.nNonce + i) ) {\n+       if(hash == refhash) {\n+        printf(\"\r%lu\", found);\n+        totalhashes += NPAR;\n+        done = 1;\n+       } else {\n+        printf(\"Hashes do not match!\");\n+       }\n+      } else {\n+       printf(\"nonce does not match. %08x != %08x\", tnonce, ByteReverse(tmp.block.nNonce + i));\n+      }\n+      break;\n+     }\n+    }\n+   }\n+   if(done) break;\n+\n+   tmp.block.nNonce+=NPAR;\n+   totalhashes += NPAR;\n+   if(tmp.block.nNonce == 0) {\n+    printf(\"ERROR: Hash not found for:%s\", in.c_str());\n+    return;\n+   }\n+  }\n+ }\n+ printf(\"\");\n+ end = clock();\n+ cpu_time_used += (unsigned int)(end - start);\n+ cpu_time_used /= ((CLOCKS_PER_SEC)/1000);\n+ printf(\"found solutions = %lu\", found);\n+ printf(\"total hashes = %lu\", totalhashes);\n+ printf(\"total time = %lu ms\", cpu_time_used);\n+ printf(\"average speed: %lu khash/s\", (totalhashes)/cpu_time_used);\n+}\n+\n+int main(int argc, char* argv[]) {\n+ if(argc == 2) {\n+  BitcoinTester(argv[1]);\n+ } else\n+  printf(\"Missing filename!\");\n+ return 0;\n+}"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6831#msg6831"},{"f":"nelisky","d":1280603837,"b":[["t","Had to manually patch, as I'm not using git for bitcoin and 'patch' doesn't munch this format, I guess. Anyway, got almost double speed on the OSX side, (i5 2.4, now ~2400 from ~1400), but my linux on Q6600 quad 2.4Ghz was pumping ~2500 with 0.3.6 (from source) and now, with the patch it's... ~2400. Need I tweak anything to take advantage on this?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6841#msg6841"},{"f":"nelisky","d":1280608446,"b":[["t","ahm, let me correct myself: on the quad core linux, I went from ~4400 with svn trunk @ 119 to ~2400 with the patch... not exactly what I hoped for after the success in OSX."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6850#msg6850"},{"f":"aceat64","d":1280609869,"b":[["q","ahm, let me correct myself: on the quad core linux, I went from ~4400 with svn trunk @ 119 to ~2400 with the patch... not exactly what I hoped for after the success in OSX.","Quote from: nelisky on July 31, 2010, 08:34:06 PM"],["t","I noticed the same, I went from about 4300 to 2100 when I tested it on Linux."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6853#msg6853"},{"f":"tcatm","d":1280615909,"b":[["t","What CPUs are you running it on? Could you send me sha256.o (compiled object of the algorithm)?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6861#msg6861"},{"f":"nelisky","d":1280618287,"b":[["t","I'm running on the Intel Q6600 2.4Ghz, how shall I get the file to you?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6866#msg6866"},{"f":"Mionione","d":1280619011,"b":[["t","care with __attribute__ ((aligned (16))) , it doesn't work with local variable, gcc doesn't align the stack"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6867#msg6867"},{"f":"tcatm","d":1280619422,"b":[["q","I'm running on the Intel Q6600 2.4Ghz, how shall I get the file to you?","Quote from: nelisky on July 31, 2010, 11:18:07 PM"],["t","yes. i will look at the assembler code. maybe the compiler did something \"wrong\"."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6868#msg6868"},{"f":"tcatm","d":1280620810,"b":[["t","Patch against SVN. Maybe it'll work now..."],["c","diff --git a/cryptopp/sha256.cpp b/cryptopp/sha256.cpp\nnew file mode 100644\nindex 0000000..6735678\n--- /dev/null\n+++ b/cryptopp/sha256.cpp\n@@ -0,0 +1,447 @@\n+#include <string.h>\n+#include <assert.h>\n+\n+#include <xmmintrin.h>\n+#include <stdint.h>\n+#include <stdio.h>\n+\n+#define NPAR 32\n+\n+static const unsigned int sha256_consts[] = {\n+ 0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, /*  0 */\n+ 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,\n+ 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, /*  8 */\n+ 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,\n+ 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, /* 16 */\n+ 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,\n+ 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, /* 24 */\n+ 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,\n+ 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, /* 32 */\n+ 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,\n+ 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, /* 40 */\n+ 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,\n+ 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, /* 48 */\n+ 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,\n+ 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, /* 56 */\n+ 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2\n+};\n+\n+\n+static inline __m128i Ch(const __m128i b, const __m128i c, const __m128i d) {\n+ return (b & c) ^ (~b & d);\n+}\n+\n+static inline __m128i Maj(const __m128i b, const __m128i c, const __m128i d) {\n+ return (b & c) ^ (b & d) ^ (c & d);\n+}\n+\n+static inline __m128i ROTR(__m128i x, const int n) {\n+ return _mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n);\n+}\n+\n+static inline __m128i SHR(__m128i x, const int n) {\n+ return _mm_srli_epi32(x, n);\n+}\n+\n+/* SHA256 Functions */\n+#define BIGSIGMA0_256(x) (ROTR((x), 2) ^ ROTR((x), 13) ^ ROTR((x), 22))\n+#define BIGSIGMA1_256(x) (ROTR((x), 6) ^ ROTR((x), 11) ^ ROTR((x), 25))\n+#define SIGMA0_256(x)  (ROTR((x), 7) ^ ROTR((x), 18) ^ SHR((x), 3))\n+#define SIGMA1_256(x)  (ROTR((x), 17) ^ ROTR((x), 19) ^ SHR((x), 10))\n+\n+static inline __m128i load_epi32(const unsigned int x0, const unsigned int x1, const unsigned int x2, const unsigned int x3) {\n+ return _mm_set_epi32(x0, x1, x2, x3);\n+}\n+\n+static inline unsigned int store32(const __m128i x, int i) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x;\n+ return box.ret[i];\n+}\n+\n+static inline void store_epi32(const __m128i x, unsigned int *x0, unsigned int *x1, unsigned int *x2, unsigned int *x3) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x;\n+ *x0 = box.ret[3]; *x1 = box.ret[2]; *x2 = box.ret[1]; *x3 = box.ret[0];\n+}\n+\n+static inline __m128i SHA256_CONST(const int i) {\n+ return _mm_set1_epi32(sha256_consts[i]);\n+}\n+\n+#define add4(x0, x1, x2, x3) _mm_add_epi32(_mm_add_epi32(_mm_add_epi32(x0, x1), x2), x3)\n+#define add5(x0, x1, x2, x3, x4) _mm_add_epi32(add4(x0, x1, x2, x3), x4)\n+\n+#define SHA256ROUND(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+d = _mm_add_epi32(d, T1);                                           \\\n+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \\\n+h = _mm_add_epi32(T1, T2);\n+\n+#define SHA256ROUND_lastd(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+d = _mm_add_epi32(d, T1);                                           \n+//T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \n+//h = _mm_add_epi32(T1, T2);\n+\n+#define SHA256ROUND_last(a, b, c, d, e, f, g, h, i, w)                       \\\n+ T1 = add5(h, BIGSIGMA1_256(e), Ch(e, f, g), SHA256_CONST(i), w); \\\n+T2 = _mm_add_epi32(BIGSIGMA0_256(a), Maj(a, b, c));                 \\\n+h = _mm_add_epi32(T1, T2);\n+\n+static inline unsigned int swap(unsigned int value) {\n+ __asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));\n+ return value;\n+}\n+\n+static inline unsigned int SWAP32(const void *addr) {\n+ unsigned int value = (*((unsigned int *)(addr)));\n+ __asm__ (\"bswap %0\" : \"=r\" (value) : \"0\" (value));\n+ return value;\n+}\n+\n+static inline void dumpreg(__m128i x, char *msg) {\n+ union { unsigned int ret[4]; __m128i x; } box;\n+ box.x = x ;\n+ printf(\"%s %08x %08x %08x %08x\", msg, box.ret[0], box.ret[1], box.ret[2], box.ret[3]);\n+}\n+\n+#if 1\n+#define dumpstate(i) printf(\"%s: %08x %08x %08x %08x %08x %08x %08x %08x %08x\", \\\n+  __func__, store32(w0, i), store32(a, i), store32(b, i), store32(c, i), store32(d, i), store32(e, i), store32(f, i), store32(g, i), store32(h, i));\n+#else\n+#define dumpstate()\n+#endif\n+void Double_BlockSHA256(const void* pin, void* pad, const void *pre, unsigned int thash[9][NPAR], const void *init)\n+{\n+ unsigned int* In = (unsigned int*)pin;\n+ unsigned int* Pad = (unsigned int*)pad;\n+ unsigned int* hPre = (unsigned int*)pre;\n+ unsigned int* hInit = (unsigned int*)init;\n+ unsigned int i, j, k;\n+\n+ /* vectors used in calculation */\n+ __m128i w0, w1, w2, w3, w4, w5, w6, w7;\n+ __m128i w8, w9, w10, w11, w12, w13, w14, w15;\n+ __m128i T1, T2;\n+ __m128i a, b, c, d, e, f, g, h;\n+  __m128i nonce;\n+\n+ /* nonce offset for vector */\n+ __m128i offset = load_epi32(0x00000003, 0x00000002, 0x00000001, 0x00000000);\n+\n+\n+ for(k = 0; k<NPAR; k+=4) {\n+  w0 = load_epi32(In[0], In[0], In[0], In[0]);\n+  w1 = load_epi32(In[1], In[1], In[1], In[1]);\n+  w2 = load_epi32(In[2], In[2], In[2], In[2]);\n+  //w3 = load_epi32(In[3], In[3], In[3], In[3]); nonce will be later hacked into the hash\n+  w4 = load_epi32(In[4], In[4], In[4], In[4]);\n+  w5 = load_epi32(In[5], In[5], In[5], In[5]);\n+  w6 = load_epi32(In[6], In[6], In[6], In[6]);\n+  w7 = load_epi32(In[7], In[7], In[7], In[7]);\n+  w8 = load_epi32(In[8], In[8], In[8], In[8]);\n+  w9 = load_epi32(In[9], In[9], In[9], In[9]);\n+  w10 = load_epi32(In[10], In[10], In[10], In[10]);\n+  w11 = load_epi32(In[11], In[11], In[11], In[11]);\n+  w12 = load_epi32(In[12], In[12], In[12], In[12]);\n+  w13 = load_epi32(In[13], In[13], In[13], In[13]);\n+  w14 = load_epi32(In[14], In[14], In[14], In[14]);\n+  w15 = load_epi32(In[15], In[15], In[15], In[15]);\n+\n+  /* hack nonce into lowest byte of w3 */\n+  nonce = load_epi32(In[3], In[3], In[3], In[3]);\n+  __m128i k_vec = load_epi32(k, k, k, k);\n+  nonce = _mm_add_epi32(nonce, offset);\n+  nonce = _mm_add_epi32(nonce, k_vec);\n+    w3 = nonce;\n+\n+  a = load_epi32(hPre[0], hPre[0], hPre[0], hPre[0]);\n+  b = load_epi32(hPre[1], hPre[1], hPre[1], hPre[1]);\n+  c = load_epi32(hPre[2], hPre[2], hPre[2], hPre[2]);\n+  d = load_epi32(hPre[3], hPre[3], hPre[3], hPre[3]);\n+  e = load_epi32(hPre[4], hPre[4], hPre[4], hPre[4]);\n+  f = load_epi32(hPre[5], hPre[5], hPre[5], hPre[5]);\n+  g = load_epi32(hPre[6], hPre[6], hPre[6], hPre[6]);\n+  h = load_epi32(hPre[7], hPre[7], hPre[7], hPre[7]);\n+\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);   \n+  SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);\n+\n+#define store_load(x, i, dest) \\\n+  w8 = load_epi32((hPre)[i], (hPre)[i], (hPre)[i], (hPre)[i]); \\\n+  dest = _mm_add_epi32(w8, x);\n+\n+  store_load(a, 0, w0);\n+  store_load(b, 1, w1);\n+  store_load(c, 2, w2);\n+  store_load(d, 3, w3);\n+  store_load(e, 4, w4);\n+  store_load(f, 5, w5);\n+  store_load(g, 6, w6);\n+  store_load(h, 7, w7);\n+\n+  w8 = load_epi32(Pad[8], Pad[8], Pad[8], Pad[8]);\n+  w9 = load_epi32(Pad[9], Pad[9], Pad[9], Pad[9]);\n+  w10 = load_epi32(Pad[10], Pad[10], Pad[10], Pad[10]);\n+  w11 = load_epi32(Pad[11], Pad[11], Pad[11], Pad[11]);\n+  w12 = load_epi32(Pad[12], Pad[12], Pad[12], Pad[12]);\n+  w13 = load_epi32(Pad[13], Pad[13], Pad[13], Pad[13]);\n+  w14 = load_epi32(Pad[14], Pad[14], Pad[14], Pad[14]);\n+  w15 = load_epi32(Pad[15], Pad[15], Pad[15], Pad[15]);\n+\n+  a = load_epi32(hInit[0], hInit[0], hInit[0], hInit[0]);\n+  b = load_epi32(hInit[1], hInit[1], hInit[1], hInit[1]);\n+  c = load_epi32(hInit[2], hInit[2], hInit[2], hInit[2]);\n+  d = load_epi32(hInit[3], hInit[3], hInit[3], hInit[3]);\n+  e = load_epi32(hInit[4], hInit[4], hInit[4], hInit[4]);\n+  f = load_epi32(hInit[5], hInit[5], hInit[5], hInit[5]);\n+  g = load_epi32(hInit[6], hInit[6], hInit[6], hInit[6]);\n+  h = load_epi32(hInit[7], hInit[7], hInit[7], hInit[7]);\n+\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 0, w0);   \n+  SHA256ROUND(h, a, b, c, d, e, f, g, 1, w1);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 2, w2);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 3, w3);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 4, w4);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 5, w5);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 6, w6);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 7, w7);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 8, w8);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 9, w9);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 10, w10);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 11, w11);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 12, w12);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 13, w13);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 14, w14);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 15, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 16, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 17, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 18, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 19, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 20, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 21, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 22, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 23, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 24, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 25, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 26, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 27, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 28, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 29, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 30, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 31, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 32, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 33, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 34, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 35, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 36, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 37, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 38, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 39, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 40, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 41, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 42, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 43, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 44, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 45, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 46, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 47, w15);\n+\n+  w0 = add4(SIGMA1_256(w14), w9, SIGMA0_256(w1), w0);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 48, w0);\n+  w1 = add4(SIGMA1_256(w15), w10, SIGMA0_256(w2), w1);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 49, w1);\n+  w2 = add4(SIGMA1_256(w0), w11, SIGMA0_256(w3), w2);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 50, w2);\n+  w3 = add4(SIGMA1_256(w1), w12, SIGMA0_256(w4), w3);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 51, w3);\n+  w4 = add4(SIGMA1_256(w2), w13, SIGMA0_256(w5), w4);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 52, w4);\n+  w5 = add4(SIGMA1_256(w3), w14, SIGMA0_256(w6), w5);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 53, w5);\n+  w6 = add4(SIGMA1_256(w4), w15, SIGMA0_256(w7), w6);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 54, w6);\n+  w7 = add4(SIGMA1_256(w5), w0, SIGMA0_256(w8), w7);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 55, w7);\n+  w8 = add4(SIGMA1_256(w6), w1, SIGMA0_256(w9), w8);\n+  SHA256ROUND(a, b, c, d, e, f, g, h, 56, w8);\n+  w9 = add4(SIGMA1_256(w7), w2, SIGMA0_256(w10), w9);\n+  SHA256ROUND(h, a, b, c, d, e, f, g, 57, w9);\n+  w10 = add4(SIGMA1_256(w8), w3, SIGMA0_256(w11), w10);\n+  SHA256ROUND(g, h, a, b, c, d, e, f, 58, w10);\n+  w11 = add4(SIGMA1_256(w9), w4, SIGMA0_256(w12), w11);\n+  SHA256ROUND(f, g, h, a, b, c, d, e, 59, w11);\n+  w12 = add4(SIGMA1_256(w10), w5, SIGMA0_256(w13), w12);\n+  SHA256ROUND(e, f, g, h, a, b, c, d, 60, w12);\n+  w13 = add4(SIGMA1_256(w11), w6, SIGMA0_256(w14), w13);\n+  SHA256ROUND(d, e, f, g, h, a, b, c, 61, w13);\n+  w14 = add4(SIGMA1_256(w12), w7, SIGMA0_256(w15), w14);\n+  SHA256ROUND(c, d, e, f, g, h, a, b, 62, w14);\n+  w15 = add4(SIGMA1_256(w13), w8, SIGMA0_256(w0), w15);\n+  SHA256ROUND(b, c, d, e, f, g, h, a, 63, w15);\n+\n+  /* store resulsts directly in thash */\n+#define store_2(x,i)  \\\n+  w0 = load_epi32((hInit)[i], (hInit)[i], (hInit)[i], (hInit)[i]); \\\n+  *(__m128i *)&(thash)[i][0+k] = _mm_add_epi32(w0, x);\n+\n+  store_2(a, 0);\n+  store_2(b, 1);\n+  store_2(c, 2);\n+  store_2(d, 3);\n+  store_2(e, 4);\n+  store_2(f, 5);\n+  store_2(g, 6);\n+  store_2(h, 7);\n+  *(__m128i *)&(thash)[8][0+k] = nonce;\n+ }\n+\n+}\ndiff --git a/main.cpp b/main.cpp\nindex 0239915..50db1a3 100644\n--- a/main.cpp\n+++ b/main.cpp\n@@ -2555,8 +2555,10 @@ inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)\n     CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);\n }\n \n+// !!!! NPAR must match NPAR in cryptopp/sha256.cpp !!!!\n+#define NPAR 32\n \n-\n+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[9][NPAR], const void *init2);\n \n \n void BitcoinMiner()\n@@ -2701,108 +2703,128 @@ void BitcoinMiner()\n         uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();\n         uint256 hashbuf[2];\n         uint256& hash = *alignup<16>(hashbuf);\n+\n+        // Cache for NPAR hashes\n+        unsigned int thash[9][NPAR] __attribute__ ((aligned (16)));\n+\n+        unsigned int j;\n         loop\n         {\n-            SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);\n-            SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);\n+          Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);\n \n-            if (((unsigned short*)&hash)[14] == 0)\n+          for(j = 0; j<NPAR; j++) {\n+            if (thash[7][j] == 0)\n             {\n-                // Byte swap the result after preliminary check\n-                for (int i = 0; i < sizeof(hash)/4; i++)\n-                    ((unsigned int*)&hash)[i] = ByteReverse(((unsigned int*)&hash)[i]);\n-\n-                if (hash <= hashTarget)\n+              // Byte swap the result after preliminary check\n+              for (int i = 0; i < sizeof(hash)/4; i++)\n+                ((unsigned int*)&hash)[i] = ByteReverse((unsigned int)thash[i][j]);\n+\n+              if (hash <= hashTarget)\n+              {\n+                // Double_BlocSHA256 might only calculate parts of the hash.\n+                // We'll insert the nonce and get the real hash.\n+                //pblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n+                //hash = pblock->GetHash();\n+\n+                /* get nonce from hash */\n+                pblock->nNonce = ByteReverse((unsigned int)thash[8][j]);\n+                assert(hash == pblock->GetHash());\n+\n+                //// debug print\n+                printf(\"BitcoinMiner:\");\n+                printf(\"proof-of-work found    hash: %s  target: %s\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());\n+                pblock->print();\n+                printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n+                printf(\"generated %s\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());\n+\n+                SetThreadPriority(THREAD_PRIORITY_NORMAL);\n+                CRITICAL_BLOCK(cs_main)\n                 {\n-                    pblock->nNonce = ByteReverse(tmp.block.nNonce);\n-                    assert(hash == pblock->GetHash());\n-\n-                        //// debug print\n-                        printf(\"BitcoinMiner:\");\n-                        printf(\"proof-of-work found    hash: %s  target: %s\", hash.GetHex().c_str(), hashTarget.GetHex().c_str());\n-                        pblock->print();\n-                        printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n-                        printf(\"generated %s\", FormatMoney(pblock->vtx[0].vout[0].nValue).c_str());\n-\n-                    SetThreadPriority(THREAD_PRIORITY_NORMAL);\n-                    CRITICAL_BLOCK(cs_main)\n-                    {\n-                        if (pindexPrev == pindexBest)\n-                        {\n-                            // Save key\n-                            if (!AddKey(key))\n-                                return;\n-                            key.MakeNewKey();\n-\n-                            // Track how many getdata requests this block gets\n-                            CRITICAL_BLOCK(cs_mapRequestCount)\n-                                mapRequestCount[pblock->GetHash()] = 0;\n-\n-                            // Process this block the same as if we had received it from another node\n-                            if (!ProcessBlock(NULL, pblock.release()))\n-                                printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\");\n-                        }\n+                  if (pindexPrev == pindexBest)\n+                  {\n+                    // Save key\n+                    if (!AddKey(key))\n+                      return;\n+                    key.MakeNewKey();\n+\n+                    // Track how many getdata requests this block gets\n+                    CRITICAL_BLOCK(cs_mapRequestCount)\n+                      mapRequestCount[pblock->GetHash()] = 0;\n+\n+                    // Process this block the same as if we had received it from another node\n+                    if (!ProcessBlock(NULL, pblock.release()))\n+                      printf(\"ERROR in BitcoinMiner, ProcessBlock, block not accepted\");\n+\n                     }\n                     SetThreadPriority(THREAD_PRIORITY_LOWEST);\n \n                     Sleep(500);\n                     break;\n                 }\n-            }\n+                SetThreadPriority(THREAD_PRIORITY_LOWEST);\n \n-            // Update nTime every few seconds\n-            const unsigned int nMask = 0xffff;\n-            if ((++tmp.block.nNonce & nMask) == 0)\n+                Sleep(500);\n+                break;\n+              }\n+            }\n+          }\n+\n+          // Update nonce\n+          tmp.block.nNonce += NPAR;\n+\n+          // Update nTime every few seconds\n+          const unsigned int nMask = 0xffff;\n+          if ((tmp.block.nNonce & nMask) == 0)\n+          {\n+            // Meter hashes/sec\n+            static int64 nTimerStart;\n+            static int nHashCounter;\n+            if (nTimerStart == 0)\n+              nTimerStart = GetTimeMillis();\n+            else\n+              nHashCounter++;\n+            if (GetTimeMillis() - nTimerStart > 4000)\n             {\n-                // Meter hashes/sec\n-                static int64 nTimerStart;\n-                static int nHashCounter;\n-                if (nTimerStart == 0)\n-                    nTimerStart = GetTimeMillis();\n-                else\n-                    nHashCounter++;\n+              static CCriticalSection cs;\n+              CRITICAL_BLOCK(cs)\n+              {\n                 if (GetTimeMillis() - nTimerStart > 4000)\n                 {\n-                    static CCriticalSection cs;\n-                    CRITICAL_BLOCK(cs)\n-                    {\n-                        if (GetTimeMillis() - nTimerStart > 4000)\n-                        {\n-                            double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);\n-                            nTimerStart = GetTimeMillis();\n-                            nHashCounter = 0;\n-                            string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/1000.0);\n-                            UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));\n-                            static int64 nLogTime;\n-                            if (GetTime() - nLogTime > 30 * 60)\n-                            {\n-                                nLogTime = GetTime();\n-                                printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n-                                printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/1000.0);\n-                            }\n-                        }\n-                    }\n+                  double dHashesPerSec = 1000.0 * (nMask+1) * nHashCounter / (GetTimeMillis() - nTimerStart);\n+                  nTimerStart = GetTimeMillis();\n+                  nHashCounter = 0;\n+                  string strStatus = strprintf(\"    %.0f khash/s\", dHashesPerSec/1000.0);\n+                  UIThreadCall(bind(CalledSetStatusBar, strStatus, 0));\n+                  static int64 nLogTime;\n+                  if (GetTime() - nLogTime > 30 * 60)\n+                  {\n+                    nLogTime = GetTime();\n+                    printf(\"%s \", DateTimeStrFormat(\"%x %H:%M\", GetTime()).c_str());\n+                    printf(\"hashmeter %3d CPUs %6.0f khash/s\", vnThreadsRunning[3], dHashesPerSec/1000.0);\n+                  }\n                 }\n-\n-                // Check for stop or if block needs to be rebuilt\n-                if (fShutdown)\n-                    return;\n-                if (!fGenerateBitcoins)\n-                    return;\n-                if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)\n-                    return;\n-                if (vNodes.empty())\n-                    break;\n-                if (tmp.block.nNonce == 0)\n-                    break;\n-                if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)\n-                    break;\n-                if (pindexPrev != pindexBest)\n-                    break;\n-\n-                pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());\n-                tmp.block.nTime = ByteReverse(pblock->nTime);\n+              }\n             }\n+\n+            // Check for stop or if block needs to be rebuilt\n+            if (fShutdown)\n+              return;\n+            if (!fGenerateBitcoins)\n+              return;\n+            if (fLimitProcessors && vnThreadsRunning[3] > nLimitProcessors)\n+              return;\n+            if (vNodes.empty())\n+              break;\n+            if (tmp.block.nNonce == 0)\n+              break;\n+            if (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60)\n+              break;\n+            if (pindexPrev != pindexBest)\n+              break;\n+\n+            pblock->nTime = max(pindexPrev->GetMedianTimePast()+1, GetAdjustedTime());\n+            tmp.block.nTime = ByteReverse(pblock->nTime);\n+          }\n         }\n     }\n }\ndiff --git a/makefile.unix b/makefile.unix\nindex e965287..04dac86 100644\n--- a/makefile.unix\n+++ b/makefile.unix\n@@ -41,7 +41,8 @@ OBJS= \\\n     obj/rpc.o \\\n     obj/init.o \\\n     cryptopp/obj/sha.o \\\n-    cryptopp/obj/cpu.o\n+    cryptopp/obj/cpu.o \\\n+    cryptopp/obj/sha256.o\n \n \n all: bitcoin\n@@ -51,7 +52,7 @@ obj/%.o: %.cpp $(HEADERS)\n  g++ -c $(CFLAGS) -DGUI -o $@ $<\n \n cryptopp/obj/%.o: cryptopp/%.cpp\n- g++ -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_SSE2 -o $@ $<\n+ g++ -c $(CFLAGS) -frename-registers -funroll-all-loops -fomit-frame-pointer  -march=native -msse2 -msse3  -ffast-math -O3 -o $@ $<\n \n bitcoin: $(OBJS) obj/ui.o obj/uibase.o\n  g++ $(CFLAGS) -o $@ $^ $(WXLIBS) $(LIBS)\n@@ -63,6 +64,9 @@ obj/nogui/%.o: %.cpp $(HEADERS)\n bitcoind: $(OBJS:obj/%=obj/nogui/%)\n  g++ $(CFLAGS) -o $@ $^ $(LIBS)\n \n+test: cryptopp/obj/sha.o cryptopp/obj/sha256.o test.cpp\n+ g++ $(CFLAGS) -o $@ $^ $(LIBS)\n+\n \n clean:\n  -rm -f obj/*.o\ndiff --git a/test.cpp b/test.cpp\nnew file mode 100644\nindex 0000000..a55e972\n--- /dev/null\n+++ b/test.cpp\n@@ -0,0 +1,221 @@\n+// Copyright (c) 2009-2010 Satoshi Nakamoto\n+// Distributed under the MIT/X11 software license, see the accompanying\n+// file license.txt or http://www.opensource.org/licenses/mit-license.php.\n+#include <assert.h>\n+#include <openssl/ecdsa.h>\n+#include <openssl/evp.h>\n+#include <openssl/rand.h>\n+#include <openssl/sha.h>\n+#include <openssl/ripemd.h>\n+#include <db_cxx.h>\n+#include <stdio.h>\n+#include <stdlib.h>\n+#include <math.h>\n+#include <limits.h>\n+#include <float.h>\n+#include <assert.h>\n+#include <memory>\n+#include <iostream>\n+#include <sstream>\n+#include <string>\n+#include <vector>\n+#include <list>\n+#include <deque>\n+#include <map>\n+#include <set>\n+#include <algorithm>\n+#include <numeric>\n+#include <boost/foreach.hpp>\n+#include <boost/lexical_cast.hpp>\n+#include <boost/tuple/tuple.hpp>\n+#include <boost/fusion/container/vector.hpp>\n+#include <boost/tuple/tuple_comparison.hpp>\n+#include <boost/tuple/tuple_io.hpp>\n+#include <boost/array.hpp>\n+#include <boost/bind.hpp>\n+#include <boost/function.hpp>\n+#include <boost/filesystem.hpp>\n+#include <boost/filesystem/fstream.hpp>\n+#include <boost/algorithm/string.hpp>\n+#include <boost/interprocess/sync/interprocess_mutex.hpp>\n+#include <boost/interprocess/sync/interprocess_recursive_mutex.hpp>\n+#include <boost/date_time/gregorian/gregorian_types.hpp>\n+#include <boost/date_time/posix_time/posix_time_types.hpp>\n+#include <sys/resource.h>\n+#include <sys/time.h>\n+using namespace std;\n+using namespace boost;\n+#include \"cryptopp/sha.h\"\n+#include \"strlcpy.h\"\n+#include \"serialize.h\"\n+#include \"uint256.h\"\n+#include \"bignum.h\"\n+\n+#undef printf\n+\n+int FormatHashBlocks(void* pbuffer, unsigned int len)\n+{\n+ unsigned char* pdata = (unsigned char*)pbuffer;\n+ unsigned int blocks = 1 + ((len + 8) / 64);\n+ unsigned char* pend = pdata + 64 * blocks;\n+ memset(pdata + len, 0, 64 * blocks - len);\n+ pdata[len] = 0x80;\n+ unsigned int bits = len * 8;\n+ pend[-1] = (bits >> 0) & 0xff;\n+ pend[-2] = (bits >> 8) & 0xff;\n+ pend[-3] = (bits >> 16) & 0xff;\n+ pend[-4] = (bits >> 24) & 0xff;\n+ return blocks;\n+}\n+\n+using CryptoPP::ByteReverse;\n+static int detectlittleendian = 1;\n+\n+#define NPAR 32\n+\n+extern void Double_BlockSHA256(const void* pin, void* pout, const void *pinit, unsigned int hash[9][NPAR], const void *init2);\n+\n+using CryptoPP::ByteReverse;\n+\n+static const unsigned int pSHA256InitState[8] = {0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19};\n+\n+inline void SHA256Transform(void* pstate, void* pinput, const void* pinit)\n+{\n+ memcpy(pstate, pinit, 32);\n+ CryptoPP::SHA256::Transform((CryptoPP::word32*)pstate, (CryptoPP::word32*)pinput);\n+}\n+\n+void BitcoinTester(char *filename)\n+{\n+ printf(\"SHA256 test started\");\n+\n+ struct tmpworkspace\n+ {\n+  struct unnamed2\n+  {\n+   int nVersion;\n+   uint256 hashPrevBlock;\n+   uint256 hashMerkleRoot;\n+   unsigned int nTime;\n+   unsigned int nBits;\n+   unsigned int nNonce;\n+  }\n+  block;\n+  unsigned char pchPadding0[64];\n+  uint256 hash1;\n+  unsigned char pchPadding1[64];\n+ }\n+  tmp __attribute__ ((aligned (16)));\n+\n+ char line[180];\n+ ifstream fin(filename);\n+ char *p;\n+ unsigned long int totalhashes= 0;\n+ unsigned long int found = 0;\n+ clock_t start, end;\n+ unsigned long int cpu_time_used;\n+ unsigned int tnonce;\n+ start = clock();\n+\n+ while( fin.getline(line, 180))\n+ {\n+  string in(line);\n+  //printf(\"%s\", in.c_str());\n+  tmp.block.nVersion       = strtol(in.substr(0,8).c_str(), &p, 16);\n+  tmp.block.hashPrevBlock.SetHex(in.substr(8,64));\n+  tmp.block.hashMerkleRoot.SetHex(in.substr(64+8,64));\n+  tmp.block.nTime          = strtol(in.substr(128+8,8).c_str(), &p, 16);\n+  tmp.block.nBits          = strtol(in.substr(128+16,8).c_str(), &p, 16);\n+  tnonce = strtol(in.substr(128+24,8).c_str(), &p, 16);\n+  tmp.block.nNonce         = tnonce;\n+\n+  unsigned int nBlocks0 = FormatHashBlocks(&tmp.block, sizeof(tmp.block));\n+  unsigned int nBlocks1 = FormatHashBlocks(&tmp.hash1, sizeof(tmp.hash1));\n+\n+  // Byte swap all the input buffer\n+  for (int i = 0; i < sizeof(tmp)/4; i++)\n+   ((unsigned int*)&tmp)[i] = ByteReverse(((unsigned int*)&tmp)[i]);\n+\n+  // Precalc the first half of the first hash, which stays constant\n+  uint256 midstate __attribute__ ((aligned(16)));\n+  SHA256Transform(&midstate, &tmp.block, pSHA256InitState);\n+\n+\n+  uint256 hashTarget = CBigNum().SetCompact(ByteReverse(tmp.block.nBits)).getuint256();\n+  // printf(\"target %s\", hashTarget.GetHex().c_str());\n+  uint256 hash;\n+  uint256 refhash __attribute__ ((aligned(16)));\n+\n+  unsigned int thash[9][NPAR] __attribute__ ((aligned (16)));\n+  int done = 0;\n+  unsigned int i, j;\n+\n+  /* reference */\n+  SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);\n+  SHA256Transform(&refhash, &tmp.hash1, pSHA256InitState);\n+  for (int i = 0; i < sizeof(refhash)/4; i++)\n+   ((unsigned int*)&refhash)[i] = ByteReverse(((unsigned int*)&refhash)[i]);\n+\n+  //printf(\"reference nonce %08x:%s\", tnonce, refhash.GetHex().c_str());\n+\n+  tmp.block.nNonce = ByteReverse(tnonce) & 0xfffff000;\n+\n+\n+  for(;;)\n+  {\n+\n+   Double_BlockSHA256((char*)&tmp.block + 64, &tmp.hash1, &midstate, thash, pSHA256InitState);\n+\n+   for(i = 0; i<NPAR; i++) {\n+    /* fast hash checking */\n+    if(thash[7][i] == 0) {\n+   //  printf(\"found something... \");\n+\n+     for(j = 0; j<8; j++) ((unsigned int *)&hash)[j] = ByteReverse((unsigned int)thash[j][i]);\n+    // printf(\"%s\", hash.GetHex().c_str());\n+\n+     if (hash <= hashTarget)\n+     {\n+      found++;\n+      if(tnonce == ByteReverse((unsigned int)thash[8][i]) ) {\n+       if(hash == refhash) {\n+        printf(\"\r%lu\", found);\n+        totalhashes += NPAR;\n+        done = 1;\n+       } else {\n+        printf(\"Hashes do not match!\");\n+       }\n+      } else {\n+       printf(\"nonce does not match. %08x != %08x\", tnonce, ByteReverse(tmp.block.nNonce + i));\n+      }\n+      break;\n+     }\n+    }\n+   }\n+   if(done) break;\n+\n+   tmp.block.nNonce+=NPAR;\n+   totalhashes += NPAR;\n+   if(tmp.block.nNonce == 0) {\n+    printf(\"ERROR: Hash not found for:%s\", in.c_str());\n+    return;\n+   }\n+  }\n+ }\n+ printf(\"\");\n+ end = clock();\n+ cpu_time_used += (unsigned int)(end - start);\n+ cpu_time_used /= ((CLOCKS_PER_SEC)/1000);\n+ printf(\"found solutions = %lu\", found);\n+ printf(\"total hashes = %lu\", totalhashes);\n+ printf(\"total time = %lu ms\", cpu_time_used);\n+ printf(\"average speed: %lu khash/s\", (totalhashes)/cpu_time_used);\n+}\n+\n+int main(int argc, char* argv[]) {\n+ if(argc == 2) {\n+  BitcoinTester(argv[1]);\n+ } else\n+  printf(\"Missing filename!\");\n+ return 0;\n+}"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6869#msg6869"},{"f":"wereHamster","d":1280657808,"b":[["q","care with __attribute__ ((aligned (16))) , it doesn't work with local variable, gcc doesn't align the stack","Quote from: Mionione on July 31, 2010, 11:30:11 PM"],["t","Maybe gcc doesn't align the stack, but it can (and automatically does) align variables on the stack."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6893#msg6893"},{"f":"Mionione","d":1280667220,"b":[["t","that's what it is supposed to do, but it doesn't always do it, issues are on gcc bugzilla\n\nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=43798\nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660\nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6899#msg6899"},{"f":"Ground Loop","d":1280708563,"b":[["t","No joy against SVN tip here."],["c","patching file sha256.cpp\npatching file main.cpp\nHunk #1 FAILED at 2555.\nHunk #2 FAILED at 2703.\n2 out of 2 hunks FAILED -- saving rejects to file main.cpp.rej\npatching file makefile.unix\nHunk #1 FAILED at 41.\nHunk #2 FAILED at 52.\nHunk #3 FAILED at 64.\n3 out of 3 hunks FAILED -- saving rejects to file makefile.unix.rej\npatching file test.cpp"],["t","Trying manually now."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6949#msg6949"},{"f":"Ground Loop","d":1280732240,"b":[["t","I got the patch knitted in, and I think I did it correctly.. wasn't complicated.\n\nRegrettably, the hash rate has decreased by almost half.  I'm down from 2071 (stock build, svn tip) to 1150 khash/sec with the patch.\n\nIt's an Intel Xeon 3 GHz, Linux, with these proc flags:"],["c","flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr"],["t","Has anyone seen gains?\n\nDid I botch it?  Missing CPU capabilities?  Wrong compiler options?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6970#msg6970"},{"f":"impossible7","d":1280736791,"b":[["t","I have been able to apply the patch against SVN (r121) and I tested it on 2 machines:\n\n• on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)\n\n• on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)\n\nThe strange thing is that despite the fact that I have been running it on 6 Opterons (i.e. 6x4=24 cores) for 40 hours with an average rate of 51,000 khash/s, I still haven't generated any blocks. The probability of this (no blocks, 40 hours, 51,000 khash/s and diffuculty=244.2) is 0.09% or 1/1098. Are you sure this thing works correctly and that the reported rate is correct? How do I run the included test program?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6979#msg6979"},{"f":"knightmb","d":1280738824,"b":[["t","Is it a AMD only optimization perhaps?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6984#msg6984"},{"f":"impossible7","d":1280739655,"b":[["q","Is it a AMD only optimization perhaps?","Quote from: knightmb on August 02, 2010, 08:47:04 AM"],["t","Or a 64-bit only optimization."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6985#msg6985"},{"f":"Ground Loop","d":1280740627,"b":[["t","With the patch above, I was unable to build the test program.  You?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6986#msg6986"},{"f":"petree","d":1280740949,"b":[["t","The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client.  I was even able to port its minor changes to 0.3.7 successfully, with the same results.\n\nIs there a way we can confirm that the variables are being aligned properly?  I'm wondering if the Intel procs are less tolerant of misalignment than the AMD's."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6987#msg6987"},{"f":"impossible7","d":1280741504,"b":[["q","With the patch above, I was unable to build the test program.  You?","Quote from: Ground Loop on August 02, 2010, 09:17:07 AM"],["t","Under x86 I had to include cryptopp/obj/cpu.o in the list of object files, otherwise \"make test\" would fail. Under x86_64 I had no such issue."],["q","The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client.  I was even able to port its minor changes to 0.3.7 successfully, with the same results.","Quote from: petree on August 02, 2010, 09:22:29 AM"],["t","As I said above I did notice an imporvement in performace too, but I am not sure the patched version works correctly. Have you been able to generate any blocks with the patched version?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg6988#msg6988"},{"f":"nelisky","d":1280754348,"b":[["q","> Quote from: knightmb on August 02, 2010, 08:47:04 AM\n> Is it a AMD only optimization perhaps?\n\nOr a 64-bit only optimization.","Quote from: impossible7 on August 02, 2010, 09:00:55 AM"],["t","I'm trying on a Q6600 running 64bit linux (ubuntu server) and it makes things slower there, so not 64bit only. And I'm running on my mac laptop which sports an Intel i5 (also 64 bit OSX 10.6), which great speed improvement there, so not AMD only."]],"u":"https://bitcointalk.org/index.php?topic=648.msg6999#msg6999"},{"f":"petree","d":1280765553,"b":[["q","> Quote from: Ground Loop on August 02, 2010, 09:17:07 AM\n> With the patch above, I was unable to build the test program.  You?\n\nUnder x86 I had to include cryptopp/obj/cpu.o in the list of object files, otherwise \"make test\" would fail. Under x86_64 I had no such issue.\n\n> Quote from: petree on August 02, 2010, 09:22:29 AM\n> The original patch posted is working just fine for me (Opteron 2376), and did double my performance over the stock 0.3.6 client.  I was even able to port its minor changes to 0.3.7 successfully, with the same results.\n\nAs I said above I did notice an imporvement in performace too, but I am not sure the patched version works correctly. Have you been able to generate any blocks with the patched version?","Quote from: impossible7 on August 02, 2010, 09:31:44 AM"],["t","Yes, since applying this patch I've generated 2 blocks."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7027#msg7027"},{"f":"satoshi","d":1280775766,"b":[["t","Is it 2x fast on AMD and 1/2 fast on Intel?"],["q","Btw. Why are you using this alignup<16> function when __attribute__ ((aligned (16))) will tell the compiler to align at compiletime?","Quote from: tcatm on July 31, 2010, 10:12:38 AM"],["t","Tried that, but it doesn't work for things on the stack.  I ran some tests.\n\nIt doesn't even cause an error, it just doesn't align it."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7084#msg7084","s":1,"n":307,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/307/"},{"f":"jgarzik","d":1280776523,"b":[["t","FWIW, there exists -mstackrealign and -mpreferred-stack-boundary=NUM"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7086#msg7086"},{"f":"impossible7","d":1280782165,"b":[["t","After 52 hours of trying with no blocks generated, I give up and I am switching back to the vanilla bitcoin.\n\nThe probability of getting no blocks within 52 hours at 51,000 khash/s is 0.011%. So I conclude that the patch doesn't work and I am 99.989% confident about that. I hope that tcatm provides some explanation on how to use the supplied test program."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7094#msg7094"},{"f":"tcatm","d":1280783276,"b":[["t","To use the test program download this file (or generate it yourself from the blockchain): http://ul.to/hz5wlg\nThe program will try to find the correct nonce in each block and detect if the hash function does work correctly. It'll also benchmark the algorithm.\n\nFrom what I've heard the patch does not work on 32 bit systems. I don't know why. I've developed it on an AMD64 machine and it works fine. If it's slower on Intel, try to disable Hyperthreading. The big loop in the SSE2 code doesn't contain any \"normal\" x86 except for one jump at the end.\n\nBtw, there's a git repo at http://github.com/tcatm/bitcoin-cruncher/"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7096#msg7096"},{"f":"nelisky","d":1280793147,"b":[["t","I've tried the git branch and results stay the same, almost half of what the vanilla svn can pump out. I'm running Intel and not AMD, but I am on 64bit:\n\nLinux bah 2.6.32-22-server #33-Ubuntu SMP Wed Apr 28 14:34:48 UTC 2010 x86_64 GNU/Linux\n\nAnything I can try to help and debug this?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7111#msg7111"},{"f":"tcatm","d":1280794901,"b":[["q","I've tried the git branch and results stay the same, almost half of what the vanilla svn can pump out. I'm running Intel and not AMD, but I am on 64bit:\n\nLinux bah 2.6.32-22-server #33-Ubuntu SMP Wed Apr 28 14:34:48 UTC 2010 x86_64 GNU/Linux\n\nAnything I can try to help and debug this?","Quote from: nelisky on August 02, 2010, 11:52:27 PM"],["t","Can you mail me a copy of cryptopp/obj/sha256.o to tcatm@gawab.com <mailto:tcatm@gawab.com>? I still fear Intels microcode in their CPUs wasn't made for such tight loops of SSE code. Have you run the test program? How many khash/s does it crunch?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7115#msg7115"},{"f":"nelisky","d":1280796372,"b":[["t","datla@bah:~/src/bitcoin/bitcoin-cruncher$ ./test blocks.txt\nSHA256 test started\n70293\nfound solutions = 70293\ntotal hashes = 139463136\ntotal time = 235480 ms\naverage speed: 592 khash/s\n\nI'll send you the obj file now"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7117#msg7117"},{"f":"tcatm","d":1280798273,"b":[["t","Thanks for the object!\n\nThere are two things I noticed:\n1) The Intel object runs at 3269khash/s on my AMD64 (vs. 3778khash/s) so it's less optimized than the AMD64 code.\n\n2) AMD64 moves less data around and does more calculations. Sometimes it even abuses floating point instructions for integers.\n\nCould you drop in my sha256.o from http://ul.to/2ckndx to cryptopp/obj/, delete test (not the .cpp!!) and recompile test using make -f makefile.unix test (take care it doesn't recompile sha256.cpp to sha256.o). Then run test again. It should be using AMD64 code now. Maybe it works better...\n\nIf not we've found that AMD64 is about four times faster than Intel at SSE2 integer vector arithmetic. Anyone working on a floating point SHA256 implementation? Wink"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7123#msg7123"},{"f":"nelisky","d":1280801062,"b":[["t","SHA256 test started\n70293\nfound solutions = 70293\ntotal hashes = 139463136\ntotal time = 222110 ms\naverage speed: 627 khash/s\n\nSo slightly better, but still far for good... As for AMD vs Intel, on my Mac, which is an intel i5, the performance boost was almost 100%, so maybe some compiler thing? I did have to remove the -arch i386 from makefile.osx to have it build on osx 10.6, but there's no such flag on linux' g++ and I'm pretty sure the 64bit g++ will not compile 32bit anyway."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7131#msg7131"},{"f":"tcatm","d":1280802110,"b":[["t","i5 is a different architecture than Core2. Maybe SSE in Core2 is broken and was fixed in i5. That means the original client is close to the fastest you can get on Core2. It's not a compiler thing. I compared the output for different architectures and -march=amdfam10 produces the fastest and smallest code. I would be surprised if a longer loop using the same instructions was faster on an older CPU."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7134#msg7134"},{"f":"nelisky","d":1280802228,"b":[["t","Well, kudos to you for trying. Now if I can just get your code merged with the old cuda version on my macbook pro, I'll be a happy camper Smiley"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7135#msg7135"},{"f":"vess","d":1280867764,"b":[["t","Anyone able to send me a compiled version of this for windows? I'm interested to try it out on my AMD server."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7325#msg7325"},{"f":"impossible7","d":1280872152,"b":[["t","I kept running the patched version on 2 machines and the following has happened 5 times: bitcoind crashes and debug.log contains the following:"],["c","proof-of-work found\n  hash: 00000000001c3530e42b2c7e1a20de01436882d0c1de0b63db6be8e6194255dd\ntarget: 00000000010c5a00000000000000000000000000000000000000000000000000\nCBlock(hash=00000000001c3530, ver=1, hashPrevBlock=0000000000253ab5, hashMerkleRoot=89541f, nTime=1280867359, nBits=1c010c5a, nNonce=3915571979, vtx=2)\n  CTransaction(hash=4fcb8e, ver=1, vin.size=1, vout.size=1, nLockTime=0)\n    CTxIn(COutPoint(000000, -1), coinbase 045a0c011c021b04)\n    CTxOut(nValue=50.00000000, scriptPubKey=0xCE5264238BAC29160CDC9C)\n  CTransaction(hash=8f2466, ver=1, vin.size=1, vout.size=1, nLockTime=0)\n    CTxIn(COutPoint(77aaae, 1), scriptSig=0x01F561A9044BF348CEF6F4)\n    CTxOut(nValue=5.00000000, scriptPubKey=OP_DUP OP_HASH160 0xB13A)\n  vMerkleTree: 4fcb8e 8f2466 89541f\n08/03/10 20:29 generated 50.00\nAddToWallet 4fcb8e  new\nAddToBlockIndex: new best=00000000001c3530  height=72112\nProcessBlock: ACCEPTED\nsending: inv"],["t","I guess this means that a new block has been generated. But when I restart bitcoind the balance is still zero. When I ask for a list of generated blocks I get the following:"],["c","$ ./bitcoind listgenerated\n[\n    {\n        \"value\" : 50.00000000000000,\n        \"maturesIn\" : -1,\n        \"accepted\" : false,\n        \"confirmations\" : 0,\n        \"genTime\" : 1280867359\n    }\n]"],["t","(listgenerated is from the patch at http://www.alloscomp.com/bitcoin/)\n\nI guess this means that my client produced a block but it crashed before it was able to broadcast it."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7343#msg7343"},{"f":"tcatm","d":1280872434,"b":[["t","did you run it on 32 bit machines? which version of the patch did you use?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7345#msg7345"},{"f":"impossible7","d":1280872607,"b":[["t","r121 from the svn patched with the patch from the post #21 running on a Opteron/x86_64"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7347#msg7347"},{"f":"tcatm","d":1280872835,"b":[["t","did it crash with a segfault and can you provide a backtrace (gdb bitcoind; run; bt)?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7348#msg7348"},{"f":"impossible7","d":1280879488,"b":[["t","I did segfault according to dmesg:"],["c","bitcoind[2469]: segfault at 0 ip 00007fe92c5b3f32 sp 00007fff15e5f6b0 error 4 in libc-2.11.2.so[7fe92c57e000+150000]"],["t","I don't have a stack trace."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7368#msg7368"},{"f":"tcatm","d":1280880187,"b":[["t","Did your kernel write a coredump and if so can you mail me the binary + coredump to tcatm@gawab.com <mailto:tcatm@gawab.com>?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7369#msg7369"},{"f":"impossible7","d":1280890337,"b":[["t","I modified bitcoind so that it doen't fork to the background and now I can debug it with gdb. Next time it crashes gdb will give me a backtrace."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7420#msg7420"},{"f":"tcatm","d":1280890849,"b":[["t","GDB can also generate coredumps with the command generate-core-file. It might be useful to reconstruct the cause for the segfault. Please note, that the coredump might include your wallet so it's probably a good idea to run bitcoind on a seperate datadir."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7421#msg7421"},{"f":"vess","d":1280928884,"b":[["t","Just a comment that this would be easier to test if difficulty were set to '1' in the client."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7467#msg7467"},{"f":"tcatm","d":1280929406,"b":[["t","Oh thats easy: Get two nodes on a seperate network and connect them using -connect=other_nodes_ip and a seperate/empty datadir."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7470#msg7470"},{"f":"impossible7","d":1280990416,"b":[["t","I had 5 machines running today and when I checked back 10 hours later, 4 of them had crashed, in the same way as with the previous times (i.e. right after they had generated a new block but before they broadcasted it).\n\nI created a tarball containing the coredump, backtrace, binary and the sources I used to compile it including the compiled object files. You can get it from here (link removed). Hope that helps.\n\nEDIT: Ok, I just noticed that both your patch and the patch for the getkhps rpc (from http://www.alloscomp.com/bitcoin/) modify the function BitcoinMiner in main.cpp (which is where the segfault occurs) so this must be the reason for the seqfaults. I will try to test it without the getkhps patch."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7641#msg7641"},{"f":"impossible7","d":1281015350,"b":[["t","Ok I tried again, this time with no extra patches. I just cloned your git tree and compiled it. It still crashes. Here's the stack backtrace:"],["c","#0  0x00007ffff710b1b5 in raise () from /lib/libc.so.6\n#1  0x00007ffff710c5e0 in abort () from /lib/libc.so.6\n#2  0x00007ffff71042d1 in __assert_fail () from /lib/libc.so.6\n#3  0x00000000004628de in BitcoinMiner () at main.cpp:2741\n#4  0x0000000000462d70 in ThreadBitcoinMiner (parg=0x391e) at main.cpp:2518\n#5  0x00007ffff6ec3894 in start_thread () from /lib/libpthread.so.0\n#6  0x00007ffff71aa07d in clone () from /lib/libc.so.6"],["t","I have also uploaded here (link removed) the sources with the object files as well as the a core dump and the binary."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7668#msg7668"},{"f":"tcatm","d":1281017174,"b":[["t","That's not a real crash this time. It's an assert that fails in the miner. Most likely assert(hash == pblock->GetHash());. Can you run the test programm (explained in http://bitcointalk.org/index.php?topic=648.msg7096#msg7096)? If it fails, can you change -march=amdfam10 back to -march=native in makefile.unix, rm cryptopp/obj/*.o and recompile everything? What cpu are you running it on?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7669#msg7669"},{"f":"impossible7","d":1281062972,"b":[["t","The test program does not fail"],["c","$ ./test ../blocks.txt\nSHA256 test started\n70293\nfound solutions = 70293\ntotal hashes = 139463136\ntotal time = 63250 ms\naverage speed: 2204 khash/s"],["t","Does the test program run on a single thread?\n\nFinally, I have the same problem with both -march=amdfam10 and -march=native. The cpu is a Opteron 2374."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7774#msg7774"},{"f":"tcatm","d":1281065933,"b":[["t","Yes, test is single threaded. Is there any output on stderr? From the coredumps I can tell that there must be some output.\n\nThe problem seems to be hard to debug, though. Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7779#msg7779"},{"f":"knightmb","d":1281077403,"b":[["q","<snip> Is the khash/s you get worth it anymore at 352 difficulty? I'm only getting a block once a week now. If you want to keep the block chain working, you should use the original client. If you want to gain lots of bitcoins you should use a GPU.","Quote from: tcatm on August 06, 2010, 03:38:53 AM"],["t","When the difficulty changed, the first machine in my group to generate a block was the slowest one running the stock client (800 MHz E-machine) and it hadn't generated anything in over a week itself. So I guess every little bit helps, that's so many are interested in getting this to work on their machine."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7796#msg7796"},{"f":"impossible7","d":1281085252,"b":[["t","Here's the output on stderr:"],["c","bitcoind: main.cpp:2741: void BitcoinMiner(): Assertion `(\"break caught by CRITICAL_BLOCK!\", !fcriticalblockonce)' failed."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7814#msg7814"},{"f":"tcatm","d":1281092358,"b":[["t","Oh, that's a part in the code my patch doesn't touch. You could try to remove line 2741 (CRITICAL_BLOCK(cs_main))."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7831#msg7831"},{"f":"impossible7","d":1281094640,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=648.msg7838#msg7838"},{"f":"tcatm","d":1281095644,"b":[["t","Thanks! That got probably mixed up when I patched the file with an older diff. I fixed the git: http://github.com/tcatm/bitcoin-cruncher"]],"u":"https://bitcointalk.org/index.php?topic=648.msg7841#msg7841"},{"f":"satoshi","d":1281215761,"b":[["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.","Quote from: impossible7 on August 06, 2010, 11:37:20 AM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=648.msg8145#msg8145","s":1,"n":330,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/330/"},{"f":"impossible7","d":1281221467,"b":[["t","I can confirm that the patch now works just fine. I just generated my first 50 BTC with it. And since this patch doubles the speed I think it's only fair if I donated half of that to tcatm."]],"u":"https://bitcointalk.org/index.php?topic=648.msg8167#msg8167"},{"f":"tcatm","d":1281221995,"b":[["q","I can confirm that the patch now works just fine. I just generated my first 50 BTC with it. And since this patch doubles the speed I think it's only fair if I donated half of that to tcatm.","Quote from: impossible7 on August 07, 2010, 10:51:07 PM"],["t","That's nice to hear. Thanks for the donation and thanks to everyone else who donated!"]],"u":"https://bitcointalk.org/index.php?topic=648.msg8170#msg8170"},{"f":"aceat64","d":1281249433,"b":[["t","I just tried again with the latest version from your github. I'm still seeing a drop in performance compared to the vanilla source.\n\nMy system went from ~7100 to ~4200.\n\nThis particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz."]],"u":"https://bitcointalk.org/index.php?topic=648.msg8215#msg8215"},{"f":"tcatm","d":1281268373,"b":[["t","It seems to be like this: everything before Core2 will be slower, everything starting with Core2 is faster. Can anyone test the code on an older AMD64? I know there was a change in the way SSE2 instructions are executed in recent architectures."]],"u":"https://bitcointalk.org/index.php?topic=648.msg8229#msg8229"},{"f":"nimnul","d":1281615503,"b":[["t","Can we implement a speed test, so different hashing engines are tried and the fastest is chosen?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg8875#msg8875"},{"f":"nelisky","d":1281617878,"b":[["q","It seems to be like this: everything before Core2 will be slower, everything starting with Core2 is faster. Can anyone test the code on an older AMD64? I know there was a change in the way SSE2 instructions are executed in recent architectures.","Quote from: tcatm on August 08, 2010, 11:52:53 AM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg8883#msg8883"},{"f":"satoshi","d":1281650843,"b":[["t","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.\n\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\n\naceat64:\nMy system went from ~7100 to ~4200.\nThis particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz.\n\nimpossible7:\non an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121)\n\nnelisky:\nMy Core2Quad (Q6600) slowed down 50%,\nmy i5 improved ~200%,\n\nimpossible7:\non an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!)"]],"u":"https://bitcointalk.org/index.php?topic=648.msg8929#msg8929","s":1,"n":352,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/352/"},{"f":"vess","d":1281650990,"b":[["t","My core i5 doubled in speed. My Core 2 Duo is the same speed. "]],"u":"https://bitcointalk.org/index.php?topic=648.msg8930#msg8930"},{"f":"tcatm","d":1281660167,"b":[["t","Would be interesting to try it out on older AMD64. There's been a change that would explain it there:\nhttp://developer.amd.com/documentation/articles/pages/682007171.aspx\n\nMaybe Intel did something similiar without announcing it?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg8949#msg8949"},{"f":"Cheater","d":1281680843,"b":[["t","I'll just pitch in that Phenom and Phenom II processors doubled (roughly).\nNo difference between the two that I can tell.\n\nSorry I dont have anything older than Phenoms available right now.\nMight be able to access a old X2 in a week."]],"u":"https://bitcointalk.org/index.php?topic=648.msg8973#msg8973"},{"f":"sgtstein","d":1281733833,"b":[["t","Just a question for whoever, trying to wrap up the information in this thread.\n\nDoes this:\n\n• 1. Work on 32-bit?\n\n• 2. Patch the SVN (r130 as of current) or Git?\n\n• 3. Compile on CentOS?\n\nIf anyone has any answers I would greatly appreciate them."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9105#msg9105"},{"f":"tcatm","d":1281734834,"b":[["t","1. Does not work on 32-bit (though that's not a problem with the algorithm).\n2. Patch is against older SVN. There's a git repo at http://github.com/tcatm/bitcoin-cruncher\n3. Compiles on every 64bit Linux.\n\nIt's not intended as a replacement for a standard client but for a dedicated bitcoinminer box. I'm planning a pluggable bitcoinminer someday. But at current difficulty it's easier to work for bitcoins than finding faster ways for mining."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9109#msg9109"},{"f":"NewLibertyStandard","d":1281738445,"b":[["t","I would really like to have this feature included in an official build  sometimes soon along with an internal speed test to determine which algorithm to use. You can always remove the speed test later once you figure out how to determine whether it will be faster or slower without running the speed test."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9121#msg9121"},{"f":"sgtstein","d":1281741471,"b":[["q","1. Does not work on 32-bit (though that's not a problem with the algorithm).\n2. Patch is against older SVN. There's a git repo at http://github.com/tcatm/bitcoin-cruncher\n3. Compiles on every 64bit Linux.\n\nIt's not intended as a replacement for a standard client but for a dedicated bitcoinminer box. I'm planning a pluggable bitcoinminer someday. But at current difficulty it's easier to work for bitcoins than finding faster ways for mining.","Quote from: tcatm on August 13, 2010, 09:27:14 PM"],["t","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?\n\n2. Thank you, I will look into implementing it on my 64bit systems.\n3. Excellent to hear. I'm looking forward to using it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9128#msg9128"},{"f":"satoshi","d":1281746958,"b":[["t","MinGW on Windows has trouble compiling it:\n\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\n\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"]],"u":"https://bitcointalk.org/index.php?topic=648.msg9145#msg9145","s":1,"n":358,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/358/"},{"f":"tcatm","d":1281747028,"b":[["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?","Quote from: sgtstein on August 13, 2010, 11:17:51 PM"],["t","No idea, maybe some alignment problem. Someone was trying to figure it out on IRC. I don't have a SSE2 capable 32bit system. The additional registers in 64bit mode are also useful. I don't know if your PE2650 has a recent enough CPU. You might experience a performance drop of 50% if the CPU is too old.\n\nBtw, did anyone with Intel CPU compare performance with Hyperthreading enabled/disabled? The SSE2 loop keeps the arithmetic units and pipelines pretty busy and I can imagine Hyperthreading might decrease performance."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9146#msg9146"},{"f":"tcatm","d":1281747187,"b":[["q","MinGW on Windows has trouble compiling it:\n\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\n\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","Quote from: satoshi on August 14, 2010, 12:49:18 AM"],["t","Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?"]],"u":"https://bitcointalk.org/index.php?topic=648.msg9147#msg9147"},{"f":"satoshi","d":1281759749,"b":[["t","If you haven't already, try aligning thash.  It might matter.  Couldn't hurt."],["q","Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?","Quote from: tcatm on August 14, 2010, 12:53:07 AM"],["t","No help from -O0, same error.\n\nMinGW is GCC 3.4.5.  Probably the problem.\n\nI'll see if I can get a newer version of MinGW."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9159#msg9159","s":1,"n":359,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/359/"},{"f":"satoshi","d":1281808537,"b":[["t","Got the test working on 32-bit with MinGW GCC 4.5.  Exactly 50% slower than stock with Core 2."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9228#msg9228","s":1,"n":360,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/360/"},{"f":"satoshi","d":1281823573,"b":[["t","MinGW GCC 4.5.0:\nCrypto++ doesn't work, X86_SHA256_HashBlocks() never returns\nI only got 4-way working with test.cpp but not when called by BitcoinMiner\n\nMinGW GCC 4.4.1:\nCrypto++ works\n4-way SIGSEGV\n\nGCC is definitely not aligning __m128i.\n\nEven if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable.\n\nBy making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only:\n#define Ch(b, c, d)  ((b & c) ^ (~b & d))\n#define Maj(b, c, d)  ((b & c) ^ (b & d) ^ (c & d))\n#define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n))\n#define SHR(x, n)  _mm_srli_epi32(x, n)\n\nBut that's with -O0."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9278#msg9278","s":1,"n":361,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/361/"},{"f":"sgtstein","d":1281842371,"b":[["t","Well, reporting back.\n\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.\n\nAlso, does the git contain the patched and updated code?"],["c","// 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"],["t","Just wanted to tell my story and help with whatever information I could."]],"u":"https://bitcointalk.org/index.php?topic=648.msg9353#msg9353"},{"f":"satoshi","d":1281843629,"b":[["t","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.\n\nI have it working fine on GCC 4.3.3 on Ubuntu 32-bit.\n\nI found the problem with Crypto++ on MinGW 4.5.0.  Here's the patch for that:"],["c","--- \\old\\sha.cpp Mon Jul 26 13:31:11 2010\n+++ ew\\sha.cpp Sat Aug 14 20:21:08 2010\n@@ -336,7 +336,7 @@\n  ROUND(14, 0, eax, ecx, edi, edx)\n  ROUND(15, 0, ecx, eax, edx, edi)\n \n- ASL(1)\n+    ASL(label1)   // Bitcoin: fix for MinGW GCC 4.5\n  AS2(add WORD_REG(si), 4*16)\n  ROUND(0, 1, eax, ecx, edi, edx)\n  ROUND(1, 1, ecx, eax, edx, edi)\n@@ -355,7 +355,7 @@\n  ROUND(14, 1, eax, ecx, edi, edx)\n  ROUND(15, 1, ecx, eax, edx, edi)\n  AS2( cmp  WORD_REG(si), K_END)\n- ASJ( jne, 1, b)\n+    ASJ(    jne,    label1,  )   // Bitcoin: fix for MinGW GCC 4.5\n \n  AS2( mov  WORD_REG(dx), DATA_SAVE)\n  AS2( add  WORD_REG(dx), 64)"]],"u":"https://bitcointalk.org/index.php?topic=648.msg9359#msg9359","s":1,"n":362,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/362/"}]},{"id":"p153","k":"p","s":"bitcointalk","t":"Webpage idea: Next predicted difficulty change","u":"https://bitcointalk.org/index.php?topic=651","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/153/","m":[{"f":"satoshi","d":1280539928,"b":[["t","It would be neat if someone had a page (like that handy calculator at http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next difficulty adjustment will be.\n\nprojected difficulty adjustment multiplier =\n\n blocks_since_last_adjustment / 2016\n ------------------------------------\n time_since_last_adjustment / 14_days\n\nFor instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:\n\n (1008/2016) / (3.5/14) = 0.5/0.25 = 2.0\n\nAlso, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed."]],"u":"https://bitcointalk.org/index.php?topic=651.msg6760#msg6760","s":1,"n":303,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/303/"}]},{"id":"p154","k":"p","s":"bitcointalk","t":"BitCoin Wikipedia page DELETED!!!","u":"https://bitcointalk.org/index.php?topic=652","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/154/","m":[{"f":"em3rgentOrdr","d":1280542661,"b":[["t","from http://en.wikipedia.org/wiki/Bitcoin\n\n\"This page has been deleted. The deletion and move log for the page are provided below for reference.\n\n10:42, 30 July 2010 Polargeo (talk | contribs) deleted \"Bitcoin\" ‎ (Wikipedia:Articles for deletion/Bitcoin)\""]],"u":"https://bitcointalk.org/index.php?topic=652.msg6765#msg6765"},{"f":"kiba","d":1280545105,"b":[["q","from http://en.wikipedia.org/wiki/Bitcoin\n\n\"This page has been deleted. The deletion and move log for the page are provided below for reference.\n\n10:42, 30 July 2010 Polargeo (talk | contribs) deleted \"Bitcoin\" ‎ (Wikipedia:Articles for deletion/Bitcoin)\"","Quote from: em3rgentOrdr on July 31, 2010, 02:17:41 AM"],["t","Boohoo. They don't like us. Big deal."]],"u":"https://bitcointalk.org/index.php?topic=652.msg6768#msg6768"},{"f":"fresno","d":1280549600,"b":[["t","Wiki-who? Never heard of it!\n\nIs it some sort of ukulele band?"]],"u":"https://bitcointalk.org/index.php?topic=652.msg6773#msg6773"},{"f":"Anonymous","d":1280550924,"b":[["t","It is ironic that wikipedia itself isnt accepted as a reliable source when you quote from  it in an argument. Roll Eyes  Apparently you are only notable if a celebrity mentions you. "]],"u":"https://bitcointalk.org/index.php?topic=652.msg6775#msg6775"},{"f":"ichi","d":1280555180,"b":[["t","I didn't suggest reading ae's Wikipedia page  Wink  And I definitely didn't link to it."]],"u":"https://bitcointalk.org/index.php?topic=652.msg6782#msg6782"},{"f":"Anonymous","d":1280558211,"b":[["q","I didn't suggest reading ae's Wikipedia page  Wink  And I definitely didn't link to it.","Quote from: ichi on July 31, 2010, 05:46:20 AM"],["t","I definitely didnt read it  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=652.msg6786#msg6786"},{"f":"knightmb","d":1280560809,"b":[["t","I've started the undelete request here:\nhttp://en.wikipedia.org/wiki/Wikipedia:Requests_for_undeletion#Bitcoin\n\nIf anyone wants to participate, just edit my undelete request and add more reasons why you think it wasn't fair to delete the article."]],"u":"https://bitcointalk.org/index.php?topic=652.msg6790#msg6790"},{"f":"Anonymous","d":1280582725,"b":[["q","What is funny to me, is all the other pages on there asking for undeletion... are garage bands, wanna be \"upcoming actors\", and start up companies trying to advertise...\n\nWithout in depth examination, it appears we are the only such type of article that has been deleted asking for reinstatement. Someone must have really been PMSy to request the deletion in the first place.","Quote from: davidonpda on July 31, 2010, 01:18:33 PM"],["t","The admin who deleted the article is an expert on glaciers .\n\nDoes this make him an ice-hole?\n Smiley"]],"u":"https://bitcointalk.org/index.php?topic=652.msg6806#msg6806"},{"f":"Bitquux","d":1280589260,"b":[["q","The admin who deleted the article is an expert on glaciers .","Quote from: Anonymous on July 31, 2010, 01:25:25 PM"],["t","That would explain why he's got the time to admin for wikipedia."]],"u":"https://bitcointalk.org/index.php?topic=652.msg6825#msg6825"},{"f":"Anonymous","d":1280589437,"b":[["q","> Quote from: Anonymous on July 31, 2010, 01:25:25 PM\n> The admin who deleted the article is an expert on glaciers .\n\nThat would explain why he's got the time to admin for wikipedia.","Quote from: Bitquux on July 31, 2010, 03:14:20 PM"],["t","I cant believe bitcoin got hit by an ice berg. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=652.msg6826#msg6826"},{"f":"knightmb","d":1280648996,"b":[["t","Instead of wasting with them (they do frustrate me sometimes), why not create a new article at a more \"friendly\" place like\nhttp://en.citizendium.org/wiki/Welcome_to_Citizendium"],["q","Citizendium is a wiki that seems to be a compromise between the free-for-all that is Wikipedia and the strict supervision that accompanies Scholarpedia. One of Wikipedia's founders, Larry Sanger, created Citizendium in the hopes of improving on Wikipedia's model. With what the site refers to as \"gentle oversight\", all articles are subject to approval by the site's editorial team. Articles that haven't been approved will have an accompanying disclaimer, which helps to prevent people from taking potentially false information to heart. Also, you must register under your real name to become a contributor, unlike Wikipedia. Although the site is still in beta form, it is quickly becoming a popular alternative to Wikipedia.","Quote"]],"u":"https://bitcointalk.org/index.php?topic=652.msg6887#msg6887"},{"f":"throughput","d":1280766460,"b":[["t","Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,\nthat is for a long time. Wikipedia represent collective and often inconsistent point of view\nof a small (compared to society) group of people.\n\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.\n\nI believe, it is some form of sexual perversion, wikipedism or like that...  Lips sealed\n\nJust find another wikipedia editor and he will play instead of you."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7031#msg7031"},{"f":"kiba","d":1280766775,"b":[["q","Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,\nthat is for a long time. Wikipedia represent collective and often inconsistent point of view\nof a small (compared to society) group of people.\n\"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.\n\nI believe, it is some form of sexual perversion, wikipedism or like that...  Lips sealed\n\nJust find another wikipedia editor and he will play instead of you.","Quote from: throughput on August 02, 2010, 04:27:40 PM"],["t","There is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.\n\nSimilarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7033#msg7033"},{"f":"joechip","d":1280767889,"b":[["q","> Quote from: throughput on August 02, 2010, 04:27:40 PM\n> Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,\n> that is for a long time. Wikipedia represent collective and often inconsistent point of view\n> of a small (compared to society) group of people.\n> \"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.\n>\n> I believe, it is some form of sexual perversion, wikipedism or like that...  Lips sealed\n>\n> Just find another wikipedia editor and he will play instead of you.\n\nThere is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.\n\nSimilarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed.","Quote from: kiba on August 02, 2010, 04:32:55 PM"],["t","When they moved to that model the outcome was inevitable.... personal empire building.  If it continues to a point where it destroys the product, something else will rise to challenge it, as long as they don't use the gov't to enforce their 'right' to be the arbitrators of 'editorial standards.'\n\nTa,"]],"u":"https://bitcointalk.org/index.php?topic=652.msg7040#msg7040"},{"f":"throughput","d":1280768001,"b":[["q","> Quote from: throughput on August 02, 2010, 04:27:40 PM\n> Well, wikipedia is not a public driven project. It is driven by a limited community of it's editors,\n> that is for a long time. Wikipedia represent collective and often inconsistent point of view\n> of a small (compared to society) group of people.\n> \"Playing by the rules\" is a favorite game of them. Don't play that game, do not entertain them.\n>\n> I believe, it is some form of sexual perversion, wikipedism or like that...  Lips sealed\n>\n> Just find another wikipedia editor and he will play instead of you.\n\nThere is Wikipedia and its hierarchy, just like government and their hierarchy. The idea that the government could represent the people is laughable.\n\nSimilarly, the Wikipedia hierarchy devolved into politicking, no sexual perversion needed.","Quote from: kiba on August 02, 2010, 04:32:55 PM"],["t","Agree.\nI just count politicking itself as some form of sexual perversion, or like that... Wink\n\nAnyway, contacting wikipedia editor, who is external to this situation, will help a lot."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7041#msg7041"},{"f":"omegadraconis","d":1280790160,"b":[["t","Wanted to add another reference here that I found via http://scholar.google.com/ http://yuumei.co.uk/files/dissertation.pdf. It is a paper Titled \"The Impact of Decentralization on Networked Computer Games\" Written by Ashley Vaughan Smith of School of Computing, University of Derby. The paper mentions bitcoins as a good currency for online games. It is only about a paragraph but, I think a research paper for a University would count as an independent 3rd party and may be more of what Wikipedia would like to see."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7102#msg7102"},{"f":"NewLibertyStandard","d":1280800481,"b":[["q","Wanted to add another reference here that I found via http://scholar.google.com/ http://yuumei.co.uk/files/dissertation.pdf. It is a paper Titled \"The Impact of Decentralization on Networked Computer Games\" Written by Ashley Vaughan Smith of School of Computing, University of Derby. The paper mentions bitcoins as a good currency for online games. It is only about a paragraph but, I think a research paper for a University would count as an independent 3rd party and may be more of what Wikipedia would like to see.","Quote from: omegadraconis on August 02, 2010, 11:02:40 PM"],["t","I beat ya to it by almost two weeks. <http://bitcointalk.org/index.php?topic=342.msg5152#msg5152> Grin Not that anyone looks through my rambling lists. Cry"]],"u":"https://bitcointalk.org/index.php?topic=652.msg7130#msg7130"},{"f":"Lemming","d":1280864574,"b":[["t","Somebody (possibly knightmb?) should request Userfication <http://en.wikipedia.org/wiki/Wikipedia:Userfication> of the deleted article, to preserve the content."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7310#msg7310"},{"f":"knightmb","d":1280865342,"b":[["q","Somebody (possibly knightmb?) should request Userfication <http://en.wikipedia.org/wiki/Wikipedia:Userfication> of the deleted article, to preserve the content.","Quote from: Lemming on August 03, 2010, 07:42:54 PM"],["t","I just saw that myself, I haven't had time to dig through all the links to see what the process is since the Administrators don't have a direct \"contact me\" button anywhere.  Sad"]],"u":"https://bitcointalk.org/index.php?topic=652.msg7311#msg7311"},{"f":"omegadraconis","d":1280889260,"b":[["t","Google cache has it: http://webcache.googleusercontent.com/search?q=cache:hyQZi6xkulEJ:en.wikipedia.org/wiki/Bitcoin+bitcoins&cd=3&hl=en&ct=clnk&gl=us and Message_From_Xenu(not sure who that is on the forums) has it http://en.wikipedia.org/wiki/User:Message_From_Xenu/Bitcoin"]],"u":"https://bitcointalk.org/index.php?topic=652.msg7417#msg7417"},{"f":"mpkomara","d":1281027648,"b":[["t","the deleter's stats:\nPages deleted   839\nPages restored   1"]],"u":"https://bitcointalk.org/index.php?topic=652.msg7702#msg7702"},{"f":"RHorning","d":1281034355,"b":[["t","It should be pointed out that \"User:Message_From_Xenu/Bitcoin\" currently has the full edit history of the previous Bitcoin article, and IMHO should be what gets \"moved back\" if there is some substantial improvement in the article that might pass muster if another AfD were to be offered again.\n\nRather than fighting the tide of those supporting the deletion of this article, finding those 3rd party references would be a much better act to perform and then restore the article when an act of deletion would seem over the top.  If the community wants to continue to refine the article, that is a good place to start."]],"u":"https://bitcointalk.org/index.php?topic=652.msg7721#msg7721"},{"f":"mpkomara","d":1281705160,"b":[["t","Should we try submitting bitcoin wikipedia articles in several different languages?"]],"u":"https://bitcointalk.org/index.php?topic=652.msg9000#msg9000"},{"f":"ribuck","d":1281706901,"b":[["t","I don't think it's worth sweating over the Wikipedia deletion.\n\nJust leave it a month or two until there is some good third-party coverage then try again. The article should stick then."]],"u":"https://bitcointalk.org/index.php?topic=652.msg9003#msg9003"},{"f":"mpkomara","d":1281707824,"b":[["t","We could let the community decide the importance of a wikipedia article by offering a bounty for the article to be undeleted in English.  You might even consider bribing the original deletist with bitcoins.  He would either a) refuse it b) accept it on the basis that third party coverage had reached sufficient wikipedia standards or c) accept it controversially which would create publicity for bitcoin.  I would offer 500 bitcoins towards that end."]],"u":"https://bitcointalk.org/index.php?topic=652.msg9010#msg9010"},{"f":"ribuck","d":1281711124,"b":[["t","I think you might find that offering a bribe would be the surest way to prevent the article from being re-included."]],"u":"https://bitcointalk.org/index.php?topic=652.msg9020#msg9020"},{"f":"mpkomara","d":1285794643,"b":[["t","reviving this post.  anyone want to try creating the article in Russian? Пожалуйста, создайте статью.  or maybe that catalan speaker is around and he can start an article.  wikipedia articles are key to credibility, so i'm not letting this go.  and where are the french?  the swiss?  the germans?  let's go, people."]],"u":"https://bitcointalk.org/index.php?topic=652.msg14623#msg14623"},{"f":"sirius","d":1285865126,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=652.msg14716#msg14716"},{"f":"satoshi","d":1285869032,"b":[["t","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.\n\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.\n\nThe article could be as simple as something like:\n\"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/.\"\n\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."]],"u":"https://bitcointalk.org/index.php?topic=652.msg14729#msg14729","s":1,"n":467,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/467/","qt":["I 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: \"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."],"qc":["general"]}]},{"id":"p155","k":"p","s":"bitcointalk","t":"Linux version => No GUI after upgrade.  WTF?","u":"https://bitcointalk.org/index.php?topic=655","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/155/","m":[{"f":"generica","d":1280603197,"b":[["t","Hey guys,\n\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."]],"u":"https://bitcointalk.org/index.php?topic=655.msg6839#msg6839"},{"f":"satoshi","d":1280770767,"b":[["t","Did it print anything to the console?  Are you sure you didn't run \"bitcoind\"?\n\nTry version 0.3.7."]],"u":"https://bitcointalk.org/index.php?topic=655.msg7057#msg7057","s":1,"n":305,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/305/"}]},{"id":"p156","k":"p","s":"bitcointalk","t":"Mac Client Problems Outlined...","u":"https://bitcointalk.org/index.php?topic=660","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/156/","m":[{"f":"ArrowJ","d":1280627567,"b":[["t","Hardware\nMacBook Pro 2.4 GHz Intel Core 2 Duo (Model 4,1)\n2 GB 667 MHz DDR2 SDRAM\n\nSoftware\nMac OS X 10.6.4 Snow Leopard\nBitcoin 0.3.7 (according to Bitcoin >> About)\n\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.\n\nCPU Usage: when generating coins top shows Bitcoin at ~187% CPU...this seems extreme? A friend just explained what a \"nice process\" is. Sorry.\n\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.\n\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\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!"]],"u":"https://bitcointalk.org/index.php?topic=660.msg6875#msg6875"},{"f":"andrew","d":1280716418,"b":[["t","The first 5 minutes I used bitcoin about a three weeks ago I generated a block straight away and haven't generated another since. I think it's purely based on luck. Using the OSX client here."]],"u":"https://bitcointalk.org/index.php?topic=660.msg6956#msg6956"},{"f":"satoshi","d":1280772140,"b":[["t","\"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."]],"u":"https://bitcointalk.org/index.php?topic=660.msg7068#msg7068","s":1,"n":306,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/306/"}]},{"id":"p157","k":"p","s":"bitcointalk","t":"What happens when network is split for prolonged time and reconnected?","u":"https://bitcointalk.org/index.php?topic=661","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/157/","m":[{"f":"em3rgentOrdr","d":1280660844,"b":[["t","Suppose that BitCoins are being widely used all across the globe.  Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network.  Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network.  Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.\n\nNow after several years existing independently, what happens when the two networks are reconnected?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg6895#msg6895"},{"f":"Anonymous","d":1280718347,"b":[["q","Suppose that BitCoins are being widely used all across the globe.  Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network.  Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network.  Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.\n\nNow after several years existing independently, what happens when the two networks are reconnected?","Quote from: em3rgentOrdr on August 01, 2010, 11:07:24 AM"],["t","If the US and China go to war you will have more things to worry about than bitcoins. Sad"]],"u":"https://bitcointalk.org/index.php?topic=661.msg6961#msg6961"},{"f":"kiba","d":1280719148,"b":[["q","Now after several years existing independently, what happens when the two networks are reconnected?","Quote from: em3rgentOrdr on August 01, 2010, 11:07:24 AM"],["t","Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s)."]],"u":"https://bitcointalk.org/index.php?topic=661.msg6962#msg6962"},{"f":"throughput","d":1280764783,"b":[["q","Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).","Quote from: kiba on August 02, 2010, 03:19:08 AM"],["t","For that to happen, someone should\na) notice what's happened\nb) understand what's happened\nc) make a decision on technically isolating two economies for ever\nd) force that decision somehow.\n\nQuestion: who can be that entity, whitepaper says there is not any central authority, at all ?\n\nkiba what you say, that's impossible or whitepaper lies?"],["q","If the US and China go to war you will have more things to worry about than bitcoins.","Quote"],["t","Is it typical to ignore real threats here, by the way?"],["q","Now after several years existing independently, what happens when the two networks are reconnected?","Quote from: em3rgentOrdr on August 01, 2010, 11:07:24 AM"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7023#msg7023"},{"f":"kiba","d":1280765074,"b":[["q","> Quote from: kiba on August 02, 2010, 03:19:08 AM\n> Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).\n\nFor that to happen, someone should\na) notice what's happened\nb) understand what's happened\nc) make a decision on technically isolating two economies for ever\nd) force that decision somehow.\n\nQuestion: who can be that entity, whitepaper says there is not any central authority, at all ?\n\nkiba what you say, that's impossible or whitepaper lies?","Quote from: throughput on August 02, 2010, 03:59:43 PM"],["t","It does not require an entity to know what happen if the design of the bitcoin network didn't anticipated this kind of event. If it does happen anyway, than it may or may not be intended to deal with it."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7025#msg7025"},{"f":"em3rgentOrdr","d":1280767159,"b":[["q","> Quote from: kiba on August 02, 2010, 03:19:08 AM\n> Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).\n\nFor that to happen, someone should\na) notice what's happened\nb) understand what's happened\nc) make a decision on technically isolating two economies for ever\nd) force that decision somehow.\n\nQuestion: who can be that entity, whitepaper says there is not any central authority, at all ?\n\nkiba what you say, that's impossible or whitepaper lies?","Quote from: throughput on August 02, 2010, 03:59:43 PM"],["t","Thanks for addressing my concern!  I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly).  It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist.  I suppose each bitcoin community would properly fork the source code to do something along this line."],["q","If the US and China go to war you will have more things to worry about than bitcoins. Sad","Quote from: Anonymous on August 02, 2010, 03:05:47 AM"],["t","I don't know...I actually think that BitCoin would become popular as a resistance currency in wartime.  The State likes to enact all sorts of totalitarian BS during war, such as massive government spending <http://www.usgovernmentspending.com/spending_history>, massive inflation <http://mises.org/daily/3010>, collection of all scap or private metal <http://tvh.bfn.org/metal.html>, confiscation of private property <http://en.wikipedia.org/wiki/United_States_home_front_during_World_War_II#Taxes_and_controls>.  Even FDR in the economic emergency during 1933 outlawed private ownership of gold <http://en.wikipedia.org/wiki/Executive_Order_6102>.  But bit coin would be resistant to such measures, as long as the government doesn't shut down the internet <http://www.huffingtonpost.com/2010/06/25/internet-kill-switch-appr_n_625856.html>, which I doubt they would do since it would seriously cripple the economy and thereby destroy the tax base (although, I forgot how stupid can be sometimes), or somehow outlaw cryptography by regular folk, institute a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc.."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7034#msg7034"},{"f":"kiba","d":1280767337,"b":[["q","Thanks for addressing my concern!  I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly).  It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist.  I suppose each bitcoin community would properly fork the source code to do something along this line.","Quote from: em3rgentOrdr on August 02, 2010, 04:39:19 PM"],["t","It would seem to me it still warrant a bitcoin exchange market."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7035#msg7035"},{"f":"bytemaster","d":1280768826,"b":[["t","I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them.    At the very least you enable \"division of labor\" and allow the \"little guys\" to keep up with the data rates required under heavy transaction loads.   Failure to provide some means of breaking the chain and then transferring coins back and forth between chains at full value means that eventually only big players with low-latency high bandwidth connections will be able to handle the transaction volume. "]],"u":"https://bitcointalk.org/index.php?topic=661.msg7047#msg7047"},{"f":"knightmb","d":1280769451,"b":[["t","It is possible to run an experiment just to see what happens. It would take 4 separate clients though running at the same time (probably help to have 4 different PC to do this)\n\nBasically, take a fresh install of 2 PC, have them only connect to each other and let them generate blocks starting at 1, build up some coin, transfer between the two in a few transactions, then shut them down. Do the same thing on 2 different PC, build some coin for longer (more blocks), transfer some coin around, shut them down. Then fire up all 4 at the same time and have all 4 connected to each other and see what happens when one pair had a longer block chain than another.\n\nMy guess is the longer block chain will win and the lesser of the pair would lose all of their history/coins.\n\nSo if this was on a much larger scale (east vs. west), then whoever had the longest block chain would win once the networks started to merge back together.\n\nThinking about that thought experiment, one could run their own internal micro-payment system for fun  Grin"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7051#msg7051"},{"f":"throughput","d":1280770561,"b":[["q","I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them. ","Quote from: bytemaster on August 02, 2010, 05:07:06 PM"],["t","Double that.\nTriple that.\nThat is not possible by current design.\n\nBut network splits are inevitable future.\n\nNot every merchant will agree to lose his money due to a network split, which may sound\nreally abstract to him.\nThose who will still agree will demand a means of determining, whether a network split is\nin effect now, to limit their possible loses.\n\nIs it at all possible to monitor Bitcoin for network splits?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7056#msg7056"},{"f":"knightmb","d":1280771486,"b":[["q","Is it at all possible to monitor Bitcoin for network splits?","Quote from: throughput on August 02, 2010, 05:36:01 PM"],["t","Not easily because it would entail finding out what \"blocks\" everyone else has. Since everyone is working off the current chain, if you did find a client with \"another\" chain, it would either be silly short or hacker longer."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7063#msg7063"},{"f":"knightmb","d":1280772186,"b":[["t","I'm running an experiment to give everyone a more definitive answer.\n\nI have two fresh PC each running the BitCoin client (new install, no blocks, transactions, etc) and they are only network to each other. I'm having them generate coin against each other.\n\nI think that if such a large network split did happen, it would be from the client standpoint (basically someone would compile a client that uses a different bootstrap method, so in essence you would have a \"new\" bitcoin chain that would forever be separate from everyone else)."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7069#msg7069"},{"f":"throughput","d":1280772428,"b":[["q","> Quote from: throughput on August 02, 2010, 05:36:01 PM\n> Is it at all possible to monitor Bitcoin for network splits?\nNot easily because it would entail finding out what \"blocks\" everyone else has. Since everyone is working off the current chain, if you did find a client with \"another\" chain, it would either be silly short or hacker longer.","Quote from: knightmb on August 02, 2010, 05:51:26 PM"],["t","I, as a merchant, will only care about whether my network is a majority network,\nso after a reconnect my transactions will be accepted.\nSo it will be enough for me to be able to monitor the current number of distinct nodes.\nPut that into a graph and stop processing transactions if that number suddenly halves.\nIt may be a service on a web-server running a Bitcoin node.\n\nBut is there a way to monitor that number at all?\nIf not, it would be wise to add some feature to the standard, which will\nallow to determine in real time what is the number of distinct nodes running."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7071#msg7071"},{"f":"knightmb","d":1280772717,"b":[["q","But is there a way to monitor that number at all?\nIf not, it would be wise to add some feature to the standard, which will\nallow to determine in real time what is the number of distinct nodes running.","Quote from: throughput on August 02, 2010, 06:07:08 PM"],["t","Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)\n\nAs of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7072#msg7072"},{"f":"throughput","d":1280773193,"b":[["q","> Quote from: throughput on August 02, 2010, 06:07:08 PM\n> But is there a way to monitor that number at all?\n> If not, it would be wise to add some feature to the standard, which will\n> allow to determine in real time what is the number of distinct nodes running.\n\nMaybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)\n\nAs of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.","Quote from: knightmb on August 02, 2010, 06:11:57 PM"],["t","But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not\nconnect to you by themselves. Still being connected to the network.\n\nThis is a task of counting distinct nodes in a graph. Too bad.  Sad"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7075#msg7075"},{"f":"knightmb","d":1280773592,"b":[["q","But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not\nconnect to you by themselves. Still being connected to the network.\n\nThis is a task of counting distinct nodes in a graph. Too bad.  Sad","Quote from: throughput on August 02, 2010, 06:19:53 PM"],["t","The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading \"generic\" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7076#msg7076"},{"f":"throughput","d":1280774799,"b":[["q","> Quote from: throughput on August 02, 2010, 06:19:53 PM\n> But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not\n> connect to you by themselves. Still being connected to the network.\n>\n> This is a task of counting distinct nodes in a graph. Too bad.  Sad\nThe connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading \"generic\" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.","Quote from: knightmb on August 02, 2010, 06:26:32 PM"],["t","Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have\ntoo much connections, so the actual number of active nodes may be larger.\nOr how should I understand the connection limit? Is it only an outgoing connection limit?\n\nBy the way, I myself run two nodes on public addresses and two other behind a firewall.\nThe last two are only allowed to connect to first two, and not not the Internet.\nAFAIK, it counts as being connected to the network, so they generate blocks."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7081#msg7081"},{"f":"knightmb","d":1280775004,"b":[["q","Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have\ntoo much connections, so the actual number of active nodes may be larger.\nOr how should I understand the connection limit? Is it only an outgoing connection limit?\n\nBy the way, I myself run two nodes on public addresses and two other behind a firewall.\nThe last two are only allowed to connect to first two, and not not the Internet.\nAFAIK, it counts as being connected to the network, so they generate blocks.","Quote from: throughput on August 02, 2010, 06:46:39 PM"],["t","Exactly why a good count would be difficult as it currently is setup. I could have hundreds of clients behind a node and the outside world (Internet) would never know from what I know about how everything works."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7082#msg7082"},{"f":"omegadraconis","d":1280777574,"b":[["t","I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.\n\nAlso I was thinking that if country A goes to war with country B both countries will still most likely maintain a connection to country C, D, E, and F which can maintain the network and prevent a split. If country A blocks all internet access and country B does not then Country A looses because, Country B still connects to C,D,E, and F; Therefor country A's block chain will be shorter. If Country A and B both block internet all together they both loose because C,D,E, and F have the longer block chain. IF A, B, C go to war with D,E,F and they block access to each other on the internet then we have two bit markets now.\n\nI agree that if the world goes to hell in a hand basket a network split would be the least of our worries and it is probable that a split would not likely be due to war. I would think a network split is more likely to be caused by a country with an over zealous government repressing their own citizens via their national firewall. Another possibility would be a mass technical problem such as the rapid undersea cable cuts in 2008 (see Here <http://www.dailytech.com/Bad+to+Worse+Fifth+Undersea+Cable+Cut+in+Middle+East/article10598c.htm> or here <http://www.cnn.com/2008/WORLD/meast/02/01/internet.outage/index.html>) that cause some countries internet connection to slow to a crawl. The worst case scenario I can think of is that a large number of under sea cables or other link failures segment a large chunk of the worlds computer. The nodes outside the segment keep going like nothing happened and the same is true for the nodes in the segment. At some point we have the networks links fixed (would probably less then a week or so for another link to be established be it other land links come online or satellite links take over more bandwidth and a month at most for a more permanent fix.) I would guess that the network with the larger chunk of nodes would win out and the smaller segment would loose. The biggest problem would be that in this type of split there is not much time to try and work out a solution. Though it could be possible that in this situation if there were a super node or two in the segmented group it could still be able to make a connection to other super nodes and keep a split to a minimum."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7087#msg7087"},{"f":"knightmb","d":1280778510,"b":[["q","I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.","Quote from: omegadraconis on August 02, 2010, 07:32:54 PM"],["t","I can already tell you, it has almost no impact on the CPU, it will shave off some khash/s, but the big difference is bandwidth and memory.\n\nWhen running the program by itself (8 connection limit), you'll use between 16 and 28 MB of RAM for the program, 300MB a month for bandwidth (24/7 operation basically)\n\nWhen you run *nearly* unlimited connections, the memory usage jumps up to about 128MB of RAM, bandwidth usage also jumps way up as well to where you are using 100MB in a day instead of a month.\n\nTruthfully though, for a \"super node\" as you've now coined it  Wink it's not really that hard spec wise for any server to handle, my old celeron server could easily handle this kind of load if it was shaved down to just a few thousand connections."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7089#msg7089"},{"f":"FreeMoney","d":1280781387,"b":[["q","I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating.  ","Quote from: omegadraconis on August 02, 2010, 07:32:54 PM"],["t","This is interesting to me. What is most robust?\n\n1000 nodes all with 9 connections\n\n1000 nodes with 8 connections and one with 1000 connections\n\n1000 nodes with 8 connections and ten with 100 connections\n\nIf you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.\n\nAnother thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments)."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7091#msg7091"},{"f":"knightmb","d":1280782908,"b":[["q","> Quote from: omegadraconis on August 02, 2010, 07:32:54 PM\n> I think the idea of \"super nodes\" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating.  \n\nThis is interesting to me. What is most robust?\n\n1000 nodes all with 9 connections\n\n1000 nodes with 8 connections and one with 1000 connections\n\n1000 nodes with 8 connections and ten with 100 connections\n\nIf you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.\n\nAnother thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments).","Quote from: FreeMoney on August 02, 2010, 08:36:27 PM"],["t","I would say everyone connected to everyone (first option) because the one big node that has 1,000 other clients connected through it is great for redundancy, but also gives a good central point of attack. It's easier to attack a single node than to try and attack them all."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7095#msg7095"},{"f":"Anonymous","d":1280798672,"b":[["q","> Quote from: throughput on August 02, 2010, 03:59:43 PM\n> > Quote from: kiba on August 02, 2010, 03:19:08 AM\n> > Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).\n>\n> For that to happen, someone should\n> a) notice what's happened\n> b) understand what's happened\n> c) make a decision on technically isolating two economies for ever\n> d) force that decision somehow.\n>\n> Question: who can be that entity, whitepaper says there is not any central authority, at all ?\n>\n> kiba what you say, that's impossible or whitepaper lies?\n\nThanks for addressing my concern!  I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly).  It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist.  I suppose each bitcoin community would properly fork the source code to do something along this line.\n\n> Quote from: Anonymous on August 02, 2010, 03:05:47 AM\n> If the US and China go to war you will have more things to worry about than bitcoins. Sad\n\nI don't know...I actually think that BitCoin would become popular as a resistance currency in wartime.  The State likes to enact all sorts of totalitarian BS during war, such as massive government spending <http://www.usgovernmentspending.com/spending_history>, massive inflation <http://mises.org/daily/3010>, collection of all scap or private metal <http://tvh.bfn.org/metal.html>, confiscation of private property <http://en.wikipedia.org/wiki/United_States_home_front_during_World_War_II#Taxes_and_controls>.  Even FDR in the economic emergency during 1933 outlawed private ownership of gold <http://en.wikipedia.org/wiki/Executive_Order_6102>.  But bit coin would be resistant to such measures, as long as the government doesn't shut down the internet <http://www.huffingtonpost.com/2010/06/25/internet-kill-switch-appr_n_625856.html>, which I doubt they would do since it would seriously cripple the economy and thereby destroy the tax base (although, I forgot how stupid can be sometimes), or somehow outlaw cryptography by regular folk, institute a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..","Quote from: em3rgentOrdr on August 02, 2010, 04:39:19 PM"],["q"," a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..","Quote"],["t","They can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are Smiley"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7124#msg7124"},{"f":"knightmb","d":1280811385,"b":[["t","I have a definitive answer for you all.\n\nI built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.\n\nSo to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7152#msg7152"},{"f":"Red","d":1280811572,"b":[["q","I have a definitive answer for you all.","Quote from: knightmb on August 03, 2010, 04:56:25 AM"],["t","Woot! Real facts! Nice!\n\nCool time machine thread too. Nice analysis!"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7153#msg7153"},{"f":"FreeMoney","d":1280819634,"b":[["q","I have a definitive answer for you all.\n\nI built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.\n\nSo to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.","Quote from: knightmb on August 03, 2010, 04:56:25 AM"],["t","Cool. I guess you aren't seeing the transactions being redone because the accounts had no valid coins at all, right?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7174#msg7174"},{"f":"throughput","d":1280839989,"b":[["q","I have a definitive answer for you all.\n\nI built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the \"outside\" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.\n\nSo to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.","Quote from: knightmb on August 03, 2010, 04:56:25 AM"],["t","So, I suggest not to concentrate heavily on preventing the network split, since that is inevitable event in the life of Internet,\nbut to invent some method to monitor connected computing power, to allow those, who bother, to stop processing transactions,\nuntil the network's majority reconnects back.\n\nPerhaps that would not be a realtime method, but a reasonable and fixed delay will still be accepted.\nI'm sure, GUI client or daemon should inform you about total computing power, but how can it be computed?\nDifficulty? It is too slowly updated.\nWhat is your variants?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7219#msg7219"},{"f":"BeeCee1","d":1280840843,"b":[["t","If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.\n\nImagine a cable cut, or series of cable cuts that isolated a block of countries.\n\n- Someone with bitcoin might initiate an oversees dialup connection\n- someone might have a satellite connection\n\nThese would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.\n\nSomeone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world. "]],"u":"https://bitcointalk.org/index.php?topic=661.msg7223#msg7223"},{"f":"throughput","d":1280842388,"b":[["q","If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.\n\nImagine a cable cut, or series of cable cuts that isolated a block of countries.\n\n- Someone with bitcoin might initiate an oversees dialup connection\n- someone might have a satellite connection\n\nThese would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.\n\nSomeone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.","Quote from: BeeCee1 on August 03, 2010, 01:07:23 PM"],["t","Yes...\nBut what you describe is only possible after someone have noticed and prooved the network split is happening.\nDo you propose any method to detect the beginning of the network split?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7230#msg7230"},{"f":"theymos","d":1280844286,"b":[["t","Satoshi posted about this concern:\nhttp://bitcointalk.org/index.php?topic=241.msg2071#msg2071"],["q","Yes...\nBut what you describe is only possible after someone have noticed and prooved the network split is happening.\nDo you propose any method to detect the beginning of the network split?","Quote from: throughput on August 03, 2010, 01:33:08 PM"],["t","You think people would fail to notice an entire ISP/country/continent falling off the Internet?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7239#msg7239"},{"f":"throughput","d":1280845496,"b":[["q","Satoshi posted about this concern:\nhttp://bitcointalk.org/index.php?topic=241.msg2071#msg2071\n\n> Quote from: throughput on August 03, 2010, 01:33:08 PM\n> Yes...\n> But what you describe is only possible after someone have noticed and prooved the network split is happening.\n> Do you propose any method to detect the beginning of the network split?\n\nYou think people would fail to notice an entire ISP/country/continent falling off the Internet?","Quote from: theymos on August 03, 2010, 02:04:46 PM"],["t","Why do you think, that what you describe will be the only reason for a Bitcoin network split?\nAnd if some people will know that a continent is disconnected, then why all others will be as informed?\nAnd even if everyone will know, that some amount of Internet is disconnected from the rest, then\nhow would they decide whether that is a good reason to stop processing (and sending) transactions?\nISP disconnectivity is not a rarity today, single misconfiguration may shutdown routing for a whole AS.\nWill that be enough reason to stop processing transactions or not?\nThe same with a country and continent.\n\nThe question is not wheter there exists some parts of Internet or Bitcoin network, that will reconnect later.\nYou may always answer YES here, at every moment they exists. My phone loses signal very often, for example.\n\nThe actual question is"],["q","Whether I am connected with a network, that will be a majority of nodes on reconnect, or not?","Quote"],["t","It is not possible to give a definitive answer about future, but you may estimate that almost accurately based on the size\nof the network before the split and the size of the network after the split.\nIf your network is not going to be a majority later, then it is safer to use another payment method, I suppose."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7242#msg7242"},{"f":"em3rgentOrdr","d":1280846152,"b":[["q","> Quote from: em3rgentOrdr on August 02, 2010, 04:39:19 PM\n>  a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..\nThey can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are Smiley","Quote from: Anonymous on August 03, 2010, 01:24:32 AM"],["t","Sad\n\nI suppose you are right, unfortunately: They can do all those things now...the only real thing stopping them is bad pr."],["q","If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.\n\nImagine a cable cut, or series of cable cuts that isolated a block of countries.\n\n- Someone with bitcoin might initiate an oversees dialup connection\n- someone might have a satellite connection\n\nThese would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.\n\nSomeone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.","Quote from: BeeCee1 on August 03, 2010, 01:07:23 PM"],["t","^^^ good points...I suppose that the demand for connectivity in the smaller network would produce an strong incentive to find some way, no matter how primitive, to connect the two networks.  It could even be as primitive as using (physical) snail mail or dialup."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7246#msg7246"},{"f":"BeeCee1","d":1280848362,"b":[["q","> Quote from: BeeCee1 on August 03, 2010, 01:07:23 PM\n> If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.\n>\n> Imagine a cable cut, or series of cable cuts that isolated a block of countries.\n>\n> - Someone with bitcoin might initiate an oversees dialup connection\n> - someone might have a satellite connection\n>\n> These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.\n>\n> Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.\nYes...\nBut what you describe is only possible after someone have noticed and prooved the network split is happening.\nDo you propose any method to detect the beginning of the network split?","Quote from: throughput on August 03, 2010, 01:33:08 PM"],["t","No, I am saying that given enough bitcoin users this is likely to happen, there is no need for them to notice that the bitcoin network split, either they notice that they can't check email/access websites outside of their local area and initiate a temporary alternate connection to the \"rest of the world\" or they just happen to take a laptop with bitcoin on an airplane.\n\nI am also not saying it is a good thing.  having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7249#msg7249"},{"f":"Gavin Andresen","d":1280860724,"b":[["q","I am also not saying it is a good thing.  having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.","Quote from: BeeCee1 on August 03, 2010, 03:12:42 PM"],["t","Transactions won't disappear if they're valid.  They'll just move to the longer block chain.\n\nInvalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).\n\nOr if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.\n\nFor shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat)."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7293#msg7293"},{"f":"jgarzik","d":1280862074,"b":[["q","For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).","Quote from: gavinandresen on August 03, 2010, 06:38:44 PM"],["t","It doesn't have to be someone trying to cheat.  You can be honest, and yet unlucky and get caught on the other side of a network split.  If you generate and spend coins on the unlucky side of the network split, the consequences are the same as for dishonest users."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7302#msg7302"},{"f":"knightmb","d":1280862133,"b":[["q","Transactions won't disappear if they're valid.  They'll just move to the longer block chain.\n\nInvalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).\n\nOr if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.\n\nFor shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).","Quote from: gavinandresen on August 03, 2010, 06:38:44 PM"],["t","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), it should be able to merge back to together without too many issues. So coin generation would probably be the only victim (if no double-spending cheats took place), or more technically, coin generation would be assigned to someone else that was generating at the same time as those that split off.\n\nIf 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?"]],"u":"https://bitcointalk.org/index.php?topic=661.msg7303#msg7303"},{"f":"MoonShadow","d":1280865682,"b":[["q","Yes...\nBut what you describe is only possible after someone have noticed and prooved the network split is happening.\nDo you propose any method to detect the beginning of the network split?","Quote from: throughput on August 03, 2010, 01:33:08 PM"],["t","I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening.  Each block in a row that takes longer than the average increases confidence against a false positive.  So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7314#msg7314"},{"f":"FreeMoney","d":1280874507,"b":[["q","> Quote from: throughput on August 03, 2010, 01:33:08 PM\n> Yes...\n> But what you describe is only possible after someone have noticed and prooved the network split is happening.\n> Do you propose any method to detect the beginning of the network split?\n\nI started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening.  Each block in a row that takes longer than the average increases confidence against a false positive.  So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.","Quote from: creighto on August 03, 2010, 08:01:22 PM"],["t","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.\n\nI'm probably misunderstanding."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7351#msg7351"},{"f":"satoshi","d":1280875507,"b":[["t","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."],["q","> Quote from: gavinandresen on August 03, 2010, 06:38:44 PM\n> Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.\nInteresting 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),","Quote from: knightmb on August 03, 2010, 07:02:13 PM"],["t","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."],["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?","Quote from: knightmb on August 03, 2010, 07:02:13 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=661.msg7356#msg7356","s":1,"n":312,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/312/"}]},{"id":"p158","k":"p","s":"bitcointalk","t":"Multiple Wallets, one computer (multiple accounts)","u":"https://bitcointalk.org/index.php?topic=665","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/158/","m":[{"f":"bytemaster","d":1280693669,"b":[["t","I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis.  The equiv. of having multiple wallets running at the same time.  \n\nIt would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins.  "]],"u":"https://bitcointalk.org/index.php?topic=665.msg6928#msg6928"},{"f":"Insti","d":1280704463,"b":[["q","It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins. ","Quote from: bytemaster on August 01, 2010, 08:14:29 PM"],["t","+1"]],"u":"https://bitcointalk.org/index.php?topic=665.msg6940#msg6940","sj":"Re: Multiple Wallets, one computer"},{"f":"lfm","d":1280705097,"b":[["q","I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis.  The equiv. of having multiple wallets running at the same time.   \n\nIt would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins. ","Quote from: bytemaster on August 01, 2010, 08:14:29 PM"],["t","Would it help to use the attached messages you have when sending to an IP address? It should be easy to record a \"sending ip address\" in that case also."]],"u":"https://bitcointalk.org/index.php?topic=665.msg6945#msg6945","sj":"Re: Multiple Wallets, one computer"},{"f":"bytemaster","d":1280711835,"b":[["t","Nope, I really need it on a per-receiving address so that it is easy to directly track the balances from customers paying me.  "]],"u":"https://bitcointalk.org/index.php?topic=665.msg6952#msg6952","sj":"Re: Multiple Wallets, one computer"},{"f":"kwukduck","d":1285181992,"b":[["t","It's something im missing too, it would be nice to have seperate 'accounts' with each it's own balance and transactions. One for personal use, one for business, etc."]],"u":"https://bitcointalk.org/index.php?topic=665.msg13713#msg13713","sj":"Re: Multiple Wallets, one computer"},{"f":"lfm","d":1285489451,"b":[["q","I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis.  The equiv. of having multiple wallets running at the same time.   \n\nIt would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins. ","Quote from: bytemaster on August 01, 2010, 08:14:29 PM"],["t","I guess one way to do this would be use the -datadir=<dir>  command line arg to specify a data directory (other than the default \"$(HOME)/.bitcoin/\"). You would only run the client on one directory at a time. (Note the directory is relative to the current directory for the SERVER bitcoind. Its safest to specify a fully qualified directory starting at the root.) Also of course the client does not need to be running  on any specific directory nor running at all to receive payments to addresses in any/all of the wallets."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14090#msg14090","sj":"Re: Multiple Wallets, one computer"},{"f":"nelisky","d":1285496071,"b":[["q","> Quote from: bytemaster on August 01, 2010, 08:14:29 PM\n> I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis.  The equiv. of having multiple wallets running at the same time.   \n>\n> It would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins. \n\nI guess one way to do this would be use the -datadir=<dir>  command line arg to specify a data directory (other than the default \"$(HOME)/.bitcoin/\"). You would only run the client on one directory at a time. (Note the directory is relative to the current directory for the SERVER bitcoind. Its safest to specify a fully qualified directory starting at the root.) Also of course the client does not need to be running  on any specific directory nor running at all to receive payments to addresses in any/all of the wallets.","Quote from: lfm on September 26, 2010, 08:24:11 AM"],["t","Yeah, I've been considering how to best go about this for the web services. Right now multiple services on the same machine run multiple clients bound to separate rpc ports. It works... to a point.\n\nWhat I want is a separate wallet per user, and that scales pretty badly, so what I thought could be done is have multiple wallets in memory at the same time, based on some key (which would be the subdir inside the datadir for the wallet) and the rpc calls would take a -wallet= switch. I just don't know how many wallets I would be able to keep in memory at the same time, and I would loose the ability to move money instantly amongst them, but that's ok, I guess.\n\nA slightly more scalable alternative would be to lazily load the wallets on demand. I know wallets keep a bunch of information, but maybe we could limit that to own addresses and transactions?\n\nSatoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn Smiley"]],"u":"https://bitcointalk.org/index.php?topic=665.msg14096#msg14096","sj":"Re: Multiple Wallets, one computer"},{"f":"jimbobway","d":1285559618,"b":[["t","Can you just create a new windows user and log in with that user?  Bitcoin creates a directory per windows user, I think."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14193#msg14193","sj":"Re: Multiple Wallets, one computer"},{"f":"theymos","d":1285562044,"b":[["t","You could create an additional database file with public keys associated with usernames/passwords. Creating an address logs the resulting public key to the new database (in addition to wallet.dat); CreateTransaction is modified to only select coins from those addresses associated with the account; the various \"list transactions\" commands are modified to only tally/show transactions to addresses associated with the account; new commands are added to transfer keys from one account to another. You could make it possible to transfer funds (without the keys) from one account to another without a real transaction, but this would involve much more complexity.\n\nImplementation wouldn't be too difficult, I think (if you don't have to deal with the UI). The worst part would be dealing with the new database file and figuring out how to replace the existing authentication with your own stuff."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14199#msg14199","sj":"Re: Multiple Wallets, one computer"},{"f":"throughput","d":1285595298,"b":[["q","Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn Smiley","Quote from: nelisky on September 26, 2010, 10:14:31 AM"],["t","I'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,\nfree from his dictatorship and tyranny. That is solely my own opinion.\n\nFor the techical issue discussed: It is clear, that the \"node\" instance, that holds the blocks database, connects to the network,\nexchanges data with peers and with users, is architecturally independent from the \"wallet\" instance(s).\nWallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.\n\nSo it is feasible to have \"block chain\" daemon, that will cache block database on disk and may also act as an intermediary\nbetween the local users and \"the network\", so it will have no secret keys at all, no sensitive information.\nAnd the local \"wallets\" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no \"bind to port 8XXX\" issue.\nThey will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.\nAnd so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like \"getreceivedbyaddr\" does now.\n\nGeneration should happen at admin's local wallet, not at the networking node. That means \"wallets\" will be permitted to publish not only transactions, but solved blocks too.\n\nFor current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.\nSo the only hope is the alternative implementations, that aren't possible without the standard."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14243#msg14243","sj":"Re: Multiple Wallets, one computer"},{"f":"nelisky","d":1285595765,"b":[["q","> Quote from: nelisky on September 26, 2010, 10:14:31 AM\n> Satoshi: are you planning on doing any of this? As I'm not familiar with this part of the code, it would suck to spend a week trying to figure out the best way to do this and then you pushing the perfect implementation to svn Smiley\n\nI'm sure, Satoshi should better plan documenting the protocol as a standard, so we will have interoperable implementations,\nfree from his dictatorship and tyranny. That is solely my own opinion.\n\nFor the techical issue discussed: It is clear, that the \"node\" instance, that holds the blocks database, connects to the network,\nexchanges data with peers and with users, is architecturally independent from the \"wallet\" instance(s).\nWallet(s) may be viewed as peer(s), that request the block data and publish transactions/blocks, like network peers do now.\n\nSo it is feasible to have \"block chain\" daemon, that will cache block database on disk and may also act as an intermediary\nbetween the local users and \"the network\", so it will have no secret keys at all, no sensitive information.\nAnd the local \"wallets\" will have no networking part, no network interoperability problems, except for connecting to the daemon. So there will be no \"bind to port 8XXX\" issue.\nThey will be free from the P2P stuff, will only work in a client-server paradigm, will trust the server for executing their requests, but will not trust the server with any secret information.\nAnd so, they may be as simple, as system-on-a-chip cards, capable of iterating through the blocks/transactions list, but not required to store it. The block chain database may also return narrow results, parameterised by the list of public keys, like \"getreceivedbyaddr\" does now.\n\nGeneration should happen at admin's local wallet, not at the networking node. That means \"wallets\" will be permitted to publish not only transactions, but solved blocks too.\n\nFor current codebase this is a major refactoring, I'm sure Satoshi will veto on it, and he may have his own merits.\nSo the only hope is the alternative implementations, that aren't possible without the standard.","Quote from: throughput on September 27, 2010, 01:48:18 PM"],["t","Well put, the standard is certainly needed to move this into mainstream, and source code as documentation sucks. But that is slightly longer, more important goal, not one I will hold off on projects for. I'm sure you agree the standard definition alone will take a good amount of time, especially when people look at it and start saying what if, or wouldn't it be better if... Then we still have to develop standards compliant clients.\n\nI'm not saying that effort isn't worth it, much the opposite, it's mandatory for the immediate future. This hack jobs we do are actually a great way to get to know how things are being done, thus gathering any knowledge to help in describing the protocol Smiley"]],"u":"https://bitcointalk.org/index.php?topic=665.msg14246#msg14246","sj":"Re: Multiple Wallets, one computer"},{"f":"Gavin Andresen","d":1285600495,"b":[["t","The \"label\" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.\n\nIf the API was extended as I describe below, would it solve the same problems as having multiple wallets?\n\nProposal:\n\n+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>\n  (change generated would be automatically tagged with <label>)\n+ add optional [label] param to getbalance.\n+ new method: listsentbylabel\n  (returns array of [ \"address\" : \"bcaddresssentto\", \"amount\" : x.yz, \"confirmations\": n ])\n\nEach customer \"account\" would be a bitcoin <label>.  Account handling would look like:\n\nCreate account / create new address for account:\n  getnewaddress [account_id_label]\n   ... tell user \"fund your account by sending coins to {the address returned}\"\n\nCustomer withdraws/spends:\n  sendfrom [account_id_label] [address] [amount]\n   (FAILS if balance for that account too low)\n\nShow customer their balance:\n  getbalance [account_id_label]\n\nShow customer their transactions in/out\n  listreceivedbylabel [account_id_label]\n  listsentbylabel [account_id_label]\n\n---------\n\nSeems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer.  At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14254#msg14254","sj":"Re: Multiple Wallets, one computer"},{"f":"nelisky","d":1285601639,"b":[["q","The \"label\" mechanism (setlabel / getreceivedbylabel) is supposed to meet this need, but only solves part of the problem.\n\nIf the API was extended as I describe below, would it solve the same problems as having multiple wallets?\n\nProposal:\n\n+ new send method: send TO a given bitcoin address specifically FROM the bitcoins sent to <label>\n  (change generated would be automatically tagged with <label>)\n+ add optional [label] param to getbalance.\n+ new method: listsentbylabel\n  (returns array of [ \"address\" : \"bcaddresssentto\", \"amount\" : x.yz, \"confirmations\": n ])\n\nEach customer \"account\" would be a bitcoin <label>.  Account handling would look like:\n\nCreate account / create new address for account:\n  getnewaddress [account_id_label]\n   ... tell user \"fund your account by sending coins to {the address returned}\"\n\nCustomer withdraws/spends:\n  sendfrom [account_id_label] [address] [amount]\n   (FAILS if balance for that account too low)\n\nShow customer their balance:\n  getbalance [account_id_label]\n\nShow customer their transactions in/out\n  listreceivedbylabel [account_id_label]\n  listsentbylabel [account_id_label]\n\n---------\n\nSeems to me this would be a much better direction to go in, rather than having separate wallet.dat files for each customer.  At the very least, backing up thousands of customer's wallet files would be inefficient and error-prone, and constantly switching between them would also be incredibly inefficient.","Quote from: gavinandresen on September 27, 2010, 03:14:55 PM"],["t","That is a much better approach, agreed. Assuming one label spans multiple addresses, so a client can accept transactions from an imported priv key (this being discussed on another thread), it seems to fit my needs perfectly, with only one small caveat which is internal transfers; say I use this approach for the lottery users (though that is not my use case, I actually would be more about site separation than user separation, but still):\n- Each account has on inbound address, annotated with the login label\n- Every time a user withdraws, I use the sendfrom mechanism you describe\n- The user hits the jackpot, but the prize is actually held in multiple users' accounts so\n  a) I need to, when users buy tickets, move the amount to a separate address (forces external transaction, sucks)\n  b) I leave coins where they are, and then on payout I make a normal sendtoaddress (both external transaction and breaks the label accounting logic)\n  c) I leave coins where they are, payouts do nothing to the wallet, withdrawals do as many transactions as needed from each user account (what a nightmare!)\n\nI don't see any good option here, and the best one, if I'm doing external transactions anyway, is a). I can trust these transactions with 0 blocks confirmed, because I'm both the sender and the recipient, and this would keep the accounts/labels in check, which serves as a great verification to the overall balances. Can you think of any alternative?"]],"u":"https://bitcointalk.org/index.php?topic=665.msg14259#msg14259","sj":"Re: Multiple Wallets, one computer"},{"f":"Gavin Andresen","d":1285607433,"b":[["t","Separate \"accounts\" (addresses with labels) to accumulate Jackpots is the right idea.  Users buy tickets, bitcoins are moved to the appropriate Jackpot account.  When a Jackpot is won, transactions flow out of its account back to whoever won."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14264#msg14264","sj":"Re: Multiple Wallets, one computer"},{"f":"nelisky","d":1285607778,"b":[["q","Separate \"accounts\" (addresses with labels) to accumulate Jackpots is the right idea.  Users buy tickets, bitcoins are moved to the appropriate Jackpot account.  When a Jackpot is won, transactions flow out of its account back to whoever won.","Quote from: gavinandresen on September 27, 2010, 05:10:33 PM"],["t","Yeah, it is quite obvious. I suffer for over optimization obsession syndrome Smiley 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."]],"u":"https://bitcointalk.org/index.php?topic=665.msg14265#msg14265","sj":"Re: Multiple Wallets, one computer"},{"f":"satoshi","d":1287947871,"b":[["t","I have the beginning of something like this.  It's mostly like what Gavin described.\n\nSome more rpc interface:\n\nmove <fromaccount> <toaccount> <amount>\n   Move 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.\n   Is \"move\" the best name for this?  I shied away from \"transfer\" because that sounds too close to sending a transaction.\n\nI'm thinking a new function getaccountaddress instead of overloading getnewaddress:\n\ngetaccountaddress <account>\n   Gives 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)\n\nWould these commands make it possible in simple cases to implement your website without needing a database of your own?"]],"u":"https://bitcointalk.org/index.php?topic=665.msg18349#msg18349","s":1,"n":497,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/497/","sj":"Re: Multiple Wallets, one computer"},{"f":"grondilu","d":1287948564,"b":[["t","Wouldn't it be much simpler to be able to run several instances of bitcoin, each of them running on a specific \"wallet.dat\" file ?\n\nI mean, we would just add a --wallet long option to the client/server app.  The name of your account would be the name of your wallet file."]],"u":"https://bitcointalk.org/index.php?topic=665.msg18351#msg18351","sj":"Re: Multiple Wallets, one computer"},{"f":"SmokeTooMuch","d":1287953912,"b":[["q","I want to have multiple \"accounts\" with unique balances and to send and receive coins on a per-account basis.  The equiv. of having multiple wallets running at the same time.   \n\nIt would help to simply list the balance for each 'receiving address' and to specify a 'source' address when sending coins. ","Quote from: bytemaster on August 01, 2010, 08:14:29 PM"],["t","use -datadir and change the port on the source code and then use a different dir and port for every bitcoin instance"]],"u":"https://bitcointalk.org/index.php?topic=665.msg18367#msg18367","sj":"Re: Multiple Wallets, one computer"},{"f":"satoshi","d":1288025633,"b":[["t","Here's some pseudocode of how you would use the account based commands.  It sure makes website integration a lot easier.\n\nprint \"send to \" + getaccountaddress(username) + \" to fund your account\"\nprint \"balance: \" + getbalance(username, 0)\nprint \"available balance: \" + getbalance(username, 6)\n\n// if you make a sale, move the money out of their account\nmove(username, \"\", amount, 6)\n\n// withdrawal\nsendfrom(username, bitcoinaddress, amount, 6)"]],"u":"https://bitcointalk.org/index.php?topic=665.msg18508#msg18508","s":1,"n":498,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/498/","sj":"Re: Multiple Wallets, one computer"}]},{"id":"p159","k":"p","s":"bitcointalk","t":"Porn","u":"https://bitcointalk.org/index.php?topic=671","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/159/","m":[{"f":"Anonymous","d":1280754723,"b":[["t","asdf"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7000#msg7000","sj":"adf"},{"f":"RHorning","d":1280755338,"b":[["t","I hate to say this, but I think davidonpda  is completely correct.  This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.\n\nTake this as a business idea if you want, but charging 0.01 BTC per image download, 0.10 BTC per movie, and 0.05 BTC per audio clip sounds like something that could catch on real well.\n\nThen again, even if you didn't want to necessarily get into porn, you could still do that in terms of building up some sort of licensed media library where folks could download images of say sunsets, bridges, and other high quality stuff (aka screensavers, etc.) and maybe a sound effects library.  There is a market for stuff like this, and charging small amounts for individual pieces could be a lot of fun."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7002#msg7002"},{"f":"mtgox","d":1280755392,"b":[["t","I think bitcoin poker will really establish the BTC."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7004#msg7004"},{"f":"kiba","d":1280756325,"b":[["q","I hate to say this, but I think davidonpda  is completely correct.  This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.\n\nTake this as a business idea if you want, but charging 0.01 BTC per image download, 0.10 BTC per movie, and 0.05 BTC per audio clip sounds like something that could catch on real well.","Quote from: RHorning on August 02, 2010, 01:22:18 PM"],["t","You hate to say this? You don't like porn or something?"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7005#msg7005"},{"f":"Anonymous","d":1280756621,"b":[["q","I'd like to refer your attention to the walmart thread if you haven't read it already http://bitcointalk.org/index.php?topic=659.0\n\nThe easiest industry to get on board of bitcoin? Come on... micropayment capable... a little anonymous? No adult store names on the credit card receipt? Someone should make a BitPorn store if they want to see bitcoins really catch on haha.  Shocked","Quote from: davidonpda on August 02, 2010, 01:12:03 PM"],["t","lmao\n\nI dont know about the \"micro\" part\n\n Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7006#msg7006"},{"f":"nelisky","d":1280759614,"b":[["t","I believe there's a huge difference between porn (which is art, weather you like it or not) and poker (or, as the governments like to put it, gambling). Basically, gambling is highly legislated, and online gambling even more so these days. The sites need to keep records of everything and while BTCs could be seen as 'play money' that would only work to a point, I believe.\n\nPorn, on the other hand, is just art (so as long as all those involved are at or above legal age, of course) and, \"no dear, of course I don't browse those stupid misogynous sites\" but I would certainly pay in bitcoins for that because... ahem... I want to help the economy pick up.\n\nIt would also rock at poker, sure, but I don't think any of the established sites will want to venture a government action because they allow 'anonymous money' to go in."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7012#msg7012"},{"f":"kiba","d":1280759813,"b":[["t","Why does the government hates internet gambling? Huh"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7013#msg7013"},{"f":"kiba","d":1280768592,"b":[["q","I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.\n\nYou could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.","Quote from: davidonpda on August 02, 2010, 04:56:13 PM"],["t","Who will provide the p0rn?"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7044#msg7044"},{"f":"nelisky","d":1280768723,"b":[["q","Why does the government hates internet gambling? Huh","Quote from: kiba on August 02, 2010, 02:36:53 PM"],["t","Why would you assume they hate it? The problem, afaict, is just controlling it. It's hard, almost as hard as the drug market. If they find a way to prevent anyone from gambling online without their approval and scrutiny, then you'll see online gambling on government sponsored ads everywhere (with a disclaimer saying \"gamble responsibly\" in very small letters). The same applies to bitcoins in general, it is just something they don't control which means can't easily tax, which obviously is seen as a threat, especially when they have a concurrent thing, which is controlled and taxed by said governments."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7045#msg7045"},{"f":"imnichol","d":1280769236,"b":[["q","> Quote from: davidonpda on August 02, 2010, 04:56:13 PM\n> I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.\n>\n> You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.\n\nWho will provide the p0rn?","Quote from: kiba on August 02, 2010, 05:03:12 PM"],["t","Wink"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7050#msg7050"},{"f":"Anonymous","d":1280799211,"b":[["t","Great...now we have to put up with ads for adultfriendfinder   Smiley\n\nI used to own the domain name sexrssize  Cheesy  \n\nGive people free iphone 4's to perform on facetime for 10 bitcoins a minute........  Cool"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7127#msg7127"},{"f":"skull88","d":1280857842,"b":[["q","> Quote from: davidonpda on August 02, 2010, 04:56:13 PM\n> I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.\n>\n> You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.\n\nWho will provide the p0rn?","Quote from: kiba on August 02, 2010, 05:03:12 PM"],["t","I have some sparetime  Grin\n\n...but I guess my girlfriend will be a little bit less happy with the idea"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7281#msg7281"},{"f":"mtgox","d":1280872511,"b":[["t","Poker sites aren't illegal in a lot of places. In fact they aren't illegal in the US. It is just illegal to fund the site with a credit card and even that is about to be repealed it looks like:\nhttp://en.wikipedia.org/wiki/Online_gambling"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7346#msg7346"},{"f":"ichi","d":1280875457,"b":[["q","Who will provide the p0rn?","Quote from: kiba on August 02, 2010, 05:03:12 PM"],["t","It's my impression that most online porn these days is made by amateurs.  That really annoys the professionals, or so I've read."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7355#msg7355"},{"f":"FreeMoney","d":1280876689,"b":[["q","Poker sites aren't illegal in a lot of places. In fact they aren't illegal in the US. It is just illegal to fund the site with a credit card and even that is about to be repealed it looks like:\nhttp://en.wikipedia.org/wiki/Online_gambling","Quote from: mtgox on August 03, 2010, 09:55:11 PM"],["t","You mean to say that playing poker at poker sites is not illegal in the US, right?\nRunning one would not be legal, afaik.\n\nDo you play much online?"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7359#msg7359"},{"f":"Anonymous","d":1280881057,"b":[["q","> Quote from: kiba on August 02, 2010, 05:03:12 PM\n> > Quote from: davidonpda on August 02, 2010, 04:56:13 PM\n> > I'm not saying I'd start it because of moral reasons, I'm just tossing out the idea that maybe hasn't been thought of too much yet.\n> >\n> > You could still pay by the month, by the day, or as mentioned per video or picture. Nice simple payments across an open p2p system.\n>\n> Who will provide the p0rn?\nI have some sparetime  Grin\n\n...but I guess my girlfriend will be a little bit less happy with the idea","Quote from: skull88 on August 03, 2010, 05:50:42 PM"],["t","lmao"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7375#msg7375"},{"f":"FreeMoney","d":1280884703,"b":[["q","> Quote from: kiba on August 02, 2010, 05:03:12 PM\n> Who will provide the p0rn?\nIt's my impression that most online porn these days is made by amateurs.  That really annoys the professionals, or so I've read.","Quote from: ichi on August 03, 2010, 10:44:17 PM"],["t","It's the opposite for poker. More amateurs is good for the pros ;-)\n\nIf we could just find a way for the pros to do porn vs amateurs I think everyone would be happy."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7389#msg7389"},{"f":"ichi","d":1280901654,"b":[["q","If we could just find a way for the pros to do porn vs amateurs I think everyone would be happy.","Quote from: FreeMoney on August 04, 2010, 01:18:23 AM"],["t","Actually, I believe that the future of professional porn is MMRPG with AIs and dongles  Wink"]],"u":"https://bitcointalk.org/index.php?topic=671.msg7441#msg7441"},{"f":"RHorning","d":1280930062,"b":[["q","> Quote from: RHorning on August 02, 2010, 01:22:18 PM\n> I hate to say this, but I think davidonpda  is completely correct.  This is the one business that does seem to take technology seriously and is an early adopter for new ideas and concepts.\n\nYou hate to say this? You don't like porn or something?","Quote from: kiba on August 02, 2010, 01:38:45 PM"],["t","Been there, done that in terms of getting tied up with the porn industry.  Some of the people involved on a full-time level in the \"porn industry\" certainly are folks you would not want hanging around your kids, or for that matter even being around at all.  I'm sort of lucky I'm even still alive frankly for even having been however briefly associated with this crowd.  Money is to be made, but there is a price to be paid.  Make sure you are willing to pay the price and know very well what the price is that has to be paid when getting into an enterprise like this.\n\nThe guys that make you pay don't care about courts, and many are into.... let's just say other enterprises of questionable legality."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7474#msg7474"},{"f":"FreeMoney","d":1280946720,"b":[["q","Been there, done that in terms of getting tied up with the porn industry.  ","Quote from: RHorning on August 04, 2010, 01:54:22 PM"],["t","Bondage is a fairly common fetish, afaik."]],"u":"https://bitcointalk.org/index.php?topic=671.msg7561#msg7561"},{"f":"skull88","d":1281403495,"b":[["q","It would also rock at poker, sure, but I don't think any of the established sites will want to venture a government action because they allow 'anonymous money' to go in.","Quote from: nelisky on August 02, 2010, 02:33:34 PM"],["t","http://www.pokerth.net/\n\ncould be a winning combination..."]],"u":"https://bitcointalk.org/index.php?topic=671.msg8456#msg8456"},{"f":"joechip","d":1282044007,"b":[["q","Why does the government hates internet gambling? Huh","Quote from: kiba on August 02, 2010, 02:36:53 PM"],["t","B/c they can't tax it.\n\nTa,"]],"u":"https://bitcointalk.org/index.php?topic=671.msg9892#msg9892"},{"f":"em3rgentOrdr","d":1284443565,"b":[["q","> Quote from: kiba on August 02, 2010, 02:36:53 PM\n> Why does the government hates internet gambling? Huh\n\nB/c they can't tax it.\n\nTa,","Quote from: joechip on August 17, 2010, 11:20:07 AM"],["t","DING! DING! DING! DING! DING!"]],"u":"https://bitcointalk.org/index.php?topic=671.msg12687#msg12687"},{"f":"Insti","d":1284454644,"b":[["q","> Quote from: joechip on August 17, 2010, 11:20:07 AM\n> > Quote from: kiba on August 02, 2010, 02:36:53 PM\n> > Why does the government hates internet gambling? Huh\n>\n> B/c they can't tax it.\n>\n> Ta,\n\nDING! DING! DING! DING! DING!","Quote from: em3rgentOrdr on September 14, 2010, 05:52:45 AM"],["t","The UK government seems to be doing an OK job of it."]],"u":"https://bitcointalk.org/index.php?topic=671.msg12710#msg12710"},{"f":"The Madhatter","d":1284460758,"b":[["t","I'll say this from experience.. a lot experience.. Don't ask. Wink\n\nThe online adult market won't adopt Bitcoin easily. The type of person who buys online porn is a 'revolver' of credit. They don't have money to spend on porn. They *need* credit. That's why credit cards work so well.\n\nBitcoin is too difficult for the average guy to use. He wants porn. He doesn't care about hashing/encrypting/p2p. No amount of convincing will tell him that Bitcoin is better than a credit card. Also, the thought of downloading and installing an application is scary to an experienced porn customer. They've all had their fair share of viruses, excessive popups from CJ sites, and other general web annoyances.\n\nPorn sites won't adopt Bitcoin because it is a waste of time. It can't do recurring billing. That is their bread and butter. Being able to silently just keep billing someone's credit card, until they cancel, is what fuels their affiliate programs and their promises to pay $150-$200 per sale (aka \"join\") to affiliates.\n\nLets say that you solved some of these problems by directing porn customers and merchants to a web interface system like MyBitcoin. Let's also say that they have a working shopping cart system for the merchants. I'll explain the problems with that next...\n\nYou could get porn customers to use it. But, you'd end up with the problem of funding the wallet. Assuming that the customer doesn't easily give up. (They *buy* porn because finding it for free is too much of a hassle. They are *LAZY*.) The customer will seek out PayPal or credit card to Bitcoin exchangers. (They stick with what they know.) The liabilities would be held by the exchangers. The levels of chargebacks will slowly increase on these exchangers until they are out of business.\n\nAfter that happens, it would grind to a halt. Merchants would drop it like a hot potato. They are used to dropping payment options. It is their first reaction when something goes wrong. The online adult industry is riddled with bank/Visa/whatever freeze-ups.\n\nFrom the merchant side, you'd have the problem of \"cashing out\". The porn merchants don't give a damn about your virtual currency. They want dollars. MyBitcoin, in this example, would have to guarantee to buy (under contract) every single Bitcoin or no merchant in their right mind would use it. Sure, they could pass the Bitcoins to their affiliates/promoters to alleviate some of their liabilities. This would require some serious adoption (and convincing) across the entire industry.\n\nThe only viable option for Bitcoin in the adult arena is the micropayment one. Period. You'd have to supply absolutely *all* of the web technology. (Customer AND merchant.) It would have to be entirely web-based. You'd have to guarantee, in writing, to buy each coin back. This would only work on a few sites. Sites that sell porn per image, video, software download, etc. Sites that don't rely on recurring revenues.\n\nPersonal reservations aside; the fastest way to encourage adoption would be a dumbed-down HYIP."]],"u":"https://bitcointalk.org/index.php?topic=671.msg12721#msg12721"},{"f":"Anonymous","d":1284462697,"b":[["t"," I wouldnt sell porn directly with bitcoins.What I would do is setup an adult verification service using bitcoins that has agreements with other avs companies to accept your avs as acceptable. Customers could then use their sites without having to reveal identity or credit card info.\n\n Smiley"]],"u":"https://bitcointalk.org/index.php?topic=671.msg12728#msg12728"},{"f":"The Madhatter","d":1284464897,"b":[["t","Just an FYI: AVS is a scam. They don't verify anything. AVS has nothing to do with verifying someone's age.\n\nThey came about to skirt the Visa regulations on selling porn. (Around 2001) They claim to Visa that they are selling an age verification service and not porn. This evolved into \"ticket service providers\" who would sell tickets that could be redeemed for porn, and many other systems that 'skirt' the banking rules.\n\nAre you really going to verify the age of the customer? You are going to sell them an anonymous currency and then ask for ID? Do you really think that current AVSes want Bitcoins? They rely on selling recurring billing.\n\nSorry to burst your bubble. Smiley I'm not trying to be mean. I'm just being realistic."]],"u":"https://bitcointalk.org/index.php?topic=671.msg12738#msg12738"},{"f":"Babylon","d":1285218119,"b":[["q","I think bitcoin poker will really establish the BTC.","Quote from: mtgox on August 02, 2010, 01:23:12 PM"],["t","I disagree.  All you can get with bitcoins by playing poker is bitcoins.  Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.\n\nI think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me.  "]],"u":"https://bitcointalk.org/index.php?topic=671.msg13789#msg13789"},{"f":"thrashaholic","d":1285218410,"b":[["q","> Quote from: mtgox on August 02, 2010, 01:23:12 PM\n> I think bitcoin poker will really establish the BTC.\n\nI disagree.  All you can get with bitcoins by playing poker is bitcoins.  Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.\n\nI think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me. ","Quote from: Babylon on September 23, 2010, 05:01:59 AM"],["t","Why not replace SharingMatrix/MegaUpload/et. al with a (user friendly) bitcoin based file host, and get all the \"free\" porn sites (like adultbay, for instance) to use it instead. I'd actually pay for the increased bandwidth and concurrent downloads if I didn't have to risk my personal and CC details and those evil, evil automatic recurring payments.\n\nThis way we can use porn (and music blogs) in a roundabout way."]],"u":"https://bitcointalk.org/index.php?topic=671.msg13794#msg13794"},{"f":"kiba","d":1285257307,"b":[["q","> Quote from: Babylon on September 23, 2010, 05:01:59 AM\n> > Quote from: mtgox on August 02, 2010, 01:23:12 PM\n> > I think bitcoin poker will really establish the BTC.\n>\n> I disagree.  All you can get with bitcoins by playing poker is bitcoins.  Gambling is also nowhere near as big a market as porn and it does not really benefit as much from the possibility of micropayments.\n>\n> I think bitporn would be an excellent idea and if someone starts developing it I hope they will contact me. \n\nWhy not replace SharingMatrix/MegaUpload/et. al with a (user friendly) bitcoin based file host, and get all the \"free\" porn sites (like adultbay, for instance) to use it instead. I'd actually pay for the increased bandwidth and concurrent downloads if I didn't have to risk my personal and CC details and those evil, evil automatic recurring payments.\n\nThis way we can use porn (and music blogs) in a roundabout way.","Quote from: thrashaholic on September 23, 2010, 05:06:50 AM"],["t","Yeah, Bitcoin serve as good captcha. "]],"u":"https://bitcointalk.org/index.php?topic=671.msg13826#msg13826"},{"f":"satoshi","d":1285264615,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=671.msg13844#msg13844","s":1,"n":460,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/460/","qt":["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."],"qc":["general"]}]},{"id":"p160","k":"p","s":"bitcointalk","t":"Bitcoind x86 binary for CentOS","u":"https://bitcointalk.org/index.php?topic=685","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/160/","m":[{"f":"nimnul","d":1280831593,"b":[["t","Does anyone have the binary?"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7207#msg7207"},{"f":"knightmb","d":1280843119,"b":[["q","Does anyone have the binary?","Quote from: nimnul on August 03, 2010, 10:33:13 AM"],["t","Which version? I haven't tried to build any yet, but after building on a few different distro so far, kind of got the process down pat.  Wink\n\nI've got a CentOS 5.5 machine I could experiment with."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7231#msg7231"},{"f":"nimnul","d":1280843636,"b":[["t","[foo@bar ~]# cat /etc/issue\nCentOS release 5.5 (Final)\n\n[foo@bar ~]# uname -a\nLinux foo.bar 2.6.18-194.3.1.el5.028stab069.6 #1 SMP Wed May 26 18:31:05 MSD 2010 i686 i686 i386 GNU/Linux"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7234#msg7234"},{"f":"knightmb","d":1280844573,"b":[["t","Cool, we could both use a build then  Wink"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7241#msg7241"},{"f":"knightmb","d":1280851085,"b":[["t","My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?\n\nAnyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7255#msg7255"},{"f":"knightmb","d":1280852459,"b":[["t","Apparently, even after copying over the header file; those libraries are disabled, grrrr.\n\nGuess I'll have to hack one together  Cry"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7261#msg7261"},{"f":"knightmb","d":1280853177,"b":[["t","Ok, got around the encryption issue (guess it's never going to be part of the Cent OS library since they don't use that part of openssl), legal issues aside, just left with the DB issues during compile, so I'll need to compile a db4.7 version and hopefully we'll have a test build here soon."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7265#msg7265"},{"f":"nimnul","d":1280856118,"b":[["t","Yes, it's not that simple - otherwise I could have compiled it myself.\n\n1) In CentOS OpenSSL rpm elliptic curves cryptography is disabled, so you have to build OpenSSL yourself.\n2)  CentOS Boost-devel RPM is outdated and missing a lot of things, so you have to build Boost yourself too.\n3) CentOS WxWidgets RPM is outdated so you have to build it yourself too. And its build requires more than 256 mb ram. Satoshi improved bitcoind so doesn't require wxWidgets any more, but I'm not sure whether that patch is in 0.3.7 or whatever sources you are building."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7272#msg7272"},{"f":"knightmb","d":1280856568,"b":[["t","I've been able to get around all of those, I'm actually stuck at the DB4.7 stuff.\n\nI build it directly from the source and during the compile I get an error:"],["c","db_cxx.h:1083: error: expected class-name before ‘{’ token"],["t","I checked the header file, I think there is a syntax error, but not sure.\n\nAny suggestions?\n\nThis is the block of code it stalls at, the class is defined at the top of the file, so I'm not sure why it hangs at that error without digging through all the Berkeley DB code. I don't want to go to a newer version of the DB if it's going to mess with everyone's BitCoin database that uses this build."],["c","// Almost any error in the DB library throws a DbException.\n// Every exception should be considered an abnormality\n// (e.g. bug, misuse of DB, file system error).\n//\nclass _exported DbException : public __DB_STD(exception)\n{\npublic:\n virtual ~DbException() throw();\n DbException(int err);\n DbException(const char *description);\n DbException(const char *description, int err);\n DbException(const char *prefix, const char *description, int err);\n int get_errno() const;\n virtual const char *what() const throw();\n DbEnv *get_env() const;\n void set_env(DbEnv *dbenv);\n\n DbException(const DbException &);\n DbException &operator = (const DbException &);\n\nprivate:\n void describe(const char *prefix, const char *description);\n\n char *what_;\n int err_;                   // errno\n DbEnv *dbenv_;\n};"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7274#msg7274"},{"f":"sgtstein","d":1280856637,"b":[["t","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. Undecided"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7275#msg7275"},{"f":"knightmb","d":1280856726,"b":[["q","{snip} And its build requires more than 256 mb ram. Satoshi improved bitcoind so doesn't require wxWidgets any more, but I'm not sure whether that patch is in 0.3.7 or whatever sources you are building.","Quote from: nimnul on August 03, 2010, 05:21:58 PM"],["t","Yeah, the bitcoind build gets around any errors for those, but I still get stuck at the DB error.  Sad"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7277#msg7277"},{"f":"knightmb","d":1280858352,"b":[["t","Just for kicks, tried to compile with DB4.8 got the same error, LOL (the line number was slightly different, but at the same class)\n\nDidn't get this on other Distros, might be a CentOS related error, but not sure why."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7285#msg7285"},{"f":"jgarzik","d":1280859024,"b":[["q","My first obstacle is the missing ecdsa.h (Elliptic Curve Digital Signature Algorithm) file. It's listed in the man pages for CentOS, but missing from the package, WTF?\n\nAnyway, I guess I can copy it from somewhere else, hopefully I'll have some binaries for us all soon.","Quote from: knightmb on August 03, 2010, 03:58:05 PM"],["t","Yes, ecdsa.h is considered patent-encumbered, so Red Hat and other distros turn off ec-dsa.\n\nYes, Virginia, this means that bitcoin potentially has patent problems."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7289#msg7289"},{"f":"knightmb","d":1280861617,"b":[["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. Undecided","Quote from: sgtstein on August 03, 2010, 05:30:37 PM"],["t","I'm probably going to load up a virtual machine of CentOS 5.5 and work with that. I've really barfed up the server I was experimenting on trying make it build the binary, LOL."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7297#msg7297"},{"f":"satoshi","d":1280869508,"b":[["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. Undecided","Quote from: sgtstein on August 03, 2010, 05:30:37 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7331#msg7331","s":1,"n":310,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/310/"},{"f":"knightmb","d":1280873465,"b":[["t","Ok, conquered the DB issue after pestering an Oracle developer all day  Tongue\n\nWhen you compile DB 4.7.25, you have to use an extra config command or else the compile will be missing those vital header files (why???)\n\nAnyway, here is what it was"],["c","../dist/configure --enable-cxx\nmake"],["t","When you compile the source, this fixes the DB compiling related errors."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7349#msg7349"},{"f":"sgtstein","d":1280875873,"b":[["t","Ah, crap. I totally forgot about that extra flag. I knew about that before from Lazslo's Linux Build Document. Sorry about that. Get a working build up and running and you'll definitely be getting some BTC from me.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7357#msg7357"},{"f":"knightmb","d":1280877421,"b":[["t","Oh, but there's more!  Shocked\n\nEven after I did that, I couldn't get it to compile due to linking errors. I was able to get a solid compile of bitcoind though, this is the extra steps it took.\n\nAfter compiling and installing the BerkeleyDB4.7, you need to add it's include path to the makefile.unix\n\nAdd -I\"/usr/local/BerkeleyDB.4.7/include\"\n\nThen you need to copy all the libraries from \"/usr/local/BerkeleyDB.4.7/lib\" to \"/usr/lib\"\nBUT WAIT, there's MORE!  Huh\n\nYes, and if that was not annoying enough, now it will fail to compile because of an OpenSSL error, Grrrrr..\n\nNow you must copy libcrypto.a and libssl.a from \"/usr/local/ssl/lib\" to \"/usr/lib\"\n\nYes, those can be linked, but I got tired of chasing down compiler errors, was easier to just copy them.  Roll Eyes\n\nAfter all of that, then you should be able to compile a bitcoind binary.\n\nI'm testing it now, seems to be working just fine. Downloading blocks and such. When it finishes, I'll experiment with some coin generation and coin transfer.\n\nI'm still caught on the GUI client compile, currently hangs at"],["c","/usr/bin/ld: cannot find -lSM"],["t","If anyone is good with Google, let me know.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7361#msg7361"},{"f":"knightmb","d":1280879206,"b":[["t","I've posted the binary up here (32 bit only - bitcoind):\nClick Here <http://knightmb.dyndns.org/files/bitcoin/custom%20builds/x86/CentOS%205.5/>\n\nThere are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)\n\nWill probably tackle the GUI client build another day, this one wore me out. Donate some BTC to my sig if you are feeling generous  Wink"]],"u":"https://bitcointalk.org/index.php?topic=685.msg7365#msg7365"},{"f":"satoshi","d":1280880572,"b":[["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)","Quote from: knightmb on August 03, 2010, 11:46:46 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=685.msg7372#msg7372","s":1,"n":314,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/314/"}]},{"id":"p161","k":"p","s":"bitcointalk","t":"Authentication, JSON RPC and Python","u":"https://bitcointalk.org/index.php?topic=689","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/161/","m":[{"f":"vess","d":1280850589,"b":[["t","Hi all,\n\nDoes anyone have jsonrpc or something similar working with HTTP Authentication? I'm trying to hit up my bitcoin server with python over JSON-RPC, and of course, getting authorization errors from the new server.\n\nI couldn't find much about this online, surprisingly, so thought I'd ask here."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7254#msg7254"},{"f":"vess","d":1280856044,"b":[["t","Update: Here is the current state of my hackish code:\n\npostdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})\n\nreq = urllib2.Request('http://127.0.0.1:8332', postdata)\n      \n\nbase64string = base64.encodestring( '%s:%s' % ('username','rpcpassword'))[:-1]\nauthheader =  \"Basic %s .\" % base64string\nreq.add_header(\"Authorization\",authheader)\n      \nhandle = urllib2.urlopen(req)\n      \nprint handle.read()\n\nIf username or password is wrong, then I get an Authorization error from the server as expected.\n\nOtherwise, I get nothing, just a closed connection.\n\nAny leads or tips? "]],"u":"https://bitcointalk.org/index.php?topic=689.msg7271#msg7271"},{"f":"nelisky","d":1280857371,"b":[["t","Did you see http://bitcointalk.org/index.php?topic=528.msg4923#msg4923 ? That might be the problem... I had read somewhere about python urllib and bitcoing not playing along, but curl had no issues. Can't find that thread though."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7280#msg7280"},{"f":"vess","d":1280858520,"b":[["t","Thanks for the pointer, interesting, but not what seems to be affecting me.\n\nHere's my current code (running on Google App Engine)\n\npostdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})\nreq = urllib2.Request('http://127.0.0.1:8332', postdata)\nuserpass = 'user:a'.encode('base64')[:-1]\nauthheader =  \"Basic %s\" % userpass\nreq.add_header(\"Authorization\",authheader)\nhandle = urllib2.urlopen(req)\njson_response = handle.read()\nself.response.out.write (json_response)\n\nThis yields a HTTPError: HTTP Error 500: Internal Server Error\n\nfrom the GAE local python script.\n\nusing\n   postdata = jsonrpc.dumps([{\"jsonrpc\": \"2.0\",\"method\": 'getbalance', \"params\":'','id':'1'}])\n\nYields the same result."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7287#msg7287"},{"f":"jgarzik","d":1280858948,"b":[["q","Thanks for the pointer, interesting, but not what seems to be affecting me.\n\nHere's my current code (running on Google App Engine)\n\npostdata = jsonrpc.dumps({\"method\": 'getbalance', \"params\":'','id':'jsonrpc'})\nreq = urllib2.Request('http://127.0.0.1:8332', postdata)\nuserpass = 'user:a'.encode('base64')[:-1]\nauthheader =  \"Basic %s\" % userpass\nreq.add_header(\"Authorization\",authheader)\nhandle = urllib2.urlopen(req)\njson_response = handle.read()\nself.response.out.write (json_response)\n\nThis yields a HTTPError: HTTP Error 500: Internal Server Error","Quote from: vess on August 03, 2010, 06:02:00 PM"],["t","This is a verified bug in bitcoin.\n\nbitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it.  When the Content-Length header is absent, bitcoin returns 500 Internal Server Error."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7288#msg7288","sj":"Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)"},{"f":"vess","d":1280861009,"b":[["t","What you say is true, but urllib2 does send Content Length.\n\nIn my case, we had a datatypes problem which Gavin helped me find: params needs to get a list in python, so\n\n\"params\" : []\n\nwill work.\n\"params\" : \"\"\n\ndid not.\n\nWith that amendation, my second sample code works well now. Hope it's helpful to others."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7294#msg7294"},{"f":"Gavin Andresen","d":1280861804,"b":[["q","bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it.  When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.","Quote from: jgarzik on August 03, 2010, 06:09:08 PM"],["t","Can you be more specific about which JSON libraries don't provide Content-Length ?  It'd be nice to document that."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7299#msg7299","sj":"Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)"},{"f":"jgarzik","d":1280861938,"b":[["q","> Quote from: jgarzik on August 03, 2010, 06:09:08 PM\n> bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it.  When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.\nCan you be more specific about which JSON libraries don't provide Content-Length ?  It'd be nice to document that.","Quote from: gavinandresen on August 03, 2010, 06:56:44 PM"],["t","The two JSON RPC libs available at CPAN (Perl), and a compliant C lib that I wrote locally to verify the behavior."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7300#msg7300","sj":"Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)"},{"f":"aceat64","d":1280865392,"b":[["t","Another issue I noticed with bitcoind's JSON-RPC is that by default there is no user, and PHP's fopen() function does not try to send the authentication information if no user was specified.\n\nFor example, this URL does not work:"],["q","\"http://:password@127.0.0.1:8332/\"","Quote"],["t","But this one does:"],["q","\"http://username:password@127.0.0.1:8332/\"","Quote"],["t","I had to set the \"rpcuser\" in my node's bitcoin.conf file in order to get PHP to play nicely."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7312#msg7312"},{"f":"vess","d":1280867475,"b":[["t","I encountered this as well: there's no documentation as to what auth string should be accepted in the case of no user.\n\nIt's probably best to require rpcuser and rpcpassword in future versions is my two cents. This is generally what's expected from an HTTP Auth anyway."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7324#msg7324"},{"f":"satoshi","d":1280870786,"b":[["q","> Quote from: jgarzik on August 03, 2010, 06:09:08 PM\n> bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it.  When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.\nCan you be more specific about which JSON libraries don't provide Content-Length ?  It'd be nice to document that.","Quote from: gavinandresen on August 03, 2010, 06:56:44 PM"],["t","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.\n\nEdit: That is, assuming there actually are any libraries that don't support Content-Length."]],"u":"https://bitcointalk.org/index.php?topic=689.msg7335#msg7335","s":1,"n":311,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/311/","sj":"Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)"}]},{"id":"p162","k":"p","s":"bitcointalk","t":"Bitcoin Watchdog Service","u":"https://bitcointalk.org/index.php?topic=691","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/162/","m":[{"f":"MoonShadow","d":1280858031,"b":[["t","Another thread that asked what would happen if the bitcoin network were to split over a period of time and reconnect got me thinking....\n\nOne way to protect against such an unlikey event would be to have a watchdog process that kept track of the average time between blocks since the last change in difficulty, and alert the owner if the time between blocks were to jump significantly and uncharacteristicly over one or more consecutive blocks.  This would also help protect a vendor from a double-spending scam if the theives involved were talented enough to be able to spoof his client's connections to delay another spend event from reaching him.\n\nBut then I realized that a server running a modified client on another machine, without a hard connection limit, could do the above for a collection of vendors, while monitoring the vendor's client by maintaining a connection to it and notifying the vendor by other means if the connection is lost.  Also, if a war, internet virus, or other were to divide the bitcoin network for an extended time; the watchdog would be able to deterimine *where* the problem on the Internet actually is by analysis of it's customers' connections that were lost, and notify all customers in the affected zone that, presumedly, they are on the wrong side of the split.\n\nThe watchdog would also work quite well as a rapid annouce clearinghouse, improving the odds for it's customers that if they are subjects of a double-spending scam, that it's less likely that they are those left holding the raw deal.\n\nAny talented programmers willing to take this up?"]],"u":"https://bitcointalk.org/index.php?topic=691.msg7283#msg7283"},{"f":"jgarzik","d":1280859148,"b":[["t","A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary."]],"u":"https://bitcointalk.org/index.php?topic=691.msg7290#msg7290"},{"f":"nelisky","d":1280861998,"b":[["q","A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary.","Quote from: jgarzik on August 03, 2010, 06:12:28 PM"],["t","But that is only as good as the trust you have in the distribution channels, which are being discussed in other threads. If a compromised client was to be served as an upgrade, and most running clients would be using this version, then a new chain would replace the old one. What would happen when, after some time, the attack was disclosed and new clients with the real block chain signatures were run? Would the old (real) chain still be alive and replace the bogus one?"]],"u":"https://bitcointalk.org/index.php?topic=691.msg7301#msg7301"},{"f":"throughput","d":1281626923,"b":[["t","Definitively, we need some overall network hps meter in every node.\n\nAnd at last I've found that article:\nhttp://www.informit.com/articles/article.aspx?p=1237179\n\nNetwork splits are easier to produce, and happen more often, than many users on this forum think.\nYou don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.\nYou don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).\nI have one  Grin\n\nSo, it is possible to talk about a short (1 - 3 hours) and controlled network split.\nNot just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that\nreally depends on work hours. Weekend attack may have more prolonged effect.\nPerhaps in the future that will be fixed and no BGP router will be vulnerable, but\nanyway, nobody should count on Internet stability and persistent connectivity."]],"u":"https://bitcointalk.org/index.php?topic=691.msg8897#msg8897"},{"f":"jgarzik","d":1281629651,"b":[["q","> Quote from: jgarzik on August 03, 2010, 06:12:28 PM\n> A good way to prevent long-chain takeover is to store the signature of the last-known \"good\" block in each bitcoin release binary.\n\nBut that is only as good as the trust you have in the distribution channels, which are being discussed in other threads. If a compromised client was to be served as an upgrade, and most running clients would be using this version, then a new chain would replace the old one. What would happen when, after some time, the attack was disclosed and new clients with the real block chain signatures were run? Would the old (real) chain still be alive and replace the bogus one?","Quote from: nelisky on August 03, 2010, 06:59:58 PM"],["t","We could convince satoshi to always post SHA1 signatures of uploads inside a PGP-signed blocks...  establish a chain of trust for both source code and official binaries."]],"u":"https://bitcointalk.org/index.php?topic=691.msg8902#msg8902"},{"f":"aceat64","d":1281632563,"b":[["q","Definitively, we need some overall network hps meter in every node.\n\nAnd at last I've found that article:\nhttp://www.informit.com/articles/article.aspx?p=1237179\n\nNetwork splits are easier to produce, and happen more often, than many users on this forum think.\nYou don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.\nYou don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).\nI have one  Grin\n\nSo, it is possible to talk about a short (1 - 3 hours) and controlled network split.\nNot just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that\nreally depends on work hours. Weekend attack may have more prolonged effect.\nPerhaps in the future that will be fixed and no BGP router will be vulnerable, but\nanyway, nobody should count on Internet stability and persistent connectivity.","Quote from: throughput on August 12, 2010, 03:28:43 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=691.msg8906#msg8906"},{"f":"satoshi","d":1281648884,"b":[["t","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.\n\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.\n\nI favour the plan to monitor if the frequency of blocks received drops too slow.  That covers a large range of possibilities."]],"u":"https://bitcointalk.org/index.php?topic=691.msg8922#msg8922","s":1,"n":350,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/350/"},{"f":"throughput","d":1281681950,"b":[["q","> Quote from: throughput on August 12, 2010, 03:28:43 PM\n> Definitively, we need some overall network hps meter in every node.\n>\n> And at last I've found that article:\n> http://www.informit.com/articles/article.aspx?p=1237179\n>\n> Network splits are easier to produce, and happen more often, than many users on this forum think.\n> You don't really need to cut any cable, nor hack into ISP's router to plug that ISP off Internet.\n> You don't need to hack his peers either. All you need is BGP router in any AS (and some unwary BGP peers).\n> I have one  Grin\n>\n> So, it is possible to talk about a short (1 - 3 hours) and controlled network split.\n> Not just split in half, but split into ASes. After an hour or three-four most of ISPs will recover, but that\n> really depends on work hours. Weekend attack may have more prolonged effect.\n> Perhaps in the future that will be fixed and no BGP router will be vulnerable, but\n> anyway, nobody should count on Internet stability and persistent connectivity.\nHow 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.","Quote from: aceat64 on August 12, 2010, 05:02:43 PM"],["t","1. Why an attacker is forced to be a single person with a single PC?\nCopy the wallet on another PC and use it anywhere!\n\n2. Why should network isolation only be used for double spending?\nCan't it be used to slow down block generation? Will that affect difficulty adjustment?"],["q","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.","Quote from: satoshi on August 12, 2010, 09:34:44 PM"],["t","But there will be no irc server to bootsrap from."]],"u":"https://bitcointalk.org/index.php?topic=691.msg8978#msg8978"},{"f":"satoshi","d":1281719367,"b":[["q","But there will be no irc server to bootstrap from.","Quote"],["t","Which doesn't matter because you can't access sourceforge to download the software either.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=691.msg9041#msg9041","s":1,"n":354,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/354/"}]},{"id":"p163","k":"p","s":"bitcointalk","t":"Please upgrade to 0.3.8!","u":"https://bitcointalk.org/index.php?topic=696","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/163/","m":[{"f":"satoshi","d":1280878818,"b":[["t","Version 0.3.8 adds an important security improvement.  Everyone should upgrade to get this change.\n\nThe new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.\n\nIf it sees a longer chain, but it can't process it, then it knows something is wrong.  It displays \"WARNING: Displayed transactions may not be correct!  You may need to upgrade.\" and makes most RPC commands return an error.  It still keeps generating as normal, which is necessary for the stability of the network.\n\nThere were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!\n\nAlso, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/"]],"u":"https://bitcointalk.org/index.php?topic=696.msg7364#msg7364","s":1,"n":313,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/313/"},{"f":"FreeMoney","d":1280880485,"b":[["t","Link takes me to 3.7"]],"u":"https://bitcointalk.org/index.php?topic=696.msg7371#msg7371"},{"f":"satoshi","d":1280881777,"b":[["t","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.\n\nEdit: SourceForge is updated now."]],"u":"https://bitcointalk.org/index.php?topic=696.msg7381#msg7381","s":1,"n":315,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/315/"}]},{"id":"p164","k":"p","s":"bitcointalk","t":"Who's the Spanish jerk draining the Faucet?","u":"https://bitcointalk.org/index.php?topic=704","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/164/","m":[{"f":"Gavin Andresen","d":1280954455,"b":[["t","I just shut down freebitcoins.appspot.com; it looks like somebody in Spain is being a jerk and getting a new IP address, bitcoin address, and solving the captcha.  Over and over and over again:"],["c","79.154.133.217 - - [04/Aug/2010:12:46:55 -0700]\n\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"\n\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\"\n\n79.146.112.13 - - [04/Aug/2010:12:45:20 -0700]\n\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"\n\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\"\n\n81.44.159.81 - - [04/Aug/2010:12:42:20 -0700]\n\"POST / HTTP/1.1\" 200 1294 \"https://freebitcoins.appspot.com/\"\n\"Opera/9.80 (Windows NT 6.0; U; es-LA) Presto/2.6.30 Version/10.60,gzip(gfe)\" "],["t","Those IP addresses all map to Telefonica de Espana.  If it was you:  give them back, please: 15VjRaDX9zpbA8LVnbrCAFzrVzN7ixHNsC\n\nNow that 5 bitcoins is worth a fair bit, I'm thinking I need more cheating countermeasures.  I can think of four things to try:\n\n1. Rate limit based on the first byte of the IP address (79. or 81. in this case).\n2. Rate limit based on the USER-AGENT string (\"Opera/9.8...\" in this case).\n3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).\n4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).\n\nIf you get rate limited, you'll get a message that asks you to try again tomorrow.\n\nBitcoinFX: thanks again for the donation to the faucet; I'm going to drain the Faucet below 500 coins temporarily, and will refill it with your donation after the new cheating countermeasures are in place."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7575#msg7575"},{"f":"knightmb","d":1280955674,"b":[["t","This has been going on for a while I would say. I noticed that when I would donate BTC to it, I would check the site a few minutes later and it would be back down below 500 again very quickly (but not further down since it appears to stop after it reaches below 500)\n\nI'm afraid with how the nature of Bitcoin works, even if you narrow it down to IP address, Bitcoin Address, cookies, browser string, etc. someone can still fake/change all of those to drain it.\n\nI think your recommendation of 0.50 with it being reduced to the 0.05 when it hits below 500 BTC would work better to deter this kind of thing. Also, a rate per hour limit (because someone with a botnet could have all of them descend on it and empty it even at 0.05 a piece just for kicks)\n\nIt's obvious from your logs, the guy/gal was just renewing his IP address, generate a new bitcoin address, refresh the page, copy/paste new bitcoin address, send 5 BTC; rinse and repeat."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7576#msg7576"},{"f":"omegadraconis","d":1280957146,"b":[["t","You know the same thing crossed my mind that you could drain the faucet by grabbing a new ip address. I figured most of the people would be honest enough to not do it or there was something behind the scenes preventing it. One idea might be Browser finger print and a 81.x.x.x or 71.x.x.x limit. http://panopticlick.eff.org was something the eff did to show just how easy it is to finger print your browser (it checks your os build, Browser build, java, flash, other add-on versions, etc). If you were to combo detect the the browser id's and the first ip block it would be a fairly good way, though it would probably be a fair bit of work.\n\nAnother idea would be to add a delay to the coins being sent out, like say an hour after they are cleared the coin goes out. This wouldn't give someone instant satisfaction and would allow you to prevent the coins going out during that hour (Add a check to email yourself if a large number of transactions come through or something like that). Also dropping the coins being given out to 1 or 0.5 would significantly decrease the incentive of doing such a thing."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7577#msg7577"},{"f":"knightmb","d":1280958861,"b":[["t","That's a really good idea, just make a queue system with a simple \"click to approve\" button.\n\nI don't know how much traffic the faucet site gets though, might not be practical from a human standpoint, but I don't often see the faucet that far below 500 most of the time."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7580#msg7580"},{"f":"NewLibertyStandard","d":1280960591,"b":[["t","I would make it give out 0.001% of the total bitcoins with a minimum of ฿0.02 and I would move those two decimal points to the left whenever the official client changes to displays another precision point. Thanks for the service, it's very useful to new users. I hope you can stay one step ahead of the cheaters."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7584#msg7584"},{"f":"mizerydearia","d":1280966202,"b":[["q","Also dropping the coins being given out to 1 or 0.5 would significantly decrease the incentive of doing such a thing.","Quote from: omegadraconis on August 04, 2010, 09:25:46 PM"],["t","The incentive will always exist.  It just makes it harder/take longer, more effort and creativity involved."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7589#msg7589"},{"f":"skull88","d":1280968150,"b":[["t","What if they just use different proxy's, than the checking the first byte of the IP is useless.\n\nYou could make a registration form on the site where they first got to activate they're email address, and than get a login code.\nAfter login than they can request the free coins, of course there is a limit of one request for one email address and you keep on checking the ip.\n\nSo if you want a lot of coins, you first got to register a lot of email adresses and than you got to register with all those addresses, you really got to have no life to do all that trouble just to drain down the Faucet Smiley"]],"u":"https://bitcointalk.org/index.php?topic=704.msg7597#msg7597"},{"f":"FreeMoney","d":1280968870,"b":[["t","This is a nice exercise in what happens when you give free stuff away.\n\nHint: People try to get the free stuff.\n\nI do think it's a nice idea, I'm not saying you shouldn't do it."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7601#msg7601"},{"f":"Anonymous","d":1280971976,"b":[["t","Whoever cheats to take free bitcoins wins this award.\n\nIt is the douche-bag of the year."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7612#msg7612"},{"f":"Gavin Andresen","d":1280974014,"b":[["t","Thanks for all the ideas!\n\nFirst: I'm definitely going to drop from 5 BTC; I think I'll go all the way down to 0.50 BTC (rather than do 1 or 2).  Giving away a percentage of how much the faucet has is an interesting idea, but I want it to be as simple as possible.\n\nSecond: I really don't want to make getting coins from the Faucet a whole heavy-weight \"register and check your email and yada yada yada.\"\n\nBut I do like the idea of adding an extra hurdle for 'suspicious-looking' behavior.  So I'm leaning towards doing some fuzzy browser fingerprinting combined with rate-limiting and, if you look suspicious or the fountain has been giving away a larger-than-usual number of coins, require that you login with your google account before getting any coins.  No google account: no coins.\n\nIt is hard to create lots of google accounts; they're requiring either phone or SMS account verification these days..."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7616#msg7616"},{"f":"Gavin Andresen","d":1280974294,"b":[["q","This is a nice exercise in what happens when you give free stuff away.\nHint: People try to get the free stuff.\nI do think it's a nice idea, I'm not saying you shouldn't do it.","Quote from: FreeMoney on August 05, 2010, 12:41:10 AM"],["t","Yeah, I shoulda anticipated problems when Bitcoins went from 0.005 USD each to 0.06 each.  If it takes somebody two minutes to go through the \"get a new IP, get a new BC address, solve the captcha\" process then they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which, if you're unemployed, bored, and/or 13 years old is easy money."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7617#msg7617"},{"f":"kiba","d":1280977692,"b":[["q","> Quote from: FreeMoney on August 05, 2010, 12:41:10 AM\n> This is a nice exercise in what happens when you give free stuff away.\n> Hint: People try to get the free stuff.\n> I do think it's a nice idea, I'm not saying you shouldn't do it.\nYeah, I shoulda anticipated problems when Bitcoins went from 0.005 USD each to 0.06 each.  If it takes somebody two minutes to go through the \"get a new IP, get a new BC address, solve the captcha\" process then they'd make 5*30=150 bitcoins an hour, which is $9 USD an hour, which, if you're unemployed, bored, and/or 13 years old is easy money.","Quote from: gavinandresen on August 05, 2010, 02:11:34 AM"],["t","Hmm, now that I think about it....13 years old would find bitcoins to be a money making opportunities, especially since they generally can't be employed by business and such. They can however, offer services and goods of some kind to bitcoiners in exchange for some money. When he/she saved up a bit, she/he can buy hosting services and bootstrap their way to bigger business operations."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7624#msg7624"},{"f":"Ground Loop","d":1280982659,"b":[["t","Sadly, I don't think there's a viable anti-abuse system when you have an automated system dispensing coins for free.  (anonymous, irrevocable coins)\n\nThe only countermeasure that makes sense is to slow down the value and pace of the whole faucet to where someone has a chance to manually keep an eye on flow.\n\nBut coming back to the roots of why it's neat, and what people reasonably get from it, the specific value is not really important.  I see it as more a \"system test\", where someone can watch coins come in, transfer them to another computer, and so on.  It's not supposed to be \"what can I buy with these\", but test coins.  Having 0.02 coins is much more fun than having zero.\n\nTo that end, a system that dispenses BTC 0.02 and has a significant delay (30 mins?) is less likely to be attractive to even automated abuse plots."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7631#msg7631"},{"f":"BioMike","d":1280988745,"b":[["t","I've tried it last week and got 0.05BC, which is fine for its purpose (testing how it works and if it works). I also send the same amount back. I think it works just fine like this. I wouldn't have tried it when I had to get a google account, or something similar (getting such thing for only 0.05BC is just to much effort for testing it)."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7638#msg7638"},{"f":"gebler","d":1281007837,"b":[["t","Perhaps it would help to be more clear about the Faucet operating on an honor principle, and that no one is really allowed more than 5.05 bitcoins (or 0.55 bitcoins if you change it to that).  When I revisit the site today it says \"Right now the rule is 0.05 bitcoins given per unique IP address.\"  Such language could be interpreted as if it was actually OK to get more payouts from the Faucet using several unique IP addresses, since it would not be \"against the rules\".  Improving the technical system to prevent cheating is probably a good idea anyway, since there are probably cheaters who don't care about being cheaters.  But some may actually think they are just being clever, maximizing their benefit without breaking any rules."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7660#msg7660"},{"f":"tcatm","d":1281017391,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7670#msg7670"},{"f":"satoshi","d":1281027963,"b":[["t","Silently failing would look bad."],["q","1. Rate limit based on the first byte of the IP address (79. or 81. in this case).","Quote from: gavinandresen on August 04, 2010, 08:40:55 PM"],["t","Definitely needed.  What rate are you thinking of?  Ultimately, it's better to rate limit it than to let it all drain out."],["q","3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).","Quote from: gavinandresen on August 04, 2010, 08:40:55 PM"],["t","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."],["q","4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).","Quote from: gavinandresen on August 04, 2010, 08:40:55 PM"],["t","Definitely time to lower it."]],"u":"https://bitcointalk.org/index.php?topic=704.msg7703#msg7703","s":1,"n":321,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/321/"}]},{"id":"p165","k":"p","s":"bitcointalk","t":"bitcoind transaction to ip address","u":"https://bitcointalk.org/index.php?topic=711","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/165/","m":[{"f":"lfm","d":1281018134,"b":[["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=711.msg7671#msg7671"},{"f":"satoshi","d":1281029320,"b":[["t","It's not implemented.\n\nIt turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention."]],"u":"https://bitcointalk.org/index.php?topic=711.msg7705#msg7705","s":1,"n":322,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/322/"}]},{"id":"p166","k":"p","s":"bitcointalk","t":"Transaction Overload Solution","u":"https://bitcointalk.org/index.php?topic=713","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/166/","m":[{"f":"bytemaster","d":1281024307,"b":[["t","In another thread I posted the comment below, but I felt that it was an important enough flaw that it should be addressed asap before bitcoin is overrun with huge numbers of automated non-micro payments.\n\nThe real issue is that even a simple legitimate automated payment negotiation 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.\n\nIn my use case you have a P2P system where they pay *anonymous users* for priority downloads.   Assume you have a single \"torrent\" file with 100,000 people all seeding and downloading.  That could easily generate 100,000 payments greater than 0.01 per minute.  Now clearly, the program would only have to use BTC in the event that upload != download between two clients.  But you never know what kind of crazy ideas people will eventually come up with.\n\nSuch a system 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.\n\nI suspect that the \"cost\" of handing individual transactions may be low (.00001 BTC) but the cost of handling ALL of those transactions from millions of users using automated payment negotiation/bidding systems would quickly make it impossible to even listen for all incoming transactions.  \n\nThe only solution to this problem is to make broadcasting of a transaction \"non free\".  Namely, if you want me to even *attempt* to include it you have to pay me whether or not I succeed in getting it in first.  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.\n\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.   You are protected against people taking your payment and then not even attempting to integrate it because they must find away to get your payment to them integrated or they don't even get paid and it would cost more for them to \"forward\" the generation transaction fee to another node than they could get by having the transaction go through.  \n\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.  \n\nThe \"winner take all\" transaction fee requires that I incur the cost for receiving and attempting to integrate transactions yet I would only get paid 1 time every couple of weeks if I was lucky and *if* my internet connection could handle receiving every transaction that occurred.  \n\nPeople should pay others to generate whether or not the generation was the first one to integrate your transaction into a block.    What are the technical challenges to implementing this. "]],"u":"https://bitcointalk.org/index.php?topic=713.msg7688#msg7688"},{"f":"bytemaster","d":1281024840,"b":[["t","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. \n\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.   "]],"u":"https://bitcointalk.org/index.php?topic=713.msg7690#msg7690"},{"f":"satoshi","d":1281029901,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=713.msg7706#msg7706","s":1,"n":323,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/323/"}]},{"id":"p167","k":"p","s":"bitcointalk","t":"Bitcoin minting is thermodynamically perverse","u":"https://bitcointalk.org/index.php?topic=721","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/167/","m":[{"f":"gridecon","d":1281059520,"b":[["t","Let me begin by saying that Bitcoin is an amazing project and I am very impressed with the implementation and the goals. From reading these forums it seems to be understood that debate about the design and operation of the bitcoin economy ultimately serves to strengthen it, so I hope these comments are taken in that spirit. *EDIT - I have been convinced by further research and discussion that Bitcoin is actually highly efficient compared to most traditional currencies, because the infrastructure required to support a government issued fiat currency represents a much larger investment of resources than Bitcoin's cpu power consumption. I am leaving this thread active though because it has been generating a lot of interesting discussion.*\n\nI believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.\n\nOne argument is that anyone who chooses to generate coins is actually making the choice to purchase bitcoins with electricity/computational resources, and that because some/many people are in fact making that choice, bitcoins have at least that much \"value\" to the generators, who can be assumed to be maximizing their utility. A contrasting argument is that cost of production is different than market value, and the most objective measure is the current market conversion price to a more liquid and widely traded currency such as the US dollar.\n\nMy contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.\n\nAs is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value. *Edit - as mentioned above, I am now much more optimistic about Bitcoin long term. I still think compucoins would be a cool idea, though!*"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7771#msg7771"},{"f":"knightmb","d":1281061610,"b":[["q","I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.\n\nOne argument is that anyone who chooses to generate coins is actually making the choice to purchase bitcoins with electricity/computational resources, and that because some/many people are in fact making that choice, bitcoins have at least that much \"value\" to the generators, who can be assumed to be maximizing their utility. A contrasting argument is that cost of production is different than market value, and the most objective measure is the current market conversion price to a more liquid and widely traded currency such as the US dollar.","Quote from: gridecon on August 06, 2010, 01:52:00 AM"],["t","My only counter is that it will seem that way to a first time user, because they have no bitcoins at all. But there are a possible 3.6 million bitcoins out there plus a member here runs a site that gives away free bitcoins so people can experiment with the system. The amount of actually energy, if you break it down, is only that of the PC itself. When you consider how few watts a processor runs to get a block where each 50 BTC block is worth about $3 USD, that's much more than the electricity cost it took to create it. Right now, you can generate BitCoins and sell them for more than it cost the electricity to run the PC to do it unless your electrical rates are the highest in the world. The only reason no one does is the scale of economics that would be required to make it profitable."],["q","My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.","Quote"],["t","The same can be said about gene folding or SETI since a ton of CPU time and electricity often does not reward the individual user of the their client software. It's the collection as a whole that rewards everyone in non-monetary ways (find cure for cancer, find aliens, etc.)"],["q","As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value.","Quote"],["t","Unless electrical rates go up higher than the value of BTC, there will always be people willing to trade out CPU resources for it. Currently, cheap VPS farming has a return on BTC generation, though not very much. The other benefit is that the generation rate tries to remain constant, so it's not always going be hard to generate BTC if less and less people decide to do it, the difficulty goes back down."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7772#msg7772"},{"f":"gridecon","d":1281063612,"b":[["t","Thanks very much for the extensive and informative reply. I do not disagree with the points that you made, but I also don't believe it invalidates my fundamental point: it is not inherently necessary for a digital currency such as bitcoin to require as much energy input as bitcoin does. A digital currency that offers bitcoin's behavior at a \"lower cost\" of energy overhead of the currency and transaction system has a competitive advantage. The digital currencies that will win and become standards, I believe, are the ones that offer the most value-added on top of the costs of running the system. Of course, there is room for many currencies - we already have a multiplicity - so it is not necessary for Bitcoin to become the \"one true money\" for it to succeed, but I believe the current minting policies will be harmful to its growth and adoption long-term. Much of the utility value of bitcoin resides in the work done to establish the security and reliability of the system - accomplishing that work with a smaller energy input would seem to be beneficial."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7775#msg7775"},{"f":"knightmb","d":1281065445,"b":[["q","Thanks very much for the extensive and informative reply. I do not disagree with the points that you made, but I also don't believe it invalidates my fundamental point: it is not inherently necessary for a digital currency such as bitcoin to require as much energy input as bitcoin does. A digital currency that offers bitcoin's behavior at a \"lower cost\" of energy overhead of the currency and transaction system has a competitive advantage. The digital currencies that will win and become standards, I believe, are the ones that offer the most value-added on top of the costs of running the system. Of course, there is room for many currencies - we already have a multiplicity - so it is not necessary for Bitcoin to become the \"one true money\" for it to succeed, but I believe the current minting policies will be harmful to its growth and adoption long-term. Much of the utility value of bitcoin resides in the work done to establish the security and reliability of the system - accomplishing that work with a smaller energy input would seem to be beneficial.","Quote from: gridecon on August 06, 2010, 03:00:12 AM"],["t","I think though you are comparing apples to oranges. The coin generation is for currency creation. You don't need to generate any coin to use the bitcoin system. You can purchase it from many market sites or get some donated for free from other sites. The current minting policy is what makes it useful because a digital currency where everyone has unlimited amounts (or large starting amounts) just causes unnecessary starting inflation. The overhead for the currency is by design, otherwise if someone creates an *easier* system, it will be quickly abused. Since you can't make everyone play fair, you create something where it's nearly impossible to cheat by using math. To make cheating expensive instead of \"easy\" is where this system works. If it's more profitable to generate coin than to cheat it, guess which one everyone will go with?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7777#msg7777"},{"f":"Red","d":1281066610,"b":[["t","Nicely written gridecon. I completely agree.\n\nI've been considering posting a similar critique but you've laid the issue out clearly. if you don't mind I'll add my thoughts here.\n\nAs the minting process and the transaction recording process are one, there is really no reason to separate them. I don't disagree with knightmb's points at all. But I do think that is is really important to point out that all that CPU power and electricity usage is absolutely NOT required for the task at hand.\n\nGenerating blocks serves three critical but independent functions in the bitcoin system.\n\n1. It permanently records valid transactions in a roughly chronological order.\n2. It creates *consensus* among all nodes on what transactions took place and when, WITHOUT relying on a central authority. That was a hugely clever breakthrough.\n3. It trickles bitcoins into circulation at a regularly scheduled rate. (roughtly 50 BTC/10 min) Also a nice motivational trick.\n\nHowever, all of these required tasks could be done in a much more efficient manner.\n\nGenerally in a P2P system, if you add more nodes then the necessary machine resources needed per node decrease. (for a given usage level of the service)\nHowever, if we add more nodes to the bitcoin network the necessary machine resources needed per node increase. This is true of CPU usage and network bandwidth.\n\nSatoshi already pointed out that the goal of this is not to scale to millions of pure P2P nodes. But instead to have thousands of transaction checking peers each having thousands of clients. That means the goal is to create core \"central authority\" of peer nodes each of which is trusted by some clients, but the core peers do not necessarily need to trust each other. This is a absolutely critical design construct if the current implementation of bitcoin is expected to scale to millions of traders.\n\nHowever, there are other design possibilities that could meet each of these three critical goals without exponential growth in resources utilization.\n\nImplementing the transaction graph using a redundant distributed hash table comes to mind. This could be done with or without a core of central peers. Another possibility would be just to store the transaction graph in a SQL database and use database replication among the core peers. Either of those satisfies goal 1 and 2 using minimal system resources.\n\nGoal 3 is implementable by simply generating a distributed shared secret, then using that shared secret as a concensus random node to send 50 BTC to.\n\nI agree with gridecon that such an implementation would out compete the current implementation. Even if it otherwise following exactly the same external behavior and transaction validation rules."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7781#msg7781"},{"f":"gridecon","d":1281066804,"b":[["t","I understand that bitcoin's utility as a currency is independent of the method of minting - that is crucial to what I'm trying to express. My claim is that the positive properties of bitcoin's security could be implemented using a different method of minting, and that users will likely gravitate to currencies with whatever they believe are the most fair and efficient minting systems.\n\nMaybe an even simpler way to put it is that I think that it is a huge waste of resources to generate a digital currency by doing fundamentally useless computational work. If you want to regulate currency production in this way, it should be done \"parasitically\" on top of useful computation, such as that done by distributed computing research projects.\n\nLet me make an analogy that I believe is actually very close to the current truth of the matter. The current method of coin minting is similar to a currency based on photographs of burned wheat. People grow wheat, burn it, and take photos of the burned wheat to prove that it was really grown and burnt, and then use the photographs as a medium of exchange. Does that sound sensible? No, and fundamentally it is just as senseless to waste potentially useful computer cycles on calculating the hash of random data until you hit the winning number. "]],"u":"https://bitcointalk.org/index.php?topic=721.msg7783#msg7783"},{"f":"MoonShadow","d":1281070267,"b":[["q","I understand that bitcoin's utility as a currency is independent of the method of minting - that is crucial to what I'm trying to express. My claim is that the positive properties of bitcoin's security could be implemented using a different method of minting, and that users will likely gravitate to currencies with whatever they believe are the most fair and efficient minting systems.","Quote from: gridecon on August 06, 2010, 03:53:24 AM"],["t","Go for it.  In the meantime, I think that you both miss some fundamental truths.\n\n1)  The point of the system is not to 'mint' coins at a high energy cost, but a high computational cost, to protect the system no matter how high Moore's law may go. \n\n2)  The award of bitcoins is not 'minting' really anyway, it is an award by lottery for participating in the strenghtening the currency.  Those 50 bitcoins already existed from the moment that the rules were conceived and the process set into motion.  They are just distrubuted from the original owner in a systematic manner.\n\n The computations are a neccessary part of keeping the system strong and confidence high, and are a small price to pay when compared to the costs that we all incur from the administration of fiat currencies.  I think that it was a brilliant idea."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7790#msg7790"},{"f":"Insti","d":1281083423,"b":[["q","I believe that the amount of energy input required to the bitcoin economy represents a serious obstacle to its growth. I think in the long-term, transactions may be even more serious than minting in this regard, but I will for the moment discuss minting because it is more precisely bounded and defined. The idea that the value of bitcoins is in some way related to the value of the electricity required, on average, to mint a winning block is generally accepted, but the precise nature of this relationship is contentious.","Quote from: gridecon on August 06, 2010, 01:52:00 AM"],["t","I don't accept that.\nThe idea that the value of a Bitcoin is in some way related to the value of the electricity required on average is a fallacy that has been widely spread by armchair economists to get-rich-quick merchants who don't understand the system."],["q","My contention is that both of these arguments miss the point and the real problem, which is the fundamental perversity of wasting large amounts of energy and computations in generating the winning blocks for the minting process. The minting process exists because of the necessity of actually \"printing\" the currency, and certain desirable properties of crypto-math for making the currency's behavior predictable. The fact that the current minting process requires a large energy input of computational work is highly unfortunate and has the perverse consequence that bitcoin may actually be \"destroying wealth\" in the sense of wasting energy producing a digital object worth less than the resources invested in it.","Quote"],["t","It's not about the minting at all.\n\nThe computation required is to maintain the integrity of the system by growing the block chain which serves as a 'timestamp' of transactions.\nIt is probably possible to make the computation required for this process less than it currently is, but it would be at the expense of disk space or bandwidth or integrity or processing power required to validate transactions, or all of the above. The current system provides a good balance of all these things.\n\nThe minting is just a side effect, and an elegant way to reward those who have contributed processing power to the integrity of the system.\nThere are many other threads that try to propose 'better' ways of rewarding these contributions, but the 'winner takes all' system is the one we have at the moment."],["q","As is often pointed out, a currency does not necessarily have, or need to have, any inherent value - a medium of exchange is a useful tool and can have value purely as a consequence of social convention. The cost of production of bitcoins in electricity consumed represents a waste, a \"thermodynamic burden\" that the currency has to carry. Consider a hypothetical alternative digital currency called \"compucoin\", which purchases cpu cycles from nodes on the network. The market value of this currency would converge very closely with the cost of electricity required to generate cpu cycles. Instead of costing cpu cycles to mint, the value of the cpu cycles the coins could be exchanged for would create a rational basis for the currency's value and integrate it with an existing market. I imagine that alternatives to Bitcoin (many of them probably sharing a lot of Bitcoin's source code) will inevitably emerge and Bitcoin's current minting process makes the currency \"expensive\" in terms of energy input. I believe this places it at a competitive disadvantage to other currencies and can only hinder its widespread adoption and long-term value.","Quote"],["t","Good luck with implementing compucoins..\n\nAgain, it is not about the minting"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7809#msg7809"},{"f":"gridecon","d":1281086687,"b":[["t","I understand the bitcoin is not INTENDED to be about the minting. The essence of my criticism is that a digital currency SHOULD NOT be \"about the minting\" but the current bitcoin system works against that goal! My argument is that the current minting system limits the utility of the currency largely because entirely too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive. If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7817#msg7817"},{"f":"pyrrhos","d":1281087463,"b":[["t","The minting should be seen as digging for gold in a gold mine. This is similarly wasting energy and resources for actually not doing anyone any favor since you increase the supply of gold. Except for yourself of course, and that why people will always will dig for gold as long as the price of gold dug will be higher than the cost of resources needed to dig. However, this difficulty is what gives scarcity and therefore value to gold.\n\nSimilarly, if and when bitcoin becomes more mainstream and follows economic sense (rather than beeing driven by curiosity, fun and excitement for participating in something new) the cost of electricity (in dollars or equivalent bitcoins) to create a bitcoin will never exceed the value of the created bitcoin. If that would happen, many will shut down their bitcoin generation for it would make no economic sense (I already stopped mine!). Luckily, and unlike gold mining, this behavior will adjust the cost of creating bitcoin to a sensible level (below the value of the generated bitcoin)\n\nIn the long run i expect that bitcoin minting will indeed be left to the supernodes which will probably have specialized hardware  that are excellent in hash calculations and can do that way better than anyone with a general purpose pc. Similarly to specialized gold digging machines.\n\nSo although you are right that it would be nice to find a system that provides scarcity without cost (I dont know whether this is possible, it seems not), the costs are certainly connected and less to the value of the created bitcoin. And it is a self regulated system that will increase the cost of creation only if the use of bitcoin actually adds value (in the form of ease of use, anonimity etc.) and therefore is worth it.\nThe cost of creation is therefore is no limitation of the growth but more and indication of the added value of the use of bitcoin.\n\nfuuny note: Following this logic the cost of minting will be somewhat less than 21million bitcoins which with the current prize of bitcoin is  around 1 million dollars.\n\n------\n1neNcqV4yRUNwP9xCdcgRvBrNwWdFo3Wv"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7819#msg7819"},{"f":"gridecon","d":1281088816,"b":[["t","Thanks to everyone for all the well-considered responses. I am, you could say, half-convinced - I understand the motivations for the design decisions bitcoin has made, but I still think more optimal solutions are likely to evolve. That said, the obvious intelligence and open-mindedness shown by the discussion here is in some ways the most convincing selling point! Any currency with a user community who engages in quality dialogue earns additional credibility with me, so based on the quality of this thread, I have acquired a few bitcoins, and distributed some of them to the posters who included a bitcoin address. As I hope I have emphasized, I think bitcoin is brilliant and I want it to succeed, I raise these issues because I would hate to see the success of bitcoin impeded by something, the minting model, that everyone agrees is in many ways arbitrary."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7825#msg7825"},{"f":"Insti","d":1281091589,"b":[["t","If the problem you are identifying is that too much attention is"],["q","too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive.","Quote"],["t","I would tend to agree with you on the first part, but disagree on the second.\nChosing the 'winners' is a side-effect of the security of the system, if we were to choose the winners just based on picking a random address out of the transaction list this would certainly be less resource intensive, but you still need to make sure that the that the blocks cannot be easily forged by an attacker.\n\nPerhaps you could contribute your ideas on how bitcoin should be publicized.\nWe (the bitcoin community) don't have a large corporate PR department who are paid to sit around and come up with good ideas.\nBitcoin video bounty thread <http://bitcointalk.org/index.php?topic=697.0> might be a good place to start.\n\nAnother problem is that there is no one controlling focus group to set the direction of Bitcoin publicity and there are people who want to use bitcoins for all kinds of different reasons.\n\nP.S. Thanks for the tip."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7828#msg7828"},{"f":"knightmb","d":1281091911,"b":[["q","I understand the bitcoin is not INTENDED to be about the minting. The essence of my criticism is that a digital currency SHOULD NOT be \"about the minting\" but the current bitcoin system works against that goal! My argument is that the current minting system limits the utility of the currency largely because entirely too much attention is focused on \"winning the block generation lottery\" and the process of choosing these winners is highly inefficient and resource intensive.","Quote from: gridecon on August 06, 2010, 09:24:47 AM"],["t","I think that's the issue you have though, you think it's inefficient and resource intensive on purpose when really it's not. No one is required to generate coins to use the system. If you click the generate coin list, you are basically volunteering your resources to strengthen the network and in exchange, you *might* get some coin for it. Since coin is in demand to use the system, someone has to generate it. If generation was as easy as \"input how many you want, *bam*, you have 1 million now\" it would make the entire system pointless. It's a chicken and the egg puzzle except there really isn't a puzzle here. People need bitcoins, they generate them at a fixed rate to make it worth spending the CPU time."],["q","If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.","Quote"],["t","There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.\n\nI have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7829#msg7829"},{"f":"gridecon","d":1281113280,"b":[["q","> Quote from: gridecon on August 06, 2010, 09:24:47 AM\n> If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.\nThere's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.\n\nI have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.","Quote from: knightmb on August 06, 2010, 10:51:51 AM"],["t","I think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.\n\nIn making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.\n\nAgain, an analysis of the behavior of self-interested actors is instructive. The most energy-efficient scenario for bitcoin generation in the current regime would be if there was ONE NETBOOK that generated all the coins - the rate of coin production is fixed, so you'd still have the same amount of coins entering circulation. The person who ran that netbook would obviously be in a position to charge a high \"rent\" from the population that needed bitcoins for their transactions. An examination of this limit case makes it clear that bitcoin minters have a strong incentive to encourage use and circulation of the currency while discouraging additional minting nodes from coming online. This is not any kind of criticism of anyone's ethics - it is simply an examination of how the game is set up, and what strategies players will adopt.\n\nAs 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. "]],"u":"https://bitcointalk.org/index.php?topic=721.msg7889#msg7889"},{"f":"kiba","d":1281113532,"b":[["q","> Quote from: knightmb on August 06, 2010, 10:51:51 AM\n> > Quote from: gridecon on August 06, 2010, 09:24:47 AM\n> > If potential users of the currency believe that bitcoin is simply a way for botnet herders to convert spare cpu cycles into cash, they are unlikely to participate in the emergence of the economy. The current system could easily result in the perception that bitcoin is basically being used as a vector for the indirect monetization of the theft of electricity via compromised computer systems. I assume most people interested in bitcoin understand that self-interested individuals will obviously seek to exploit opportunities like this, and the design of a popular currency has to prioritize how a prospective user will evaluate its fairness.\n> There's no reason to think of it that way, anymore than the local barber is collecting hair to clone an army of super-men for world domination. You have to draw the line somewhere. If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense.\n>\n> I have seen the topic come up here a few times \"what if someone seeks to exploit this?\" and the answer is the same over and over, it has been designed from the ground up to counter this exact concern. If you want to \"game\" the system, you need a lot of CPU power. CPU power cost money. The system scales itself to the available CPU power it has so if you bought 10,000 EC2 sessions from Amazon and started a massive bitcoin generating farm, you would never make more money out of it than what you put into it for long because the system would self-adjust against it. If someone throughs a massive botnet at it, the same thing will happen. The system is set for self-feedback, so to try to steal from everyone is to try to steal from yourself at the same time.\nI think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.\n\nIn making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.","Quote from: gridecon on August 06, 2010, 04:48:00 PM"],["t","The computational and energy cost for generating bitcoins is quite irrelevant to the bitcoin economy since it does not compromise the integrity of bitcoins. People should be more concerned about a botnet trying to cheat rather than mine bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7890#msg7890"},{"f":"Red","d":1281113722,"b":[["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.","Quote from: gridecon on August 06, 2010, 04:48:00 PM"],["t","Hear hear!\n\nI though I tried to explain the lack of necessity, but people seem distracted by their repetition of mantras."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7891#msg7891"},{"f":"Insti","d":1281114928,"b":[["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.","Quote from: gridecon on August 06, 2010, 04:48:00 PM"],["t","You seem to have things backwards.\nThe \"dice rolling\" is to maintain the \"chain of proof\".\nActually giving out the coins is a side effect.\n\nI have 2 questions for you:\n\nWithout high computational burden how do you propose we:\n\na) Maintain the integrity of the system?\nb) Distribute/Seed the system with coins?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7897#msg7897"},{"f":"knightmb","d":1281115450,"b":[["q","I think you are rationalizing away a serious issue. Botnets exist, and the owners of botnets seek to monetize them. Bitcoin minting is an available strategy. Saying \"If someone is going to steal electricity, targeting a 30 watt computer doesn't make a lot of sense\" is a complete non sequitir. Being in control of a botnet means YOU ALREADY HAVE STOLEN the electricity, the question is - how are you going to make use of it? It is very simple economics that bitcoin production is roughly proportional to energy input, and that therefore the most efficient producers will be those who are able to obtain that electricity at zero cost.","Quote from: gridecon on August 06, 2010, 04:48:00 PM"],["t","A botnet is a stolen computer already, the concern people have is that it will take over bitcoin in some way. What you are talking about is what we already know. They use the stolen CPU time to generate BTC and then sell it on the market. It's stolen CPU time, we have no control of that. What we do have control over is how much damage it can do to others that are running honest clients."],["q","In making an analysis of an economic system, you obviously proceed by determining how self-interested actors will behave in that system. I am completely unconvinced by hand-waving arguments that try to claim people will not behave in selfish and unethical ways, if they see an opportunity for profit. We already KNOW that people are throwing a lot of computational resources into minting bitcoins, the steadily increasing difficulty is exactly equivalent to a steadily increasing computational cost of the system! The more energy invested in the production of the same quantity of coins, the harder bitcoin has to work to deliver value added on that cost.","Quote"],["t","The system was designed with that in mind. That's why it uses a formula that forces anyone that participates in the protocol to behave or else they are ignored. So if anyone is going to game the system, they have to do it by the rules that everyone else is following. Right now, the only rule to game is CPU time. It's either expensive, donated, or stolen."],["q","Again, an analysis of the behavior of self-interested actors is instructive. The most energy-efficient scenario for bitcoin generation in the current regime would be if there was ONE NETBOOK that generated all the coins - the rate of coin production is fixed, so you'd still have the same amount of coins entering circulation. The person who ran that netbook would obviously be in a position to charge a high \"rent\" from the population that needed bitcoins for their transactions. An examination of this limit case makes it clear that bitcoin minters have a strong incentive to encourage use and circulation of the currency while discouraging additional minting nodes from coming online. This is not any kind of criticism of anyone's ethics - it is simply an examination of how the game is set up, and what strategies players will adopt.\n\nAs 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.","Quote"],["t","That's the problem with having one PC generate all the coin, that one PC is a central authority of it and can price it anyway he/she likes. To de-centralize it means you need some way to force everyone to play by the rules or else one person will try to bend the rules.\n\nI respect that you don't agree with how it works, so I offer up that we be shown a better way that we can't all punch holes in. It's open source software, if there is a better way, it can be used. Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\"."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7904#msg7904"},{"f":"kiba","d":1281115841,"b":[["q","Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".","Quote from: knightmb on August 06, 2010, 05:24:10 PM"],["t","You mean it is designed  to \"trust no one\", not of \"trust everyone collectively\"?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7907#msg7907"},{"f":"knightmb","d":1281116816,"b":[["q","> Quote from: knightmb on August 06, 2010, 05:24:10 PM\n> Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".\n\nYou mean it is designed  to \"trust no one\", not of \"trust everyone collectively\"?","Quote from: kiba on August 06, 2010, 05:30:41 PM"],["t","Trust no one node, but if enough nodes are saying the same thing, then trust that.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=721.msg7918#msg7918"},{"f":"Red","d":1281118611,"b":[["q","> Quote from: kiba on August 06, 2010, 05:30:41 PM\n> > Quote from: knightmb on August 06, 2010, 05:24:10 PM\n> > Currently the rules are why they are because the entire network is designed with \"trust no one\" but instead \"trust everyone collectively\".\n> You mean it is designed  to \"trust no one\", not of \"trust everyone collectively\"?\nTrust no one node, but if enough nodes are saying the same thing, then trust that.  Grin","Quote from: knightmb on August 06, 2010, 05:46:56 PM"],["t","This exchange is fascinating! At some sense it's just a matter of semantics, but it is very insightful semantics.\n\nLogically I can support knightmb's statement \"trust everyone collectively\".\nHowever kiba's statement \"trust no one\" is disprovable,\nas is knightmb's statement \"Trust no one node, but if enough nodes are saying the same thing, then trust that.\"\n\nThe way the system works is every node attempts to receive every transaction, they each try to put every received transaction into a block at the same time. And while they are doing that, they each play the hashing game individually looking for fate to bless them with a match before it does anyone else.\n\nSo at any given point in time the system is really *trust (but validate) someone arbitrarily*. This happens when someone declares a block & hash \"solved\". All the other nodes check the block for self consistency, but they DON'T check the block's transactions for consistency with the transactions they themselves were working on. Nor do they check against the transactions other nodes received. So I see no support for the \"if enough nodes are saying the same thing, then trust that.\"\n\nAll nodes simply declare, \"I will trust this node's work as the next increment of bitcoin truth, because fate has blessed it.\" So it doesn't qualify as a \"trust no one\" system. Node's never say, \"Hey you fuck head! I have 5 known transactions you didn't bother to put in your block! You are a lying bastard.\" Everyone just presumes the missing transactions will be resubmitted and they'll end up in a subsequent block. This is heuristically plausible, but not absolutely deterministic. Everyone has to keep checking to make sure their transactions actually cleared the process.\n\nSo if knight's \"trust everyone collectively\" meant, \"trust in the process\" I find that insightful and a good motto. I'd probably add \"...but keep doing your own validation!\""]],"u":"https://bitcointalk.org/index.php?topic=721.msg7926#msg7926"},{"f":"gridecon","d":1281119022,"b":[["q","> Quote from: gridecon on August 06, 2010, 04:48:00 PM\n> 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.\n\nYou seem to have things backwards.\nThe \"dice rolling\" is to maintain the \"chain of proof\".\nActually giving out the coins is a side effect.\n\nI have 2 questions for you:\n\nWithout high computational burden how do you propose we:\n\na) Maintain the integrity of the system?\nb) Distribute/Seed the system with coins?","Quote from: Insti on August 06, 2010, 05:15:28 PM"],["t","I understand that the incredibly thermodynamic inefficiency I was complaining about is in fact very deliberate, and bitcoin might be said to waste as much energy as possible, as a security feature! Now I really don't know what to think - because exactly what I was complaining about gives the system its diabolical effectiveness. I think my earlier analogy with deliberately burning wheat and trading photographs of the ruined crops is very apt. We are all ceremonially burning computer cycles as an investment of resources in a \"trust pool\". The irreversibility of the process - the fact that we are burning our computational wheat crop just to crank out unusually numerically small hashes - is definitely perverse, and deliberately so. The entirely stupid amount of resources wasted minting bitcoins makes it nigh-impossible that anyone would choose to be EVEN STUPIDER as to waste the amount of resources necessary to outcompute you.\n\nThe problem is, if you look at the competition in the world of digital currencies - online casino currencies, mmorpg currencies, and the like - they often have much larger economies than bitcoin, with much less security, verifiability, and certainly much lower thermodynamic burden! The market, in the form of consumers, does not seem to demand a massive investment of random numbers to be willing to trade in a currency. I understand of course that the competition is generally centralized and that the thermodynamics of bitcoin are designed as a substitute for central authority - but I personally would regard a \"large enough\" network of nodes signing a transaction history using standard public key cryptography to be secure enough to use without demanding to see photographs of 500 billion bushels of burnt wheat as proof of the network's seriousness.\n\nI see three additional replies written while I was typing this, so I'll try to refocus:\n\nI understand the system, and appreciate its strengths. I am actually happy to participate in the bitcoin economy, sending coins around as tips for forum posts and the like is enjoyable as a \"game\" and the cost of entry is currently pretty low. My personal concern is not over botnets taking over with forged currency, but with botnets taking over the issuance of genuine coins. That is why I think the \"security through wasting energy\" concept is flawed - not because it isn't secure, but because it has the potential to create incentives for harmful behaviors, which in turn diminishes the likelihood of building social trust in the currency."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7928#msg7928"},{"f":"knightmb","d":1281122259,"b":[["q","I see three additional replies written while I was typing this, so I'll try to refocus:\n\nI understand the system, and appreciate its strengths. I am actually happy to participate in the bitcoin economy, sending coins around as tips for forum posts and the like is enjoyable as a \"game\" and the cost of entry is currently pretty low. My personal concern is not over botnets taking over with forged currency, but with botnets taking over the issuance of genuine coins. That is why I think the \"security through wasting energy\" concept is flawed - not because it isn't secure, but because it has the potential to create incentives for harmful behaviors, which in turn diminishes the likelihood of building social trust in the currency.","Quote from: gridecon on August 06, 2010, 06:23:42 PM"],["t","Ah I understand then, the answer is botnets can't forge currency because the swarm would not accept it. The only thing they can do is produce \"real\" currency at the expense of the stolen CPU time. Just like forcing slaves to mine gold will still net you real gold, just at no cost.\n\nThe only known *practical* attack to bitcoin from a botnet would be to have more CPU than the swarm at your command and to use that CPU power to double-speed currency. So while that could possible fall in into the \"forged currency\" category, it's not so much to make fake currency as it is spending valid currency twice before anyone notices."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7933#msg7933"},{"f":"NewLibertyStandard","d":1281122447,"b":[["t","I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency. Yeah, they're stealing the electricity and yeah, they're profiting, but at least they're putting their stolen CPU cycles to a useful and accepted purpose instead of more harmful activities that they probably would be engaged in if they had not discovered bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7936#msg7936"},{"f":"gridecon","d":1281123032,"b":[["q","I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency. Yeah, they're stealing the electricity and yeah, they're profiting, but at least they're putting their stolen CPU cycles to a useful and accepted purpose instead of more harmful activities that they probably would be engaged in if they had not discovered bitcoin.","Quote from: NewLibertyStandard on August 06, 2010, 07:20:47 PM"],["t","Ok, bravo for an amazingly honest and straightforward answer. That is probably the most overall convincing argument I have seen made in the thread. You are arguing that the overall social utility of Bitcoin is \"worth it\" - worth both the raw energy cost of the computational work, and worth the regrettable fact that it provides a profit opportunity for botnet operators. I don't have a proposal for how exactly you measure the costs and benefits, but I entirely agree with your analysis of the bottom line of the situation. You could even make the argument that minting bitcoins as an activity is less harmful than other botnet activities like sending out spam. "]],"u":"https://bitcointalk.org/index.php?topic=721.msg7938#msg7938"},{"f":"MoonShadow","d":1281124111,"b":[["q"," You could even make the argument that minting bitcoins as an activity is less harmful than other botnet activities like sending out spam.","Quote from: gridecon on August 06, 2010, 07:30:32 PM"],["t","I think that he already did."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7946#msg7946"},{"f":"jgarzik","d":1281124405,"b":[["q","I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency.","Quote from: NewLibertyStandard on August 06, 2010, 07:20:47 PM"],["t","Well said.\n\nParticipation in the network as an honest node helps everyone."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7950#msg7950"},{"f":"BitLex","d":1281124954,"b":[["q","You are arguing that the overall social utility of Bitcoin is \"worth it\" - worth both the raw energy cost of the computational work, and worth the regrettable fact that it provides a profit opportunity for botnet operators.","Quote from: gridecon on August 06, 2010, 07:30:32 PM"],["t","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.\n\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)."]],"u":"https://bitcointalk.org/index.php?topic=721.msg7955#msg7955"},{"f":"satoshi","d":1281203169,"b":[["t","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.\n\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."],["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.","Quote from: gridecon on August 06, 2010, 04:48:00 PM"],["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=721.msg8114#msg8114","s":1,"n":327,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/327/","qt":["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.","Proof-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."],"qc":["bitcoin-economics","proof-of-work"]},{"f":"Red","d":1281206881,"b":[["t","I say this half flippantly and half seriously. :-)"],["q","If 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.","Quote from: satoshi on August 07, 2010, 05:46:09 PM"],["t","If I were you, I would have considered a mapping that included, \"For each entry into the bitcoin transaction recording/gold mining lottery, please send $10 to Satoshi.\"\n\nThat would discourage botnet operators from thousands of nodes. And if it didn't you would have tens of thousands of dollars! ;-)"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8130#msg8130"},{"f":"NewLibertyStandard","d":1281207387,"b":[["q","I say this half flippantly and half seriously. :-)\n\n> Quote from: satoshi on August 07, 2010, 05:46:09 PM\n> If 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.\n\nIf I were you, I would have considered a mapping that included, \"For each entry into the bitcoin transaction recording/gold mining lottery, please send $10 to Satoshi.\"\n\nThat would discourage botnet operators from thousands of nodes. And if it didn't you would have tens of thousands of dollars! ;-)","Quote from: Red on August 07, 2010, 06:48:01 PM"],["t","I can't imagine a more splintered network. Wink"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8133#msg8133"},{"f":"Red","d":1281211759,"b":[["q","I can't imagine a more splintered network. Wink","Quote from: NewLibertyStandard on August 07, 2010, 06:56:27 PM"],["t","You laugh and I did too. But consider that the launch of bitcoin could have gone this way.\n\n--------\n\nHi I'm Satoshi, you a are the 20 largest ISP's in the world. I'm launching a new network cash service. It will add significant value to your existing customer base and make you some additional revenue.\n\nSo here is the deal, In exchange for each of you running a bitcoin transaction verification peer and signing this contract, you will receive 1,000,000 BTC. You agree (in the contract) to distribute >= 500,000 BTC to your existing customer base in the first year. You may sell them, give them away to new subscribers or as a value add to promotions. Compete among yourselves, dispose of them anyway you want. Dispose of or keep the rest to dispose of in the future.\n\nYou also agree to run the transaction verification servers honestly for X years. Here is a free client you can pass out to your customers, you can give it away or charge them a service fee. Compete among yourselves.\n\nEach of you pay me $100 for the privilege, you'll make that back the first day.\n\nThank you for your $2,000 good luck to you all!\n\nPoof, now there is a functioning bitcoin network will all 21,000,000 coins in circulation. Satoshi gets to keep the last 1,000,000 BTC + he gets the $2,000.\n\nBitcoin builds on the reputation of the 20 largest ISP's and is adopted immediately. 20 trusted nodes can reach consensus quickly so there is no reason for the hashing game or new minting rewards.\n\n----\n\nI don't think that is too pie in the sky for some of the clever salesmen I know to pull off."]],"u":"https://bitcointalk.org/index.php?topic=721.msg8138#msg8138"},{"f":"knightmb","d":1281219088,"b":[["q","> Quote from: NewLibertyStandard on August 07, 2010, 06:56:27 PM\n> I can't imagine a more splintered network. Wink\n\nYou laugh and I did too. But consider that the launch of bitcoin could have gone this way.\n\n--------\n\nHi I'm Satoshi, you a are the 20 largest ISP's in the world. I'm launching a new network cash service. It will add significant value to your existing customer base and make you some additional revenue.\n\nSo here is the deal, In exchange for each of you running a bitcoin transaction verification peer and signing this contract, you will receive 1,000,000 BTC. You agree (in the contract) to distribute >= 500,000 BTC to your existing customer base in the first year. You may sell them, give them away to new subscribers or as a value add to promotions. Compete among yourselves, dispose of them anyway you want. Dispose of or keep the rest to dispose of in the future.\n\nYou also agree to run the transaction verification servers honestly for X years. Here is a free client you can pass out to your customers, you can give it away or charge them a service fee. Compete among yourselves.\n\nEach of you pay me $100 for the privilege, you'll make that back the first day.\n\nThank you for your $2,000 good luck to you all!\n\nPoof, now there is a functioning bitcoin network will all 21,000,000 coins in circulation. Satoshi gets to keep the last 1,000,000 BTC + he gets the $2,000.\n\nBitcoin builds on the reputation of the 20 largest ISP's and is adopted immediately. 20 trusted nodes can reach consensus quickly so there is no reason for the hashing game or new minting rewards.\n\n----\n\nI don't think that is too pie in the sky for some of the clever salesmen I know to pull off.","Quote from: Red on August 07, 2010, 08:09:19 PM"],["t","You would then have to rely on \"for profit\" companies to be the central authority for the new currency and how long would it take to generate the full chain even at a difficulty of 1.00?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8156#msg8156"},{"f":"Red","d":1281220669,"b":[["t","I'm not opposed to for profit companies. Nor am I opposed to your for profit venture. Eventhough you have a huge advantage by learning about bitcoin before most people.\n\nMy point was, if you have only twenty-one nodes validating transactions you don't need the block list at all. There are easier ways of reaching consensus with a smaller pool of peers."]],"u":"https://bitcointalk.org/index.php?topic=721.msg8163#msg8163"},{"f":"gridecon","d":1281220997,"b":[["q","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. I 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.\n[...]\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.","Quote from: satoshi on August 07, 2010, 05:46:09 PM"],["t","Thanks very much for your reply. I agree with your analysis, and this thread has actually changed my mind as to my initial criticism. After more careful study of the design of the Bitcoin network and trying to understand the exact manner in which Bitcoin attempts to create value from the computational work invested, I am now inclined to think that bitcoin is in fact high EFFICIENT rather than inefficient. My thinking now is that bitcoin does not, in fact \"waste\" computational work at all - instead it works hard to deliver the most value possible from that computational work. Something like a governnment issued fiat currency may not have any obvious energy burden beyond its printing - but in fact, maintaining the value of a fiat currency requires a substantial investment in maintaining police enforcement, a legal system, and national defense. In comparison to the energy cost of hiring police officers to enforce economic honesty, the energy costs of investing cpu cycles in guaranteeing that honesty mathematically seem very small!"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8165#msg8165"},{"f":"joechip","d":1281363795,"b":[["q","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.\n\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.","Quote from: satoshi on August 07, 2010, 05:46:09 PM"],["t","I agree with nearly everything you said, but I disagree, fundamentally, with the bolded.  Gold mining is not a waste of energy.  It is the opposite of waste, it is the measure of value people place in the 'utility of having gold as a medium of exchange' or a store of wealth, jewelry around their body parts or connectors on their home theater system.  If there was no demand for gold, the price would be zero.  Hence it is not a 'waste,' by definition.\n\nI object strenuously to this idea, promulgated by the Monetarists, that the production of money is wasted capital which could be spent on other wealth-building projects.  It's a short-sighted argument which does not fully encompass the value we place in our money.\n\nIt's semantics, yes, but the negative connotations associated with the word \"waste\" is a tool of the money masters designed to confuse us and elevate their bankrupt system.\n\nTa,"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8365#msg8365"},{"f":"Red","d":1281378965,"b":[["t","I really I understood the point of this thread but I guess I didn't.\n\nI assumed that if you could design to do the exact same thing in the same commodity quantities and at the same protection level, BUT consuming less energy and producing less BTUs of heat, then that would be less wasteful.\n\nYou can mine gold in lots of ways, some require less resources than others. If two processes produce the same amount of gold then no point in optimizing anything else?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8385#msg8385"},{"f":"MoonShadow","d":1281381129,"b":[["t","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.\n\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. \n\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.\n\nWhat if such a system were retrofitted onto the Alaskan Oil Pipeline, for example, one mile at a time?"]],"u":"https://bitcointalk.org/index.php?topic=721.msg8394#msg8394"},{"f":"satoshi","d":1281389319,"b":[["t","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.\n\nIf you have other cheaper heating than electric, then the waste is only the difference in cost.\n\nIf it's summer and you're using A/C, then it's twice.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=721.msg8431#msg8431","s":1,"n":337,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/337/","qt":["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."],"qc":["mining"]}]},{"id":"p168","k":"p","s":"bitcointalk","t":"latency and locality","u":"https://bitcointalk.org/index.php?topic=723","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/168/","m":[{"f":"mkrogh","d":1281078356,"b":[["t","Hi bitcoin users\n\nI found bitcoin yesterday, and I am really impressed by the idea of avoiding issuers/banks in a digital cash system.\n\nHowever, I have one objection that I would like your view on.\n\nThat is the latency, or delay in a local transaction. Let us say that a payer and payee are located in the same city for example. I will claim, that they want a payment to go through\nwith a delay not much slower than the latency of network connections. With an issuer and using local coins (a prefix, say, can be used to localize a server of the issuer), the transaction should be done and verified in 100 microseconds or less. With a global p2p network, it is necessary to have all nodes receive the transaction, do some calculations and send results back.\nIt is not feasible,  with the speed of light as an upper limit, to do this faster than a second. As I understand it you actually use something like 10 minutes for one block, or even more for several block verifications. This means that verification of the absence of double spending is 10,000 or even tens of millions times too slow. This would get even worse in interplanetary trade of course.\n\nThe ideal payment system should be decentralized but also local, i.e., the verification of a local transaction must not have to wait for a light signal to travel to the other end of the \"universe\" and come back again.\n\nLocality, in the sense describe here, is crucial, I will claim.\n\nSincerely,\n\nMorten Krogh."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7797#msg7797"},{"f":"FreeMoney","d":1281080155,"b":[["t","Why is it crucial?\n\nOne system doesn't have to be used for all needs. If interstellar money is needed people will choose whatever is best for that, same if people need their money in less than a second."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7801#msg7801"},{"f":"knightmb","d":1281081878,"b":[["q","It is not feasible,  with the speed of light as an upper limit, to do this faster than a second. As I understand it you actually use something like 10 minutes for one block, or even more for several block verifications. This means that verification of the absence of double spending is 10,000 or even tens of millions times too slow. This would get even worse in interplanetary trade of course.","Quote from: mkrogh on August 06, 2010, 07:05:56 AM"],["t","It depends on your network layout. If you are using the entire public network, then yes you are depending on that time for the data to be processed by everyone else that is running a node. But, you don't have to do it that way. You can build a trusted node (like a server) and have your clients direct connect to it and let it do the fast verification for you.\n\nIt won't net you 20 confirmations in a few milliseconds, but it will help stop double-spending as long as you remain in control of that node because it knows what is being spent. The whole double-spending issue arises from trust. When you are comparing anonymous seller to anonymous buyer, the only \"middle man\" for trust is the entire swarm (hence confirmations that neither is cheating)\n\nIf you know you can trust your own node(s), then it reduces the likely-hood that double-spending will occur within your own trusted network. So if your example applied to an ATM like card for example, the bank (or whoever) would have all of those ATM machines networked to their own private node (or server) which would then further connect to the outside (Internet) for the rest of the transactions. So if you went to an ATM, withdrew 100 BTC (say the entire account only had that much), then moments later went to another ATM elsewhere and tried to withdraw that amount again, somewhere along that trusted chain would spot a double-spend attempt and basically report back no BTC left for that address.\n\nThe whole verification process is how you put the swarm to work, all those clients are examining if your transaction was valid or not, but you don't have to wait for them to transfer the coin around. You can spend the coin around in circles all day without a single transaction verification. It's only when double-spending occurs does the network correct for itself and fix the balances.\n\nBanks already have this exact same problem. They all have their own networks that connect to other bank networks and it's just as easy to double-spend on their ATM as has been demonstrated at black-hat hacker conventions for probably 10+ years now. I remember reading about the issue back in 1997 because a lot of networks will still on dial-up then for banks and the latency issue was part of the attack because everyone had their own *database* that all had to inter-connect.\n\nWith bitcoin, everyone is the database and banker and guard at the same time, so while it's not perfect, it's actually a lot better than what banks are using. Have you ever noticed at an ATM they have about 20 \"network\" stickers for all the different banks and setups that the ATM has to be compatible with?"]],"u":"https://bitcointalk.org/index.php?topic=723.msg7806#msg7806"},{"f":"Insti","d":1281082090,"b":[["t","OP, have you read the Bitcoin snack machine thread <http://bitcointalk.org/index.php?topic=423.0>?"]],"u":"https://bitcointalk.org/index.php?topic=723.msg7807#msg7807"},{"f":"mkrogh","d":1281095310,"b":[["t","FreeMoney, I think it is crucial to have fast local transactions. It is needed for many businesses and person to person payments.\n10 minutes or even 10 seconds is too slow. An extraterrestrial system was just an extreme example.\n\nThe most pressing problem, as I see it, is to get a digital cash system that makes it possible for people and small businesses to pay each other fast and without\nregistration and supervision from a big company/government.\n\nI read the thread about vending machines. There were no real solutions except companies that would monitor for double checking in a few seconds. I agree that would be possible,\nbut we would lose the whole point of not having an issuer. This company needs to be trusted, it will break anonymity, and people need an account with that company.\n\nWhat is wrong with the follwing \"standard\" system. A central bank/government issues a currency like today. It sets up servers around the world to validate transactions.\nPeople pay each other by means of a single verification with one of the centeal bank's servers. The speed issue is solved by coins having the location of the relevant server embedded in them. In worst case, the server would need to make long round trips to other severs, but in most cases the first server would know the answer already. The cental bank could have an algorithm for distributing coins around the network to optimise latency and server load. The wallet would have an algorithm for choosing the most local coins when making a payment.\nThe wallet could also prepare by exchanging coins with the server. On your way to Europe, the wallet replaces \"American coins\" with European coins, such that payments will be fast in Europe. For the user, this is incredibly easy. It is anonymous, and it requires no agreements with any processing companies.\nAlso, there could be many issuers of the same currency if so desired.\n\nBitcoin gets rid of the issuers, but instead introduces unacceptable slowness or a lot of middlemen like credit card companies/debit accounts etc. Satoshi's solution, on the vending machine thread, with a double spending checking company is still too slow, even though faster than a block, and this company needs an omnipresence on the network almost like\nan issuer.\n\nBut discarding speed, bitcoin seems extremely elegant. And of course there are uses for this kind of system. One could imagine many local bitcoin systems with an exchange between\ndifferent currencies. That would work except that an attacker can take over a small currency."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7840#msg7840"},{"f":"Insti","d":1281099012,"b":[["q","The most pressing problem, as I see it, is to get a digital cash system that makes it possible for people and small businesses to pay each other fast and without\nregistration and supervision from a big company/government.\n\n...\n\nWhat is wrong with the follwing \"standard\" system. A central bank/government issues a currency like today. It sets up servers around the world to validate transactions.","Quote from: mkrogh on August 06, 2010, 11:48:30 AM"],["t","So the solution to avoiding a big company/government regulation is a big company/government?\n\nIt is currently possible with Bitcoin to do transactions which are practically instant particularly if you do not fear some vast conspiracy to defraud you.\nIf you really do have need of transactions faster than Bitcoin can offer, use a different system, but you will probably have to forgo some of the benefits that Bitcoin currently offers."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7843#msg7843"},{"f":"mkrogh","d":1281103210,"b":[["t","No, my goal is not to avoid government involvement in the payment system, but to not have the government monitor every transaction. There is a difference.\n\nThe current bill/coin system works like that. The government/central bank issues the currency but they don't monitor individual cash payments.\nI think that is okay.\n\nYou claim that is possible to make almost instantaneous payments with bitcoin. How? That is what I thought everybody agreed upon was not possible. You need to wait for\none or more blocks to be solved before you can trust a coin. That takes minutes. Even in the best case it is limited by propagation, with the speed of light, around the network which is slow. The only solution is to create another banking system on top of this. Bitcoin then becomes the backbone of an intebank transfer system, not what the population at large is using.\n   \nIt is not just me that needs fast transactions. There is giant demand for fast transfers of digital cash from cell phone to cell phone, web shopping, stock trading etc. \n\nBut, we might just have different expectations from a digital cash system.\n\nHas anyone ever stated clearly what problem bitcoin is solving? It seems to solve the problem of payments that don't need to be fast. But who are the potential users of that beyond people who thinks it is theoretically interesting like people on this board.\n\nDo people agree with me on this point: We still need another digital cash system, and that probably needs to be issuer based."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7850#msg7850"},{"f":"Insti","d":1281105050,"b":[["q","No, my goal is not to avoid government involvement in the payment system, but to not have the government monitor every transaction. There is a difference.\n\nThe current bill/coin system works like that. The government/central bank issues the currency but they don't monitor individual cash payments.\nI think that is okay.","Quote from: mkrogh on August 06, 2010, 02:00:10 PM"],["t","Every transaction is monitored in the bitcoin system."],["q","You claim that is possible to make almost instantaneous payments with bitcoin. How? That is what I thought everybody agreed upon was not possible. You need to wait for\none or more blocks to be solved before you can trust a coin.","Quote"],["t","That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.\nAnd people are going to shop with those who will give them speedy transactions."],["q","That takes minutes. Even in the best case it is limited by propagation, with the speed of light, around the network which is slow. The only solution is to create another banking system on top of this. Bitcoin then becomes the backbone of an intebank transfer system, not what the population at large is using.\n   \nIt is not just me that needs fast transactions. There is giant demand for fast transfers of digital cash from cell phone to cell phone, web shopping, stock trading etc. \n\nBut, we might just have different expectations from a digital cash system.","Quote"],["t","Clearly."],["q","Has anyone ever stated clearly what problem bitcoin is solving? It seems to solve the problem of payments that don't need to be fast. But who are the potential users of that beyond people who thinks it is theoretically interesting like people on this board.","Quote"],["t","Anyone who currently uses PayPal for a start."],["q","Do people agree with me on this point: We still need another digital cash system, and that probably needs to be issuer based.","Quote"],["t","I don't. But I'm just one person."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7855#msg7855"},{"f":"mkrogh","d":1281107538,"b":[["q","Every transaction is monitored in the bitcoin system.","Quote from: Insti on August 06, 2010, 02:30:50 PM"],["t","But you can make it anonymous. Why are you bringing this up?This is a point, were I thought we agreed.\nWhen I said monitoring, I meant including identification of the payer and payee."],["q","That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.\nAnd people are going to shop with those who will give them speedy transactions.","Quote"],["t","Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending."],["q","Anyone who currently uses PayPal for a start.","Quote"],["t","Most of those will prefer a fast issuer based system over a slow decentralized system, I will claim.\nBut they might prefer bitcoin over paypal."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7861#msg7861"},{"f":"Insti","d":1281109994,"b":[["q","> Quote from: Insti on August 06, 2010, 02:30:50 PM\n> Every transaction is monitored in the bitcoin system.\n\nBut you can make it anonymous. Why are you bringing this up?This is a point, were I thought we agreed.\nWhen I said monitoring, I meant including identification of the payer and payee.","Quote from: mkrogh on August 06, 2010, 03:12:18 PM"],["t","Ok, when you said monitoring I thought you meant monitoring, so I was just pointing out that all the transactions were trackable in case you did not already understand this. Since it seems you do it's not a problem Smiley"],["q","> Quote\n> That is your requirement for trust, not mine. You can trust a transaction as soon as you see it if you like.\n> And people are going to shop with those who will give them speedy transactions.\n\nYes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.\n\n> Quote\n> Anyone who currently uses PayPal for a start.\n\nMost of those will prefer a fast issuer based system over a slow decentralized system, I will claim.\nBut they might prefer bitcoin over paypal.","Quote"],["t","It seems we have differing opinions on the way future will develop. Which is fine.\nIt'll probably turn out nothing like either of us expect anyway."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7872#msg7872"},{"f":"mkrogh","d":1281111945,"b":[["t","Yes, it might turn out very differently. No digital cash for the masses for instance. A giant banking cartel that bribes politicians to keep the current system. "]],"u":"https://bitcointalk.org/index.php?topic=723.msg7881#msg7881"},{"f":"Red","d":1281116010,"b":[["t","mkrogh: Yes, you are correct.\n\nThere is absolutely no requirement for there to be such latency in the bitcoin system. Nothing fundamental would change if the system were implemented with a block list that updated every 10 seconds, instead of every 10 minutes. It was just a design decision that could be changed without effecting monetary policy a bit.\n\nIn fact, there is no requirement their be a block list that updates in increments at all. The system would work fine if each transaction were validated one-by-one. In effect one transaction per block. That was a design decision to make networked consensus building easier.\n\nHowever, when you say \"local transaction validation\" what you are grasping for is a truly distributed system, rather than a monolithic system made redundant. The current version of bitcoin is the latter. Each node does exactly the same work as every other node. Each redundantly checking every transaction. It is a system horribly wasteful of resources. And because it is so wasteful, generates latency as a waste product.\n\nBitcoin could be made into a truly distributed system by storing the transaction graph in a distributed hash table. This is the kind of magic that is behind most other P2P systems. In effect, each bitcoin address would be arbitrarily mapped to a smaller set of nodes that checked its transactions. In such a system, there is no need to broadcast global state to every machine. This takes huge amount of latency out without needing to change any of the desired behavior."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7908#msg7908"},{"f":"FreeMoney","d":1281116732,"b":[["q","Yes, that is my requirement, and will be most others as well. You will see almost no companies that sell without a guarantee against double spending.","Quote from: mkrogh on August 06, 2010, 03:12:18 PM"],["t","Did you know about this? You don't need to wait for it to get in a block to have way better certainty than PP or checks."],["q","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.\n\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.\n\nA rough back-of-the-envelope example:\n1         0\n4         1\n16        4\n64        16\n80%      20%\n\nSo if a double-spend has to wait even a second, it has a huge disadvantage.\n\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.","Quote from: satoshi on July 17, 2010, 10:29:13 PM"]],"u":"https://bitcointalk.org/index.php?topic=723.msg7915#msg7915"},{"f":"mkrogh","d":1281122263,"b":[["t","FreeMoney, yes I knew about that.\n\nRed, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated. That must be coin\ndependent because of double spending. So, if I understand, it must be possible, for any transaction, to choose which location the resulting coin should be validated in when that\ncoin is used next time. A random choice would not be good enough. But, are there some problems with an attacker taking over a certain location. The global system had the strength that an attacker would be outworked by the sum of all other CPUs.\n\nRed, can you elaborate more on such a distributed version of bitcoin. Is it described anywhere?\n\nCheers."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7934#msg7934"},{"f":"Gavin Andresen","d":1281123372,"b":[["q","Bitcoin could be made into a truly distributed system by storing the transaction graph in a distributed hash table. This is the kind of magic that is behind most other P2P systems. In effect, each bitcoin address would be arbitrarily mapped to a smaller set of nodes that checked its transactions. In such a system, there is no need to broadcast global state to every machine. This takes huge amount of latency out without needing to change any of the desired behavior.","Quote from: Red on August 06, 2010, 05:33:30 PM"],["t","Interesting idea.\n\nSo, lets see, I create a transaction to pay you (say) 100 of my newly minted bitcoins.\n\nThat'll be a transaction with two 50BTC TxIns (signed by me, pointing to two mature GENERATE transactions somewhere in the block chain) and one 100BTC TxOuts.\n\nYou want to make sure I haven't double-spent those TxIns, so instead of flooding the network with that transaction you find the hash of the two GENERATE transactions and send two queries down into the DHT network:  \"Hey, here's a transaction, tell me if it is valid.\"  They say \"yup\", and then... what?  Include it in any blocks they're lucky enough to generate?  Broadcast it to everybody (which'd be no better than the current scheme) or some subset of the DHT network (what subset?)?\n\nHow do you know that you won't get a different answer to \"is this transaction valid\" if you ask again in 10 minutes when the network topology might have changed?\n\nI don't know much about DHT networks and how they manage to keep reliable information when nodes may be coming and going (or buggy or malicious).  How would it work?"]],"u":"https://bitcointalk.org/index.php?topic=723.msg7940#msg7940"},{"f":"MoonShadow","d":1281125497,"b":[["q","Red, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated.","Quote from: mkrogh on August 06, 2010, 07:17:43 PM"],["t","I think that you are getting lost in the choice of wording on this list.  Every bitcoin client, whether or not it is 'generating' or not, has a very recent copy of the entire block chain, and can check any new transactions against that block chain to see if those bitcoins were owned by the *address* that the other client claims he owns, at least up until the last block update.  I'm not saying local verification is implimented in the current client, but it's possible.  But that doesn't protect you from a concurrent double spend.  The distributed verification will add confidence in the validity of the transaction with each passing block, but it's not neccessary to perform a transfer.  Cash in person has similar problems, as the vendor can never be *certain* that the customer isn't passing off counterfit currency.  The risks of fraud are included in the costs of retail business, and if speed of transactions are paramount, the vendor can simply accept the results of his own client and take the risks that he might get burned.  Waiting for confirmation would help protect against fraud, but it's not a *requirement* for completion of a trade.  I would expect that smartphone clients would do this quick local verify by default, particularly when communicating with each other directly over ad-hoc wireless.\n\nAlso, the system doesn't even require that the receiving client be on the network at the time of the transfer.  You can send money to any address at any time, and their client could find out about it long after the transfer had been verified by the bitcoin network."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7958#msg7958"},{"f":"NewLibertyStandard","d":1281125731,"b":[["t","Just agree to both use the same free online wallet before you make your trade. MyBitcoin.com offers instant transfers."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7959#msg7959"},{"f":"mkrogh","d":1281130726,"b":[["t","creighto, I am only talking about verifying the absence of double spending. Of course, you can always receive a coin and just hope. That is clear.\n\nI don't think that physical coins have this issue. Or gold. Firstly counterfeiting is really difficult, secondly \"bill verifiers or gold verifiers\" are local machines. If someone could\ncounterfeit gold or coins in a way that no local machine could detect, then it would be the same. But no one can do that.\n\nWith bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it. I don't understand what red exactly is proposing.\n\nNewLibertyStandard, your suggestion is a bank, that the payer and the payee need an account with. I don't mind, but I don't think it is an answer to the issue of this thread.\n\nWhat I see as the ideal solution has these properties.\n\n1. You can participate by just having some software on your computer/phone.\n2. The coins are stored by yourself. A coin is a string of characters, no physical gold or so is involved. Encryption keys are fine if you can generate them yourself.\n3. No accounts or registrations with banks or governments are needed.\n4. Payments can be totally verified including double spending checks. Tiny probabilites can be ignored. But I mean tiny, not just reasonably small.\n5. If a person is traveling to a city, he (she) can prepare for the visit by exchanging coins. This exchange can be slow. After arriving to the city, the person can make fast payments\nto a person residing in that city. By fast payments, I mean payments that are completely validated in a time frame that does not depend on the total size of the coin system. In other words local trade should be possible, even if the digital cash system is used all over the world (or galaxy). The preparation before arrival is important here. Of course, many coins can not be verified, fast, against double spending by the payee, but there should exist some coins that can, given the location. And the payer can prepare before arrival by getting such coins.\n6. No issuer on whose honesty the system relies.   \n\n1-5 is possible with an issuer. The coins have a tag that denotes where double spending will be verified. The issuer keeps the information about those coins on their servers in that location. In other words, the issuer's distributed hash table follows some rules for what coins are stored where. And those rules are publicly available.\n\n1,2,3,4,6 seems to be bitcoin if I understand correctly.\n\nDoes 1-6 exist. Is that what red is saying?"]],"u":"https://bitcointalk.org/index.php?topic=723.msg7982#msg7982"},{"f":"NewLibertyStandard","d":1281131798,"b":[["t","In real life, bank wires take much much longer than ten minutes. Most traditional services which you see as instantaneous are actually not instantaneous. Credit card charges don't go through immediately, the funds are just reserved immediately and the retailer trusts the credit card company. Not to mention that charges can be challenged, which means the final transaction could take weeks. Real bitcoin transactions occur much more quickly than real traditional electronic money transfers. If you need instant transfers, then you just have to set up the same tricks which the traditional electronic currency market uses, and that is basically what I suggested."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7986#msg7986"},{"f":"MoonShadow","d":1281133623,"b":[["q","creighto, I am only talking about verifying the absence of double spending. Of course, you can always receive a coin and just hope. That is clear.","Quote from: mkrogh on August 06, 2010, 09:38:46 PM"],["t","There is more to it than just hoping.  For starters, you could already have an existing business relationship, and trust built between two parties due to honest prior trading. "],["q","I don't think that physical coins have this issue. Or gold. Firstly counterfeiting is really difficult, secondly \"bill verifiers or gold verifiers\" are local machines. If someone could\ncounterfeit gold or coins in a way that no local machine could detect, then it would be the same. But no one can do that.","Quote"],["t","Counterfeiting bitcoins is really difficult as well, and that is what a local blockchain check would protect you against.  It would also protect you against a double spend that wasn't concurrent, as if one guy backs up his wallet file and then spends his coins the night before and attempts to yank your chain.  It does not protect you against a professional criminal, but against the petty attempt.\n\n[/quote]\nWith bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it.\n[/quote]\n\nI know from other threads that Red has a different understanding than I about how the system works.  Either or both of us could be wrong.  My understanding is that, at present, the clients attempt to announce a transfer and then wait for the collective to confirm the transfer via accepting the claim as valid in at least two blocks, after which point the network believes that you have valid bitcoins, therefore you do.\n\nHowever, two clients can interact directly, in theory.\n\nImagine this picture...\n\nYou have a full client on your Iphone running in the background, and then there is a power failure.  You head down to the corner store, and find that the shopkeeper has put everything in the cooler on sale half price, cash or bitcoins only.  Your cellphone client connects with the shopkeeper's cell phone client over ad-hoc bluetooth.  Signs the transfer accouncement (there are no actual cryptocoins in your wallet, they exist only as a series of entries into an encrypted ledger we call the blockchain, more like writing a check than actual coins) over to the shopkeeper's address.  Shopkeeper's client can then (but does not have to) check his copy of the blockchain to verify that you actually owned said bitcoins at the time of his last blockchain update.  If it's good locally, he can assume that you are not trying to cheat him and accept the trade and you leave with your half priced milk.  This does not protect the shopkeeper from an intentional double spend, but you still had to have honestly owned the coins at one time in order to do this.  If you did not own the coins at the time the power went out, his client would have rejected the transfer.\n\nThis also means that the shopkeeper can only spend bitcoins that he had at the time of the power failure himself, since any new bitcoins that he receives will not yet be included in the blockchains of any other vendor, and any attempts by his client to transfer his unannounced coins will be rejected by the other clients.  All transfers will either be verified or rejected by the network within 30 minutes of network reconnection."]],"u":"https://bitcointalk.org/index.php?topic=723.msg7995#msg7995"},{"f":"Red","d":1281136108,"b":[["t","What I'm suggesting doesn't exist yet. There was related talk about similar issues on the thermodynamic perversity of generating blocks. If I have just one central node, the system could generate a transaction block in a fraction of a second. If you wanted, it could do this only once every ten minutes. But it wouldn't need any more than a fraction of a second of CPU time on a single processor.\n\nThe reason is purely related to consensus.\n\nSo if you had two nodes, you could have them both redundantly capture all transactions, and then in a fraction of a second each could generate a block. They could then exchange block hashes and if they matched, they would have consensus. If they didn't match you could reach consensus in one of two ways. 1) compare the transactions of each block one by one, and create a block consisting of the union of all transactions. or 2) Just pick one of the blocks and go with it. The second is what bitcoin actually does now.\n\nIt just picks using the worlds most expensive coin flipper. You could accomplish the same task with a much cheaper coin flipper and nothing in bitcoin would change one bit.\n\nThat is what I mean by \"design decision\" a it doesn't change any of the requirements for the system's features or behavior. It just implements things differently.\n\n----\n\nSo when I talk about distributing the transaction graph throughout a distributed hash table it is just a different possible (but currently non-coded) way of implementing bitcoin's key feature. The feature of verifying the transfer of bitcoins from one address to another, in a way that makes it impossible to double spend coins.\n\nOptimally, if you had x,000 transactions per minute and 100 nodes, each node would only have to do 1/100th of the work of a single node handling x,000 transactions per minute. Each transaction is only required to be recorded once.\n\nHowever, with the current bitcoin implementation, if you have 100 nodes, they all run at 100% cpu for x,000 transactions. If you add another 100 nodes, they all still run at 100% cpu but do exactly the same job. We used to call it \"government work\" when you could do a job with 5 guys, but instead they used 50 guys, because more people working is better for the economy!\n\nSo the new design constraint I'm proposing, is that for a given number of nodes (n), it should take (Order (1/n)) or maybe (Order log(n)) work per cpu to handle a given number of transactions. In this case work means CPU time and network communication. My design modifications FAIL if they give up any of the transaction protections of the existing system.\n\n----\n\nIt turns out that the block list itself is not required to validate transactions. Only the transactions are required. So to understand what I'm suggesting you have to think about an equivalent bitcoin implementation without a monolithic block list containing every transaction in the history of the system.\n\nInstead, the transactions are redundantly scattered across all the nodes. No node need keep a complete list off all transactions, but they must be able to quickly retrieve any transaction on demand. Optimally in Order(1) time, but Order(log(n) time would probably suffice. That reduces the storage requirements of any given node to Order(1/n).\n\nTransactions are mapped to nodes by transaction out-points. You generate two unique out-point identifiers by hashing the transaction+out-point information. You then store the transaction redundantly on the five \"closest nodes\" to each out-point ID. That means for a system with 10,000 nodes. Each transaction is stored with 10X redundancy instead of 10,000X redundancy. (the 10X was an arbitrary choice, the redundancy would be based upon the DHT algorithm and characteristics of the node population.)\n\nNow each of those 10 nodes holds that out-point data completely privately, unless another node can show a \"need to know\". In this case a need to know is demonstrated by submitting a signed transaction that includes a given out-point as an in-point. In this case the storage node stores the new transaction. It also returns any known transactions referencing that out-point. If there is a previous transaction in-point associated with the out-point the second transaction is a double spend.\n\nSo for any new transaction, to verify it, you send it to the five closest nodes to each in-point on the transaction. They record the transaction and immediately tell you if they've seen a double spend. If any have, it's a bogus transaction, which gets broadcast to the other close nodes.\n\nNow the what I'm suggesting also increases anonymity because you no longer have to broadcast every transaction you make to the world. Also random individuals can't go poking around in your business.\n\nThere are many ways to map bitcoin transactions to DHTs. I just chose an example that would be easy to explain. There may be other possibilities offer improvement. But this one is sufficient to get the point across.\n\nThere is also a fun technology called a \"dining cryptographers network\" that could further improve some of the anonymity aspects of bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8007#msg8007"},{"f":"Gavin Andresen","d":1281137525,"b":[["q","So for any new transaction, to verify it, you send it to the five closest nodes to each in-point on the transaction. They record the transaction and immediately tell you if they've seen a double spend. If any have, it's a bogus transaction, which gets broadcast to the other close nodes.","Quote from: Red on August 06, 2010, 11:08:28 PM"],["t","What happens when they disagree about which transaction happened first?  Majority rule?  Who decides what the majority is, and can it change if 4 of the five nodes leave the network and are replaced by another 5 nodes?\n\nAnd if I know that I'm going to create a large transaction, can I do some work precomputing node IDs such that the transaction (which I haven't yet sent out) will hash to nodes that I control?   If I control all the nodes storing the transaction, then I can just answer \"yes, absolutely, that transaction is valid and hasn't been double-spent...\"\n\nThe brilliant insight behind bitcoin is the distributed timestamping mechanism; everybody agrees on an order of transactions.  I don't see how your scheme solves that problem."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8013#msg8013"},{"f":"MoonShadow","d":1281138151,"b":[["q","Imagine this picture...\n\nYou have a full client on your Iphone running in the background, and then there is a power failure.  You head down to the corner store, and find that the shopkeeper has put everything in the cooler on sale half price, cash or bitcoins only.  Your cellphone client connects with the shopkeeper's cell phone client over ad-hoc bluetooth.  Signs the transfer accouncement (there are no actual cryptocoins in your wallet, they exist only as a series of entries into an encrypted ledger we call the blockchain, more like writing a check than actual coins) over to the shopkeeper's address.  Shopkeeper's client can then (but does not have to) check his copy of the blockchain to verify that you actually owned said bitcoins at the time of his last blockchain update.  If it's good locally, he can assume that you are not trying to cheat him and accept the trade and you leave with your half priced milk.  This does not protect the shopkeeper from an intentional double spend, but you still had to have honestly owned the coins at one time in order to do this.  If you did not own the coins at the time the power went out, his client would have rejected the transfer.","Quote from: creighto on August 06, 2010, 10:27:03 PM"],["t","There was another point here that I intended to make.\n\nAs with the example above, most cash transactions are not actually anonymous, but psuedo-anonymous.  For example, one party can be well established (the shopkeeper) while the other is mostly anonymous, (the bargain hunter in the above example) but even the buyer is not truely anonymous.  He has been in the shop many times before, and even if the shopkeeper doesn't know his name, he has seen his face enough times to recognize it.  So there is some trust that, since he is a local or regular customer, that he is not some pro trying to sting him with an opprotunistic scam.\n\nAnother example of a psuedo-anonymous transaction is the kind that both parties are anonymous to the world, but not to each other.  This is actually how *most* cash transactions work in the real world; but online it could go like this...\n\nYou want to get something, let's say, unusual.  You find this guy on, say, Tor with a hidden website selling your wanted commodity.  He is known to you only as, \"pothead420\" on the website.  You have no other way to contact him, and no means of finding out who is actually is.  You don't trust this guy, but someone is going to have to take a leap of faith, and that someone is likely going to be you.  So at first, you order small.  After a few succesful trades, your trust grows that \"pothead420\" is an honest dealer; so your orders grow larger.  He could screw you over at any time without recourse, but then he would be cutting off a regular customer, so he has an incentive to continue to treat you properly.\n\nA third kind of pseudo-anonymous trust relationship could be found on this very forum that depends on reputation.  Most of us do not use our real names, but some of us do.  We assume that the member who uses the name of the bitcoin programmer is the actual programmer, and have some evidence to support this, but we cannot know for sure.  But, as far as this forum is concerned, he has a reputation.  So if you were to do direct business with him, and screw him, his word that you are not trustworthly would harm any business that you desired to conduct in the future, solely because he has a longer reputation than any newcomer.\n\nAll of these examples involve some kind of two party trust, but not one requires both parties trust a third.  Not even the verification of the blockchain."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8019#msg8019"},{"f":"NewLibertyStandard","d":1281138947,"b":[["q","All of these examples involve some kind of two party trust, but not one requires both parties trust a third.  Not even the verification of the blockchain.","Quote from: creighto on August 06, 2010, 11:42:31 PM"],["t","Trusted third parties are very useful when trading with someone you don't trust. One person trusts the trading administrator enough to deposit bitcoins and the other person trusts a payment processor such as Liberty Reserve or Pecunix to provide proof to the trading administrator that the payment occurred and he trust the trading site administrator that he'll accept proof of payment. Both traders have to trust the trading site and the payment processor, both third parties, but they don't need to trust each other."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8021#msg8021"},{"f":"Red","d":1281140356,"b":[["t","If you look for reasons to dismiss the idea out of hand, you will find them. However if you use the example to increase your understanding of why some P2P systems succeed yet many more fail, it will give you some insight.\n\nIn that spirit, let me answer your questions directly."],["q","What happens when they disagree about which transaction happened first?  Majority rule?  Who decides what the majority is, and can it change if 4 of the five nodes leave the network and are replaced by another 5 nodes?","Quote from: gavinandresen on August 06, 2010, 11:32:05 PM"],["t","If ANY other transaction using that out-point is found there is a double spend, same rules as the current bitcoin system. The only way there can be disagreement is conflicting transactions got broadcast simultaneously but one arrived a close node A first and the conflicting one arrived at close node E first. By the end of the two 5 node broadcasts, both parties would discover the double spend.\n\nSo which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins. Distributed coin flipping algorithms are trivial. All of this can be done almost immediately. Much faster than in 10 minute windows. So no, the majority doesn't change if 4 nodes leave, because consensus was reached and the nodes were made consistent.\n\nBy the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join."],["q","And if I know that I'm going to create a large transaction, can I do some work precomputing node IDs such that the transaction (which I haven't yet sent out) will hash to nodes that I control?   If I control all the nodes storing the transaction, then I can just answer \"yes, absolutely, that transaction is valid and hasn't been double-spent...\"","Quote from: gavinandresen on August 06, 2010, 11:32:05 PM"],["t","No, this would be a requirement constraint. It is possible for the same reason that it is impossible to generate two public keys that match to the same bitcoin address. See my previous faux pas.\n\nNodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible. All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out."],["q","The brilliant insight behind bitcoin is the distributed timestamping mechanism; everybody agrees on an order of transactions.  I don't see how your scheme solves that problem.","Quote from: gavinandresen on August 06, 2010, 11:32:05 PM"],["t","It actually solves the problem in exactly the same way, just with much less CPU power.\n\nThe brilliant insight behind bitcoin's distributed time stamping mechanism is you don't need absolute timestamps at all! You only need relative order. And for conflicts in a short window, you don't have to care at all. You can simply arbitrarily choose one.\n\nMy solution does exactly the same thing. It maintains relative order among transactions. It arbitrarily reaches consensus on conflicts. Neither method has a requirement to accurately order unrelated transactions by time. Again, that was a brilliant insight."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8023#msg8023"},{"f":"Gavin Andresen","d":1281144001,"b":[["q","So which one is valid? Who cares. Flip a coin. That is exactly what bitcoin does in this situation. If my node is working on a block with on transaction, and your node is working on a block with a conflicting transaction, whoever solves the block first wins.","Quote from: Red on August 07, 2010, 12:19:16 AM"],["t","Now I'm confused again.  I thought your scheme didn't have blocks, just transactions.  What do you mean, whoever solves \"the block\" first?"],["q","By the way, standard DHTs already address preserving data when nodes leave, and spreading the data when nodes join.","Quote"],["t","But standard DHTs are typically used to store chunks of MP3s or movies, indexed by a torrent file that has the hash for every piece.  So it is easy for me to tell whether or not I'm getting bad data from any particular DHT node.  I don't have to trust them."],["q","Nodes would generate node addresses based upon private keys, exactly as is being done for bitcoin addresses. This makes node spoofing implausible.","Quote"],["t","Huh?  Lets say the network has 10,000 nodes in it.  I query the network to find the network node closest to a transaction that I want to double-spend.\n\nSo I generate a private key.  It has about a 1 in 10,000 chance of being closer than the current closest node.  So I keep generating private keys until I have 5 that are closer.  It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5.  My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000.\n\nI create 5 nodes with those keys (telling the rest of the network \"honest, folks, I chose those keys RANDOMLY...\") and I've won."],["q","All of the inputs to the out-point hash are fixed except the payee, which is pre-specified. The only flexibility I can think of would be in the payment amount. If you want to iterate through all possible amounts and try to create a simultaneous 5 way hash collision, knock yourself out.","Quote"],["t","I'm not trying to generate a transaction with a particular hash, I'm trying to generate node ids that are \"closer\" to that transaction's hash than any other node currently on the network.  That's much easier."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8035#msg8035"},{"f":"MoonShadow","d":1281146943,"b":[["q","> Quote from: creighto on August 06, 2010, 11:42:31 PM\n> All of these examples involve some kind of two party trust, but not one requires both parties trust a third.  Not even the verification of the blockchain.\nTrusted third parties are very useful when trading with someone you don't trust.","Quote from: NewLibertyStandard on August 06, 2010, 11:55:47 PM"],["t","Yes, but I was pointing out that waiting for verification is not usually neccessary in common usage of the currency.  It's the unknowns that call for waiting for verification or the use of a trusted third party.\nSo most everyday transactions, either online or IRL, can be performed with faith instantly, or with the additional confidence of the local client verification almost instantly.  The 10 minute lag isn't really a detriment."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8038#msg8038"},{"f":"Red","d":1281148744,"b":[["q","Now I'm confused again.  I thought your scheme didn't have blocks, just transactions.  What do you mean, whoever solves \"the block\" first?","Quote from: gavinandresen on August 07, 2010, 01:20:01 AM"],["t","My scheme doesn't have blocks. I was referring here to how the existing system operates."],["q","Huh?  Lets say the network has 10,000 nodes in it.  I query the network to find the network node closest to a transaction that I want to double-spend.\n\nSo I generate a private key.  It has about a 1 in 10,000 chance of being closer than the current closest node.  So I keep generating private keys until I have 5 that are closer.  It's too late for me to figure out the odds, but lets say I generate 100,000 private keys, I'm pretty darn likely to find 5.  My wimpy laptop can generate at LEAST 100 ECC keys/second, so in under 20 minutes it could generate 100,000.\n\nI create 5 nodes with those keys (telling the rest of the network \"honest, folks, I chose those keys RANDOMLY...\") and I've won.\n\nI'm trying to generate node ids that are \"closer\" to that transaction's hash than any other node currently on the network.  That's much easier.","Quote from: gavinandresen on August 07, 2010, 01:20:01 AM"],["t","Yes, It's much easier!\n\nYou've made a quite plausible argument for this particular case. Kudos!\n\nI'm not going to do the math either because that is really not the point. I'm not proposing \"The solution\". I'm suggesting that the amount of compute resources doesn't need to scale so badly to satisfy bitcoin's requirements. I'm only trying to show that there are other reasonable designs that can meet bitcoin's requirements with significantly lower CPU usage, and in the case of this thread less latency.\n\nI think with the brain-trust that is this forum, any limitations in a distributed solution are easily discovered and rectified. Just as is being done with the current implementation. Perhaps I chose a poor way to create a node ID. Freenet proposes an entirely different way of shared generation of node IDs. It doesn't suffer from the issues you point out. Perhaps it has other issues in this situation. But I'm confident there exist a distributed implementation that would work.\n\nIs the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction?\n\n(100,000 was Satoshi's number of expected core nodes for a system that supported millions of users)\n\n "]],"u":"https://bitcointalk.org/index.php?topic=723.msg8039#msg8039"},{"f":"Gavin Andresen","d":1281181934,"b":[["q","Is the main thrust and incredulity in your argument because you think there CANNOT be a better solution than burning 100,000 CPU at 100% 24/7 and sending 100,000+ redundant messages per transaction?","Quote from: Red on August 07, 2010, 02:39:04 AM"],["t","No, not at all.  Like I said when I jumped into this thread, I think using a DHT network to somehow distribute the work is a very interesting idea, it just seems to me any solution that partitions the network will be more vulnerable to attacks that insert malicious nodes.  I think it would be fantastic to come up with less resource-intensive solution that actually works.\n\nHow does Freenet generate node IDs?  The only info I see in the latest Freenet paper is:"],["q","When joining, nodes choose an identity at random, and then connect to those peers with whom they have a pre-established trusted relationship.","Quote"],["t",".... and:"],["q","The perhaps largest advantage that the trusted-connection model offers over traditional anonymity networks is protection against the Sybil attack [13], where a single attacker infiltrates the network by pretending to have many identities. Since the network depends on out of band trust relationships, an attacker gains strength only through the number of people he can fool into trusting him, and gains nothing by presenting multiple identities online.","Quote"],["t","...which doesn't sound like it would work very well for Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=723.msg8078#msg8078"},{"f":"satoshi","d":1281198497,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=723.msg8103#msg8103","s":1,"n":326,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/326/"}]},{"id":"p169","k":"p","s":"bitcointalk","t":"Escrow","u":"https://bitcointalk.org/index.php?topic=750","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/169/","m":[{"f":"satoshi","d":1281212032,"b":[["t","Here's an outline of the kind of escrow transaction that's possible in software.  This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible.\n\nThe basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer.\n\nWhile this system does not guarantee the parties against loss, it takes the profit out of cheating.\n\nIf the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him.\n\nThe buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else.\n\nNow, an economist would say that a fraudulent seller could start negotiating, such as \"release the money and I'll give you half of it back\", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8140#msg8140","s":1,"n":329,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/329/"},{"f":"Tilka","d":1281216208,"b":[["t","Cryptography at its finest Cool\n\nCould you explain how this would work on a technical basis?"]],"u":"https://bitcointalk.org/index.php?topic=750.msg8147#msg8147"},{"f":"jgarzik","d":1281216340,"b":[["t","Buyer not having recourse except burning the money will limit the utility, I think."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8148#msg8148"},{"f":"aceat64","d":1281236159,"b":[["q","Buyer not having recourse except burning the money will limit the utility, I think.","Quote from: jgarzik on August 07, 2010, 09:25:40 PM"],["t","Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously you'd want to choose a trustworthy arbitrator)."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8189#msg8189"},{"f":"jgarzik","d":1281239883,"b":[["q","> Quote from: jgarzik on August 07, 2010, 09:25:40 PM\n> Buyer not having recourse except burning the money will limit the utility, I think.\n\nPerhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously you'd want to choose a trustworthy arbitrator).","Quote from: aceat64 on August 08, 2010, 02:55:59 AM"],["t","That's how online escrow operates today.  Buyer and seller agree to let a 3rd party physically hold the money.  Buyer and seller both agree to rules that the neutral 3rd party will follow, for transaction resolution / redemption.  The neutral third party is the one who disburses funds to one party or the other.\n\nThis is a pretty decent overview: https://www.escrow.com/solutions/escrow/process.asp\n\nSome people might choose to use the bitcoin-specific signed escrow method...  but I think the \"burn the money\" recourse serves as a incentive to avoid bitcoin escrow entirely, rather than an incentive to use bitcoin escrow honestly."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8204#msg8204"},{"f":"aceat64","d":1281246584,"b":[["t","I like Olipro's suggestion is this thread: http://bitcointalk.org/index.php?topic=645.0\n\nThe buyer and seller both an equal amount of bitcoins into escrow and the seller can't retrieve both sets until the buyer signs off on it. Optionally if both parties agree the funds are returned to their original owners or both sets are transfered to an agreed upon arbitrator. I deviate from his suggestion that the arbitrator only have control over the buyers half, I think they should have control of both so that both parties still have a bitcoin stake in the issue."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8213#msg8213"},{"f":"nimnul","d":1281462709,"b":[["t","The Satoshi solution is good, because if customer can take money back, it will be a big problem to sellers. See current situation with internet credit card payments and chargebacks. Chargebacks are major PITA for sellers, bitcoin must avoid that at all cost Smiley"]],"u":"https://bitcointalk.org/index.php?topic=750.msg8561#msg8561"},{"f":"jgarzik","d":1281466437,"b":[["q","The Satoshi solution is good, because if customer can take money back, it will be a big problem to sellers. See current situation with internet credit card payments and chargebacks. Chargebacks are major PITA for sellers, bitcoin must avoid that at all cost Smiley","Quote from: nimnul on August 10, 2010, 05:51:49 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8566#msg8566"},{"f":"nelisky","d":1281471636,"b":[["t","Regardless of what the technical options are, I think that an escrow will always need to be, by definition, a trusted entity. I can see the automated workflow being easy enough when things go well:\n\n  - Buyer sends btc to escrow, stating the recipient address\n  - Seller sees btc in escrow, marked to send to his address\n  - Buyer can release funds to seller\n  - Escrow will automatically do so after x days\n  - Both parties can open a complaint\n\nAnd that's all I would automate. When things go bad, both parties should have a fee to pay to the escrow (that fee may be paid in advance to open account there?) so everyone looses something. Then the escrow will just have to mediate.\n\nBecause there's a fee *and* a human intermediary, the chances of successful fraud will probably not be economically interesting in the long run. Someone already trusted would make the ideal person for this, and maybe for a small fee some of us 'common guys' could help assert allegations from either side, if we are local to them.\n\nBut 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."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8585#msg8585"},{"f":"satoshi","d":1281490202,"b":[["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.","Quote from: jgarzik on August 10, 2010, 06:53:57 PM"],["t","That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate.\n\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.\n\nEither party always has the option to release it to the other."],["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.","Quote from: nelisky on August 10, 2010, 08:20:36 PM"],["t","Then you must also be against the common system of payment up front, where the customer loses.\n\nPayment up front: customer loses, and the thief gets the money.\nSimple escrow: customer loses, but the thief doesn't get the money either.\n\nAre you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it?\n\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.\n\nImagine if gold turned to lead when stolen.  If the thief gives it back, it turns to gold again.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=750.msg8649#msg8649","s":1,"n":340,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/340/","qt":["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."],"qc":["general"]}]},{"id":"p170","k":"p","s":"bitcointalk","t":"bitcoin generation broken in 0.3.8?  (64-bit)","u":"https://bitcointalk.org/index.php?topic=753","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/170/","m":[{"f":"lfm","d":1281236819,"b":[["t","I was starting to wonder when my systems seemed to quit generating coins if there was something going on. They went from about 1 block / day to none in a week.\n\nArtForz in irc suggested I run a test isolated net with two nodes only connected to each other with empty wallet dir. I took a couple of quad core systems and set them up. they have produced no blocks in about 90 minutes now while hashing at a combined rate of over 8000 khash/sec. Is this evidence of a problem yet or is it more bad luck?\n\nThe systems are Linux 64 bit one Intel quad q6600 and one AMD quad phenom II 940."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8191#msg8191"},{"f":"FreeMoney","d":1281236943,"b":[["t","The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8193#msg8193","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281237189,"b":[["q","The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.","Quote from: FreeMoney on August 08, 2010, 03:09:03 AM"],["t","This is on an isolated test net with just two machines, connections = 1, difficulty = 1"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8194#msg8194","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281237294,"b":[["q","The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.","Quote from: FreeMoney on August 08, 2010, 03:09:03 AM"],["t","maybe only a problem with 64 bit linux or something"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8196#msg8196","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281237869,"b":[["t","I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8198#msg8198","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"FreeMoney","d":1281238701,"b":[["q","> Quote from: FreeMoney on August 08, 2010, 03:09:03 AM\n> The difficulty went up again just after 3.8 was out. I have not gotten any with 4000khash in about 15 days, so 90 minutes of 8000k doesn't mean much. I'm sure we'd know if 3.8 wasn't generating any blocks.\n\nThis is on an isolated test net with just two machines, connections = 1, difficulty = 1","Quote from: lfm on August 08, 2010, 03:13:09 AM"],["t","Oh, that is odd then, that would be like not finding one in over 500 hours, possible I guess, but getting out there"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8199#msg8199","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281238886,"b":[["q","I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.","Quote from: knightmb on August 08, 2010, 03:24:29 AM"],["t","I guess I want to know how long I need to run 8000 khash/s at difficulty 1.0 to have any reasonable evidence of a problem. ArtForz said it should tell me in an hour or so."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8200#msg8200","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"ArtForz","d":1281238985,"b":[["t","At ~ 8Mhash/s combined not generating a block at 1.0 diff in over 1h is pretty unlikely.\nAs in, under 0.1% probability unlikely (50% is ~6 min, 1% ~42 min)\n<edit>\nForgot to mention, he's running a custom compile of stock 0.3.8 sources."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8201#msg8201","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281239889,"b":[["q","I haven't had any problems with 0.3.8 release, generated some coin on windows and Linux clients (32/64)bit just fine this week.","Quote from: knightmb on August 08, 2010, 03:24:29 AM"],["t","I am wondering if its something odd in the way I have my systems set up or Huh just various plain ubuntu installs so far as I know."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8205#msg8205","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lachesis","d":1281243904,"b":[["t","I'm having a similar problem with my own compile of the SVN trunk. I just reverted to the stock builds to test and see what happens. I should try setting up my own network of two nodes with my builds."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8209#msg8209","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281251935,"b":[["t","Ok chatting with lachesis in irc he tried this and I get the same result: We added some prints in main.cpp at the SHA calls like so :"],["c","        loop\n        {\n            SHA256Transform(&tmp.hash1, (char*)&tmp.block + 64, &midstate);\n            printf(\"mid hash =\");\n            for (int i = 0; i < 8; i++)\n              printf(\" %08x\", ((unsigned *)&tmp.hash1)[i]);\n            printf(\"\");\n            SHA256Transform(&hash, &tmp.hash1, pSHA256InitState);\n            printf(\"full hash =\");\n            for (int i = 0; i < 8; i++)\n              printf(\" %08x\", ((unsigned *)&hash)[i]);\n            printf(\"\");\n\n            if (((unsigned short*)&hash)[14] == 0)"],["t","and then in the log we get:\n\nmid hash =\n 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19\nfull hash =\n 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19\nmid hash =\n 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19\nfull hash =\n 6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19\n\nrepeating! The hash call isn't doing anything!\n(he maybe got a different repeating value, I don't know)"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8218#msg8218","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281252020,"b":[["t","There is one behavior that I've noticed.\n\nBlock sync stalling.\n\nWhen the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block. The problem is, if you stop and restart the client, it just picks up where it left off on the same stuck block. The only way I've seen to fix this is to delete the block chain so that the client will re-download it.\n\nI've had to clear out a few block chains for a few servers because of this, I'll notice they are stuck on block 70,000 for example, while the rest of the network is working on block 70,839 for example.\n\nThat might explain why you go weeks without winning a block with a 24/7 PC going.\n\nThe server farm I had running before were spitting out blocks all day, but now that I'm just down to a few dozen servers and the difficulty is way up, I barely see about 3 or 4 blocks a day spread across all of them. But I know the 0.3.8 version is working like it should, except for the occasional block freeze."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8219#msg8219","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281263552,"b":[["t","This seems to be a different problem. The blocks do not seem to be \"stuck\" on my systems. The getinfo shows them up to date\n\nIt seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others."],["q","There is one behavior that I've noticed.\n\nBlock sync stalling.\n\nWhen the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.\n\n...","Quote from: knightmb on August 08, 2010, 07:20:20 AM"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8226#msg8226","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"tcatm","d":1281268614,"b":[["t","Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8230#msg8230","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281273210,"b":[["q","Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.","Quote from: tcatm on August 08, 2010, 11:56:54 AM"],["t","That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8233#msg8233","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lachesis","d":1281282435,"b":[["q","That seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.","Quote from: lfm on August 08, 2010, 01:13:30 PM"],["t","That appears to fix it for me too.\n\nEDIT:\nI've uploaded corrected Linux builds to http://www.alloscomp.com/bitcoin/binaries/release-r123-2010-08-08/. Enjoy!"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8239#msg8239","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281289615,"b":[["q","> Quote from: tcatm on August 08, 2010, 11:56:54 AM\n> Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.\n\nThat seems to be the root of the problem. I think even the bundled binary for Linux 64 in 0.3.8 was compiled wrong then.","Quote from: lfm on August 08, 2010, 01:13:30 PM"],["t","I just tested it out, I get the same results. Repeating values with stock, more random values with the flag modification. Probably needs to be fixed for the next release, though I'm not sure how mine are generating anything then?"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8244#msg8244","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"nimnul","d":1281289810,"b":[["t","@lachesis: 404 not found\n\n@knightmb: What about a fixed CentOS build?"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8245#msg8245","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281290169,"b":[["q","@lachesis: 404 not found\n\n@knightmb: What about a fixed CentOS build?","Quote from: nimnul on August 08, 2010, 05:50:10 PM"],["t","Should be simple enough for CentOS, I was going to test it out first to see if those suffered the same issue, thought it seems like all the builds would suffer this issue if the compile flag is what makes the difference."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8246#msg8246","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281290780,"b":[["q","This seems to be a different problem. The blocks do not seem to be \"stuck\" on my systems. The getinfo shows them up to date\n\nIt seems the sha256 code is not getting built right for linux 64. Not sure if/how it could work on some and not on others.\n\n> Quote from: knightmb on August 08, 2010, 07:20:20 AM\n> There is one behavior that I've noticed.\n>\n> Block sync stalling.\n>\n> When the client (be it Windows or Linux) has been running for a few days, *sometimes* they get stuck in block limbo. What happens is your client keeps trying to solve the current block and loses track of the entire block system. So as time goes by, other blocks are solved and your PC is still stuck on the same block.\n>\n> ...","Quote from: lfm on August 08, 2010, 10:32:32 AM"],["t","I'm starting to wonder if the two are connected now since the hashing seems to get stuck, maybe that's why it gets stuck on a block."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8248#msg8248","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281292070,"b":[["t","After testing the 32bit and 64bit builds, the problem I can confirm what was already posted here, it just affects the 64bit builds. When I go back and trace what's being produced, it's the 64bit Linux machines (the 64bit windows machines don't appear to have this problem) that aren't producing any coin since the latest releases. All of the 32bit builds (stock or custom) appear to be just fine."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8255#msg8255","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281292347,"b":[["q","Did you compile it yourself? There's a define in makefile.unix. Something like -DCRYPTOPP_DISABLE_SSE2. Remove that. Else the SHA256_Transform will return the initstate. I had the same problem when switchting to 0.3.6.","Quote from: tcatm on August 08, 2010, 11:56:54 AM"],["t","This works for the 64bit builds, strange that it has no affect on the 32bit builds? Should it be disabled for 32bit builds as well?"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8257#msg8257","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"tcatm","d":1281293355,"b":[["t","I don't really know what it changes. I wonder why the define was made in the first place. The code should be able to determine whether it's running on a SSE2 CPU or not. I discovered it while comparing my 4xSSE2 hash function to the original one in 0.3.6 so it really means, that no 64bit build since 0.3.6 was able to generate any coins. Maybe satoshi can tell us why he put the define in the makefile. "]],"u":"https://bitcointalk.org/index.php?topic=753.msg8261#msg8261","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"ArtForz","d":1281313905,"b":[["t","Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.\nSame bug, output state on return from SHA256Transform always == initial state.\nSo... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?\nOh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.\nOh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8306#msg8306","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281316591,"b":[["q","Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.\nSame bug, output state on return from SHA256Transform always == initial state.\nSo... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?\nOh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.\nOh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.","Quote from: ArtForz on August 09, 2010, 12:31:45 AM"],["t","Not on 64bit linux, just 32bit and 64bit everything else in between (Linux/Windows)\n\nI didn't notice until I checked the generation dates against the release dates of the software.\n\nIf you don't strip the debug symbols the binary is 8 times it's normal size."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8309#msg8309","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lachesis","d":1281319551,"b":[["q","Just had a \"fun\" gdb session with the official 0.3.8 linux 64 bit binary on debian sid.\nSame bug, output state on return from SHA256Transform always == initial state.\nSo... did someone really generate a block running the official 0.3.8 64 bit linux binary (the one in bin/64)?\nOh, and from a quick glance at the svn changelog, that bug probably has been there since r118 = 0.3.6.\nOh, and who THE FUCK thought stripping the official binary was a good idea? I just wasted half an hour hunting down SHA256Transform in a disassembler.","Quote from: ArtForz on August 09, 2010, 12:31:45 AM"],["t","Nice work mate! Time to PM Satoshi.\n\nSent you ฿5.01 for your troubles."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8313#msg8313","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lfm","d":1281348283,"b":[["t","The 32 bit Linux build seems ok for those who don't care to try to build it themselves. It's only a few percent slower than the 64 when built right.\n\nI guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8342#msg8342","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"lachesis","d":1281368739,"b":[["q","I guess that flag was put in for old 32 bit machines that might not have sse2. Unfortunatly there is no such thing as a 64 bit x86_64 without sse2 so the conditional compilation produced an empty body which did exactly nothing.","Quote from: lfm on August 09, 2010, 10:04:43 AM"],["t","Yet another argument for cmake or similar."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8369#msg8369","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"satoshi","d":1281379841,"b":[["t","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.\n\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.\n\nShould we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.\n\nI will recompile the 64-bit part of the Linux 0.3.8 release."]],"u":"https://bitcointalk.org/index.php?topic=753.msg8388#msg8388","s":1,"n":331,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/331/","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"knightmb","d":1281380532,"b":[["q","I found that SSE2 only added a slight speedup, about 2%, which didn't seem worth the incompatibility. ","Quote from: satoshi on August 09, 2010, 06:50:41 PM"],["t","I do the see point because a non-SSE2 machine, the client would crash?"],["q","It 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.\n\nShould we enable SSE2 in all the makefiles?  It seems like we must in case someone compiles with 64-bit.\n\nI will recompile the 64-bit part of the Linux 0.3.8 release.","Quote"],["t","Depends on which is easier really. If you enable something that is going to break compatibility, the only people who will feel the pain are the non-technical users of the client. From their perspective, it just doesn't work for some reason.\n\nI think some builds notes would be better, example (If compiling on a 64bit system, be sure to do this part).\n\nHave one branch of source that cross-compiles across multiple operating systems is always tricky business.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8389#msg8389","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"dkaparis","d":1281382297,"b":[["q","Yet another argument for cmake or similar.","Quote from: lachesis on August 09, 2010, 03:45:39 PM"],["t","It's a fact <http://bitbucket.org/dkaparis/bitcoin-cmake/wiki/Home>.\n\nI intend to eventually sort out all building hassles and have a reliable build procedure across all win/unix 32/64-bit platform combinations.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8396#msg8396","sj":"Re: bitcoin generation broken in 0.3.8?"},{"f":"satoshi","d":1281386046,"b":[["t","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.\n\nhttp://bitcointalk.org/index.php?topic=765.0\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download"]],"u":"https://bitcointalk.org/index.php?topic=753.msg8417#msg8417","s":1,"n":334,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/334/"}]},{"id":"p171","k":"p","s":"bitcointalk","t":"What could be the transition plan to Y2038 compliant Bitcoin? (it already is)","u":"https://bitcointalk.org/index.php?topic=760","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/171/","m":[{"f":"throughput","d":1281356735,"b":[["t","Or will it suddenly die then?"]],"u":"https://bitcointalk.org/index.php?topic=760.msg8353#msg8353"},{"f":"throughput","d":1281357296,"b":[["t","As far as I can read C++, Bitcoin implementation stores timestamps as unsigned integers\nand block timestamp is a part of binary block format, of which a hash is computed.\nSince blocks are chained and the previous block is referenced in the current by it's hash,\nyou cannot simply recompile the client with 64bit timestamps.\nYou will need to recompute the whole chain, is that an option?\nOr we need to propose some transition plan to another binary block format.\n\nOr, I am wrong and everybody should relax.\n\nWhat do you think?"]],"u":"https://bitcointalk.org/index.php?topic=760.msg8354#msg8354","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"martin","d":1281357829,"b":[["t","I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8356#msg8356","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"throughput","d":1281360625,"b":[["q","I believe you would need a client which understood the old time format and the new one. At a certain block number all clients would switch over to the new timestamp system, old blocks would stay as they are, people with old versions of the software would suddenly find that they could not submit any transactions or create any blocks.","Quote from: martin on August 09, 2010, 12:43:49 PM"],["t","Great.\n\nEverybody, how do you think, is it time to bother on implementing that plan or we should wait for something to happen?"]],"u":"https://bitcointalk.org/index.php?topic=760.msg8360#msg8360","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"lachesis","d":1281368354,"b":[["t","Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8368#msg8368","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"lfm","d":1281375543,"b":[["q","Timestamps are already stored as uint64s. At least, that's how they're transmitted on the network.","Quote from: lachesis on August 09, 2010, 03:39:14 PM"],["t","main.cpp:                unsigned int nTime;\n\nin the block headers. Thats 32 bits if you don't know."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8379#msg8379","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"jgarzik","d":1281377903,"b":[["t","It seems to be a crazy mix...\n\nCWalletKey(main.h): 64-bit\nRest of main.h, including in-memory block/txn objects: 32-bit\nInternal main.cpp calculations: 64-bit\nNetwork(version): 64-bit\nNetwork(addr): 32-bit\nNetwork(getblock): 32-bit\nNetwork(submitorder): 32-bit\n\nAt a minimum, there are plenty of 32-bit time variables that clearly need changing to 64-bit."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8383#msg8383","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"MoonShadow","d":1281383889,"b":[["t","I'm not a programmer, but I have doubts that any of those 32 bit variables are subject to rolling over antime near 2038.  My understanding, however limited it may be, is that the timestamp of the blockchain is relative only to it's position within the chain, and not subject to any such limitations.  I'm sure that the two week difficulty calculations require an accurate count of seconds, but at worst, that would just throw off the calculations for the two weeks around the rollover in 2038.  And since there is a limit to just how much the difficulty may change in any two week period, even that isn't particularly crucial."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8409#msg8409","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"MoonShadow","d":1281384722,"b":[["q","The problem with the time stamps, is a unix time stamp as a 32 bit integer WILL overflow in 2038. I am a programmer, but you can find more info on it by googling unix time problem or 2038 Smiley","Quote from: davidonpda on August 09, 2010, 08:07:26 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8412#msg8412","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"},{"f":"satoshi","d":1281384806,"b":[["t","unsigned int is good until 2106.  Surely the network will have to be totally revamped at least once by then.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=760.msg8413#msg8413","s":1,"n":333,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/333/","sj":"Re: What could be the transition plan to Y2038 compliant Bitcoin?"}]},{"id":"p172","k":"p","s":"bitcointalk","t":"Version 0.3.8.1 update for Linux 64-bit","u":"https://bitcointalk.org/index.php?topic=765","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/172/","m":[{"f":"satoshi","d":1281383218,"b":[["t","When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build.  Version 0.3.8.1 is on SourceForge with the 64-bit binary updated.\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download\n\nFuture versions after 0.3.8 will probably require SSE2.  Anyone have Pentium 3 or older where this would be a problem?"]],"u":"https://bitcointalk.org/index.php?topic=765.msg8402#msg8402","s":1,"n":332,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/332/"},{"f":"NewLibertyStandard","d":1281385575,"b":[["t","The difficulty has gotten high enough that I wouldn't worry about dropping block generation support for old computers if it's hard to maintain compatibility. But the client should definitely provide some feedback explaining why the feature isn't available. Perhaps you could make a message pop up that explains why generating bitcoins is not supported on old hardware."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8415#msg8415"},{"f":"jgarzik","d":1281386774,"b":[["t","IMO, SSE should be required for generation, not simply to run the client."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8421#msg8421"},{"f":"satoshi","d":1281387306,"b":[["t","That's a good point, I believe you could run with generation off if you don't have SSE2.\n\nHow about add to the top of cryptopp/config.h:\n\n#if !defined(_M_X64) && !defined(__x86_64__)\n#define CRYPTOPP_DISABLE_SSE2  1\n#endif\n\nthat would disable SSE2 for 32-bit builds.  (at least with GCC or MSVC)"]],"u":"https://bitcointalk.org/index.php?topic=765.msg8422#msg8422","s":1,"n":335,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/335/"},{"f":"dkaparis","d":1281387422,"b":[["t","From what I understand, removing the offending define is required only for 64-bit builds and 64-bit architectures are already guaranteed to support SSE2 instructions. 32-bit builds can retain the flag and thus continue to disable SSE2 instructions and remain compatible with older computers."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8423#msg8423"},{"f":"dkaparis","d":1281387769,"b":[["q","That's a good point, I believe you could run with generation off if you don't have SSE2.\n\nHow about add to the top of cryptopp/config.h:\n\n#if !defined(_M_X64) && !defined(__x86_64__)\n#define CRYPTOPP_DISABLE_SSE2  1\n#endif\n\nthat would disable SSE2 for 32-bit builds.  (at least with GCC or MSVC)","Quote from: satoshi on August 09, 2010, 08:55:06 PM"],["t","Yes, but better have that specified in the makefile. That way anyone who doesn't care for old CPU's can compile with SSE2 support by removing the flag, without fiddling with the source.\n\nI can also add a CMake property for that in the CMake build."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8425#msg8425"},{"f":"knightmb","d":1281398545,"b":[["q","From what I understand, removing the offending define is required only for 64-bit builds and 64-bit architectures are already guaranteed to support SSE2 instructions. 32-bit builds can retain the flag and thus continue to disable SSE2 instructions and remain compatible with older computers.","Quote from: dkaparis on August 09, 2010, 08:57:02 PM"],["t","Older CPU that don't support SSE2 shouldn't be excluded from coin generation in my opinion. They can still serve a vital role in block generation; I have many machines that don't support the SSE2 enhancements, but still generate blocks all the time, even if they are only churning 300-400 khash/s"]],"u":"https://bitcointalk.org/index.php?topic=765.msg8447#msg8447"},{"f":"tcatm","d":1281398685,"b":[["t","I'm still running an old node without SSE2 @600khash/s. The algorithm works so I don't see why we should make SSE2 a requirement."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8448#msg8448"},{"f":"NewLibertyStandard","d":1281408347,"b":[["t","My impression of the difficulty was based on my broken client, haha! I've already generated a block tonight for the first time in such a long time. Having older computers generate coins doesn't seem as futile as it did earlier today. If you can keep the compatibility intact, I think it would be well worth it."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8461#msg8461"},{"f":"Ground Loop","d":1281411503,"b":[["t","Hah!  This sure helps explain a long-standing mystery.. why my 10,000 khash/sec Linux 64-bit machine is the only one that has never, in two weeks, generated a block. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=765.msg8464#msg8464"},{"f":"Ground Loop","d":1281412048,"b":[["t","Just to confirm -- this fix is in SVN 125?"]],"u":"https://bitcointalk.org/index.php?topic=765.msg8466#msg8466"},{"f":"mizerydearia","d":1281421108,"b":[["q","Hah!  This sure helps explain a long-standing mystery.. why my 10,000 khash/sec Linux 64-bit machine is the only one that has never, in two weeks, generated a block. Smiley","Quote from: Ground Loop on August 10, 2010, 03:38:23 AM"],["t","You're not the only one.  I haven't generated in over a month."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8485#msg8485"},{"f":"ArtForz","d":1281433069,"b":[["t","Fix is in svn r124, r125 added -maxconnections."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8505#msg8505"},{"f":"satoshi","d":1281483960,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=765.msg8628#msg8628","s":1,"n":338,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/338/"}]},{"id":"p173","k":"p","s":"bitcointalk","t":"Connection limits","u":"https://bitcointalk.org/index.php?topic=766","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/173/","m":[{"f":"satoshi","d":1281387525,"b":[["t","SVN rev 125:\n- Always make 8 outbound connections even if have 8 inbound\n- Limit outbound connections to one per a.b.?.? range\n- Switch -maxconnections=#\n\nI added the (currently undocumented) switch -maxconnections=#.  You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30.\n\nI haven't really tested -maxconnections much, could someone test it?"]],"u":"https://bitcointalk.org/index.php?topic=766.msg8424#msg8424","s":1,"n":336,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/336/"}]},{"id":"p174","k":"p","s":"bitcointalk","t":"Not a suggestion","u":"https://bitcointalk.org/index.php?topic=770","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/174/","m":[{"f":"Red","d":1281419145,"b":[["t","As some might have noticed, one of the things that bugs me about bitcoin is that the entire history of transactions is completely public. I totally understand the benefits of how this simplifies things and makes it easy for everyone to prove coins are valid.\n\nSo this is not a suggestion for a change to bitcoin. Rather it is a question about what could be possible, and what couldn't be possible.\n\nThe general question is, could the block list be/have been implemented in a way that didn't store the full transactions in the list? Specifically, *perhaps* it would be possible to store only hashes of the in-points, out-points in the block list. These would be time stamped (notarized) in the blocklist exactly as is being done now.\n\nThe major difference is that it would be the coin receiver's responsibility to store the full transaction. And perhaps he might have to store previous transactions (X) deep to show history.\n\nThen when he wanted to transfer the coins to the next party, he would create a transaction exactly as is being done now, except he would have to submit the antecedents to the transaction for validation as well. For validation, each antecedent of the in-points would be hashed and validated as existing in the block list. The in-points would be hashed and identified in the blocklist as not yet spent. Then the transaction would be validated as is currently done.\n\nIf everything validated correctly, the additional in/out-point hashes would be added to the block. This closes the transaction's in-points, and marks the new out-point hashes as unspent.\n\nOnce a node completes the block (by winning the hashing contest), he then broadcasts the block of hashes and the related transactions+plus antecedents to the other nodes for confirmation and acceptance.\n\nas a rough example:\n\n{block-9\n hash-a, hash-b, hash-c, hash-x\n}\n{block-12\n hash-a, hash-y, hash-c, hash-d\n}\n{block-17\n hash-b, hash-d, hash-e, hash-z, hash-f\n}\n\n{Transaction\n {in-points: hash-x, hash-y, hash-z}\n {address, signature and other transactions stuff}\n {out-points: hash-payed, hash-change\n}\n \n{generating-block\n hash-x, hash-y, hash-z, hash-payed, hash-change\n}\n\nSo basically, if the i/o-point hash existed twice in the block list, it has been spent. If it exists only once it has not been spent.\n\nSo in after block-17:\n  a, b, c & d are spent.\n  e, f, x, y, z are unspent.\n\nThe transaction spends x, y & z and creates hash-payed & hash-change, so the transaction is valid.\n\nAfter the generating-block:\n  a, b, c, d, x, y, & z are spent.\n  e, f, payed, change are unspent.\n\n====\nThe Goal:\n\nThe goal is to provide all the same security of the existing system, but to avoid creating a public graph of every transaction that is easily correlated. In this case, the hashes don't even have to associate in the block. The block could simply sort all hashes in ascending order.\n\nIn effect, I want to create real gold coins. I can give my coins to you, but everyone in the world doesn't know I did. You can give them to the next guy and prove they are pure gold coins, because you have the pedigree of the coins AND every generation in the pedigree was notarized in the public record.\n\n====\nThe Question:\n\nSatoshi showed that you can remove transactions from the block list through the Merkle tree structure, without compromising security. I guess my real question is:\n\n\"What is the earliest you can remove the transactions?\"\n\nYou could argue that nodes could remember everything anyway (the web never forgets). But if you structured the protocol so that new nodes would only receive a block list of hashes, they could only remember from this moment forward. That would give a little additional privacy. (Maybe)\n\n====\nAny thoughts? Is there an obvious way that people could cheat and get rich?"]],"u":"https://bitcointalk.org/index.php?topic=770.msg8477#msg8477"},{"f":"Insti","d":1281432854,"b":[["t","In your system, Rather than just getting transactions from the block chain  I just have to watch every transaction (which I'll see anyway) and log them to my secret server.\n\nYou're just advocating security through obscurity."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8504#msg8504"},{"f":"throughput","d":1281436139,"b":[["t","By the way, doesn't the idea of"],["q","the coin receiver's responsibility to store the full transaction. And perhaps he might have to store previous transactions (X) deep to show history.","Quote"],["t","make the limitation on the minimal value of transaction redundant?\nThus making micropayments use case more feasible."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8509#msg8509"},{"f":"Red","d":1281449376,"b":[["q","You're just advocating security through obscurity.","Quote from: Insti on August 10, 2010, 09:34:14 AM"],["t","I did mention that. I wouldn't count on this for monetary security. I would like the system to be equivalent to the current one.\n\nHowever, privacy obscurity is known to add value. Your neighbors, or the FBI could me watching everything you do all day long. But they probably aren't. If you happen to become \"of interest\", sure they could start watching you now and from this time forward.\n\nBut the most asked for additional legal powers seems to be, \"let me examine everyone's logs!\" (phone calls, cell towers, email connections, facebook connections, credit/debit card transactions, Google history, browser history.) The other systems are \"security though authority.\" Bitcoin doesn't have that.\n\n====\n\nBy the way, I'd rather not broadcast every transaction to every node either. But that is for another thread."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8533#msg8533"},{"f":"Red","d":1281450129,"b":[["t","By the way, this is the way most digital notary services work. You send them a hash of a signed document and they log it permanently. Then they create a hash chain like bitcoin does. They periodically publish the current hash chain value in a newspaper or other offline redundant record.\n\nYou don't have to send your private documents/transaction to the notary for them to be time stamped and recorded. The notary is just certifying that something that matched this hash existed at this point in time."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8534#msg8534"},{"f":"Insti","d":1281452776,"b":[["q","By the way, this is the way most digital notary services work. You send them a hash of a signed document and they log it permanently. Then they create a hash chain like bitcoin does. They periodically publish the current hash chain value in a newspaper or other offline redundant record.\n\nYou don't have to send your private documents/transaction to the notary for them to be time stamped and recorded. The notary is just certifying that something that matched this hash existed at this point in time.","Quote from: Red on August 10, 2010, 02:22:09 PM"],["t","You also don't have to prove to the notary that you have X BTC in your account to spend.\n\nAlthough I was recently reading about Zero-knowledge proofs <http://en.wikipedia.org/wiki/Zero-knowledge_proof> 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.\n\nI'm just worried what you want is theoretically impossible."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8542#msg8542"},{"f":"Red","d":1281461384,"b":[["q","Although I was recently reading about Zero-knowledge proofs <http://en.wikipedia.org/wiki/Zero-knowledge_proof>","Quote from: Insti on August 10, 2010, 03:06:16 PM"],["t","Interesting idea to revisit! Thanks. Hadn't thought of them in a while."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8554#msg8554"},{"f":"satoshi","d":1281485662,"b":[["t","This is a very interesting topic.  If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.\n\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.\n\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?\n\nIt's hard to think of how to apply zero-knowledge-proofs in this case.\n\nWe're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8637#msg8637","s":1,"n":339,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/339/","qt":["It's hard to think of how to apply zero-knowledge-proofs in this case."],"qc":["privacy","zero-knowledge"]},{"f":"Red","d":1281502730,"b":[["t","Satoshi: I know you know the first part of what I'm writing, but I want others to be able to follow and for you to correct any misconceptions I might have.\n\nI was looking at the current Merkle tree implementation trying to figure out when transactions could be removed without losing security.\n\nIn transaction graph terms, the transactions represent the nodes. The edges of the transaction graph are represented by the in-points which point to previous transactions using a BlockHash->TransHash->OutPoint kind of structure. It is the existence of an in-point that marks a previous out-point spent.\n\nSo for a transaction to be valid, you most show for every in-point in a transaction that BOTH, a previous out-point exists AND no previous in-point exists that references that out-point. So for every out-point, there are zero or one in-points referring to it. zero = unspent. one = spent.\n\nThat also means that no transaction can be culled from the block list, until both its out-points are spent. Otherwise coins will disappear.\nYou can however, delete all double-bound transactions as soon as you are confident the 2nd binding block will stick around. (earliest possibility)\n\nHowever, as you delete transactions and replace them with their tree hashes, you lose the graph structure present in the block list. In effect, all transactions undeleted from the block list have unspent value purely because they still exist. They can no longer prove validity by ancestry since that part of the graph was culled.\n\nWhich got me thinking, is there a way to prove validity if you never put the whole transactions into the graph to begin with?"],["q","The 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?","Quote from: satoshi on August 11, 2010, 12:14:22 AM"],["t","The key is to hash the transaction information as part of the out-point hash. So instead of creating a single transaction hash, you represent the transaction as two out-point hashes. (I originally considered an in-point/transaction/out-point structure using hashes, but that proved unnecessary.)\n\nOnly transaction validators need to know the bitcoin address associated with a recorded out-point hash. That comes from the submitted antecedent transaction for an in-point of the current transaction. The antecedent transaction and out-point is hashed and presumed BOTH valid and unspent if that hash appears one-and-only-one time in the block list.\n\nThe current transaction must be signed by the key for the address in the antecedent transactions of course. If this proves valid, two new out-point hashes are generated and inserted in the current block. The in-point hashes are marked spent by including them in the current block as well. (If a hash exists twice it is spent.) If you want to represent the transaction as a unit (and the currently visible transaction graph), the in-point hashes and out-point hashes could be grouped. However, this is not strictly necessary to prove validity."],["q","We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.","Quote from: satoshi on August 11, 2010, 12:14:22 AM"],["t","In this case we are trying to prove the presence of ONE matching hash and the absence of TWO matching hashes. It does require knowing all of them to prove.\n\nI think the prohibitions against double spending are as strong as in the current version.\n\n==== CAUTION! ====\n\nHowever, you have to consider the case where a node causes mischief by deliberate adding random \"canceling hashes\". In this case, the node wouldn't be able to gain access to the coins, as he has no signed transaction hashing to a valid unspent out-point hash. However, the current owner wouldn't be able to spend the coins either. The in-point would be presumed already spent.\n\nThat means the validation conditions are EXACTLY THE SAME as with the current implementation. All validating nodes must examine and validate all transactions represented in a block before accepting it and building on it.\n\nIf there exist any hashes in the proposed block that are not represented by valid transactions, the block must be rejected.\nThat is exactly the same as the current system's, if any transaction doesn't validate, the block must be rejected.\n\nI had hoped the condition to pass all transactions to all validators could be weakened but I can't see how (yet) without relying on trusted delegation.\n\n----------\n\nAn interesting feature is that this simplifies the validation process. All that needs to be done is to parse the block list (of hashes) once. As each hash is parsed you simply look it up in a hash-set. If it doesn't exist you add it. If it does exist you delete it. When you are done parsing the block list, you will have the minimal set of valid and unspent out-points. You might even be able to keep the whole set in memory. (at least for a while!)"]],"u":"https://bitcointalk.org/index.php?topic=770.msg8681#msg8681"},{"f":"Red","d":1281503604,"b":[["q","It's hard to think of how to apply zero-knowledge-proofs in this case.","Quote from: satoshi on August 11, 2010, 12:14:22 AM"],["t","It's hard for me too! :-) Was interesting to re-read though!\n\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.\n\nIt didn't. :-)"]],"u":"https://bitcointalk.org/index.php?topic=770.msg8682#msg8682"},{"f":"satoshi","d":1281560879,"b":[["t","Still thinking this idea through...\n\nThe only job the network needs to do is to tell whether a spend of an outpoint is the first or not.\n\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\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8798#msg8798","s":1,"n":342,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/342/"},{"f":"Red","d":1281575419,"b":[["q","Still thinking this idea through...","Quote from: satoshi on August 11, 2010, 09:07:59 PM"],["t","It's a bit of a brain twisting idea isn't it. :-)\n\nIt turns out the notion of a cancelable notarization generalizes nicely.\n\nFor example this system is not limited to bitcoin transactions. Since the signed contracts are kept externally, with additional validation/notarization rules, you could easily implement things like IOUs/claim checks.\n\nIf someone gave you $5, you could give him a $5 IOU. Its IOU hash would be notarized into the blocks list (of hashes). When you pay them back you could have them sign the IOU for confirmation. Then have the notary insert an IOU hash cancellation. Then no one could show back up with a copy of the IOU and demand double payment."],["q","I believe the clients would have to keep the entire history back to the original generated coins.  The fact that clients have to keep the entire history reduces the privacy benefit. ","Quote from: satoshi on August 11, 2010, 09:07:59 PM"],["t","I thought this too at first. But then I convinced myself otherwise.\n\nIt is really a matter of how much trust you place in the verifiers and the process of verification. People like the warm fuzzys that having every transaction available lets them trace the roots of their money back to its creation. However that is not required.\n\nIf you are confident in the process that validated the transactions during block creation (> 50% CPU agreement). And if you are confident the previous blocks can't be changed (you proved this). Then you only need to check that related out-points have not been spent. The security features remain in the block list and procedure, even if the transactions themselves are stored externally and the predecessors are not stored at all. You showed this yourself by proving old transactions can be deleted using the Merkle tree to maintain consistency."],["q","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.","Quote from: satoshi on August 11, 2010, 09:07:59 PM"],["t","True, privacy is directly related to observability. If there is a central party like a money changer, he can relate a lot of out-points. But if we get away from the notion that every coin must be traced back to creation, the observation horizons will be much closer.\n\n----\nIt's really weird getting used to the notion that this coin is valid simply because the process wouldn't let it be included otherwise. But really, that is exactly how bitcoin generation works. The transaction has no inputs, but everyone decides the out-point must be valid purely because otherwise, it wouldn't be in the block at all. :-)"]],"u":"https://bitcointalk.org/index.php?topic=770.msg8824#msg8824"},{"f":"satoshi","d":1281581216,"b":[["q","> Quote from: satoshi on August 11, 2010, 09:07:59 PM\n> I believe the clients would have to keep the entire history back to the original generated coins.  The fact that clients have to keep the entire history reduces the privacy benefit.  \n\nI thought this too at first. But then I convinced myself otherwise.","Quote from: Red on August 12, 2010, 01:10:19 AM"],["t","Are you back to talking about the existing Bitcoin system here?\n\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.\n\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.\n\nBut if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think."]],"u":"https://bitcointalk.org/index.php?topic=770.msg8836#msg8836","s":1,"n":347,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/347/"},{"f":"Red","d":1281587151,"b":[["q","> Quote from: Red on August 12, 2010, 01:10:19 AM\n> I thought this too at first. But then I convinced myself otherwise.\nAre you back to talking about the existing Bitcoin system here?","Quote from: satoshi on August 12, 2010, 02:46:56 AM"],["t","Yes, I am talking about the hypothetical system.\n\nThe way I proposed the system, each time a block gets generated every validating node must accept or reject that block by validating the transactions and confirming the hashes in the block. In effect, the same work that is being done with the current system, plus the out-point hash checks. Since the other validators were already competing to generate the block, they already have (at least most of) the transactions.\n\nAs with the current system, if the transactions don't validate (plus match included out-point hashes) the other nodes will reject the block. If the block doesn't get acceptance by at least 50% of the CPU power, it doesn't make the block list.\n\nSo the presence of the hashes in the block list, signifies that at least 50% of the existing validators at that time saw and validated all the containing transactions and out-point hashes.\n\nTherefore (barring hash crashes) if someone submits an antecedent transaction that matches an unspent out-point, it must be valid.\n\nThat antecedent's antecedent must have been valid as well, otherwise the antecedent would have been rejected. And so on and so on.\n\nFor that not to be the case, you have to postulate that there was a period in time where blocks weren't being validated against out-point hashes. But that's plausibly implausible with the CPU competition system."],["q","If 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.","Quote from: satoshi on August 12, 2010, 02:46:56 AM"],["t","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)\n\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.\n\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.\n\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.\n\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.\n\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\n---\nIn the proposed system, exactly the same things are true.\n\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.\n\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.\n\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\n=====\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.\n\nThe rest is just warm fuzzies.\n\n-- PS --\n\nI know this is too long and redundant, but I'm to tired to edit. :-)"]],"u":"https://bitcointalk.org/index.php?topic=770.msg8844#msg8844"},{"f":"satoshi","d":1281727727,"b":[["t","I'm not grasping your idea yet.  Does it hide any information from the public network?  What is the advantage?\n\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.\n\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.\n\nDoes it hide the bitcoin addresses?  Is that it?  OK, maybe now I see, if that's it.\n\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.\n\nThere's something here in the general area:\nhttp://www.users.zetnet.co.uk/hopwood/crypto/rh/\n\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.\n\nWhen paying to a bitcoin address, you would generate a new blinded key for each use.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=770.msg9074#msg9074","s":1,"n":356,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/356/"}]},{"id":"p175","k":"p","s":"bitcointalk","t":"Lost large number of bitcoins","u":"https://bitcointalk.org/index.php?topic=782","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/175/","m":[{"f":"Stone Man","d":1281482116,"b":[["t","Here are the details.\n\n1) Bought 9,000 BTC on one of the exchanges over time.\n2) Transferred them to my client running on a linux live CD distro of Debian.\n3) Backed up the wallet file to a flash drive.\n4) Sent 1 BTC to myself\n5) Closed client before any confirmations\n6) Shut down system (wiped system disk loaded into memory and therefore the ./bitcoin folder\n7) Loaded system back up\nCool Copied old wallet.dat file into ./bitcoin folder\n9) After some confirmations appeared the balance was 1 BTC and there was a transaction saying I spent 8,900 BTC to an address I did not recognize\n10) I read on the forum threads that people have had problems like this but it seemed only when they were trying to double-spend by sending coins to another address and reloading an old wallet file\n\nIs there anything I can do?\n\nI do have the address that the 8,900 were supposedly sent to but the old wallet file is gone for good.\n\nThanks,\nStone Man"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8620#msg8620"},{"f":"tcatm","d":1281482523,"b":[["t","Do you still have the wallet.dat that once \"contained\" the 9000 BTC? I might be able to help you."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8624#msg8624"},{"f":"Insti","d":1281482591,"b":[["t","It sounds like they are lost for good.\n\nSad\n\nLesson to other people: Remember you need to back your wallet up after every transaction!\n(The wallet metaphor is actually a bad one, because it makes problems like this more common than they should be.)\n\nEdit: (more explaination)\n\nWhen you do a transaction you always spend ALL of the coins in that address, part of the money goes to whoever you're paying, and there rest is returned to you an a new 'change' address. (This helps your anonymity as someone watching cannot tell which amount you spent and which amount you kept.)\n\nBefore transaction:\nAddress1: 9000\nAddress2: 0\n\nAfter transaction:\nAddress1: 0\nAddress2: 1\nAddress3: 8999\n\nIt sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.\n(Although the numbers in your story don't add up.)\nWhat were the Bitcoin addresses? (If we know these we can do some more in-depth block chain research)"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8625#msg8625"},{"f":"FreeMoney","d":1281484579,"b":[["t","Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?\n\nThat sucks."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8631#msg8631"},{"f":"Stone Man","d":1281485299,"b":[["q","Do you still have the wallet.dat that once \"contained\" the 9000 BTC? I might be able to help you.","Quote from: tcatm on August 10, 2010, 11:22:03 PM"],["t","Yes, I do.\n\nI saw on another thread that gavinanderson has made some tools to do more in depth research but did not know how to proceed.\n\nIf you could point me in the right direction I would greatly appreciate it."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8634#msg8634"},{"f":"Stone Man","d":1281486040,"b":[["q","It sounds like you have wallet.dat that contains the private keys for Address1 and Address2, but not Address3.\n(Although the numbers in your story don't add up.)\nWhat were the Bitcoin addresses? (If we know these we can do some more in-depth block chain research)","Quote from: Insti on August 10, 2010, 11:23:11 PM"],["t","Address1: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW\nAddress2: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW\nAddress3: 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8639#msg8639"},{"f":"Insti","d":1281488888,"b":[["t","I used bitcointools: http://github.com/gavinandresen/bitcointools\nTo look for your transactions in the block chain.\n\n(Here are the edited highlights)"],["c","python dbdump.py --search-blocks 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW\n\nBlock: 73261\nTime: Mon Aug  9 22:08:34\n734 tx in, 1 out\n['TxIn: .... <snipped. There were a lot> ']\n['TxOut: value: 9000.00 pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW Script: DUP HASH160 20:2d15...8e7a EQUALVERIFY CHECKSIG']\n\nBlock: 73272\nTime: Mon Aug  9 23:35:11 2010\n1 tx in, 2 out\n['TxIn: prev(8bda...4675:0) pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW sig: 72:3045...5301 65:04bc...2d42']\n['TxOut: value: 1.00 pubkey: 157PiPgqphedUvrco3mKU3Xoof7yzhj9pW Script: DUP HASH160 20:2d15...8e7a EQUALVERIFY CHECKSIG',\n 'TxOut: value: 8999.00 pubkey: 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg Script: DUP HASH160 20:3816...7437 EQUALVERIFY CHECK SIG']"],["t","So the transactions are definitly in there.\nYour only hope is to have the private key for the 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg address.\n\nIf you can get bitcointools working you can dump your wallet.dat using:"],["c","python dbdump.py --wallet"],["t","which will show you all the keys you know about in your wallet.\nBut you'll probably find that 167ZWTT8n6s4ya8cGjqNNQjDwDGY31vmHg is not in there Sad\n\nOn the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...\n\nEdit: I'd pasted the wrong block number and date for the first block. Fixed."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8644#msg8644"},{"f":"Stone Man","d":1281489043,"b":[["q","Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?\n\nThat sucks.","Quote from: FreeMoney on August 10, 2010, 11:56:19 PM"],["t","Actually, the sad part was I wasn't even testing the wallet backup when this happened. I was trying to watch when the network should have confirmed a payment to a website that takes bitcoins by paying myself 1 coin at about the same time. I never dreamed it could compromise my whole balance, especially since I was sending to myself."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8645#msg8645"},{"f":"FreeMoney","d":1281489542,"b":[["q","> Quote from: FreeMoney on August 10, 2010, 11:56:19 PM\n> Oh, man. Why did you send the 1? Were you just testing to see how the backup worked? Why with so many coins?\n>\n> That sucks.\n\nActually, the sad part was I wasn't even testing the wallet backup when this happened. I was trying to watch when the network should have confirmed a payment to a website that takes bitcoins by paying myself 1 coin at about the same time. I never dreamed it could compromise my whole balance, especially since I was sending to myself.","Quote from: Stone Man on August 11, 2010, 01:10:43 AM"],["t","Ugh, that's awful."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8646#msg8646"},{"f":"gridecon","d":1281491049,"b":[["t","Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.\n\nSorry about your loss, Stone Man."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8653#msg8653"},{"f":"sirius","d":1281492113,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8657#msg8657"},{"f":"BioMike","d":1281505102,"b":[["q","This has the implication that if you create a receiving address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins associated with that address are lost. If you lose your wallet entirely, all of your coins are lost and can never be recovered.","Quote from: Wiki page \"address\""],["q","On the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...","Quote from: Insti on August 11, 2010, 01:08:08 AM"],["t","So, they aren't lost forever? I guess it is more likely to generate the key of the address of someone else then from this specific address."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8684#msg8684"},{"f":"Insti","d":1281512312,"b":[["q","Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.","Quote from: gridecon on August 11, 2010, 01:44:09 AM"],["t","If you backup a spreadsheet, do you not expect to lose changes you made after that backup when you restore?\n\nThere are many types of transactions that will survive a wallet restore. This is one of the circumstances in which you will lose coins.\nIf he'd transferred all 9000 to the address he would still have them.\n\nI'm not trying to blame the user. I agree this is a problem that needs to be fixed.\n\nThis problem has been previously identified and there are plans to implement a fix, which has been talked about in the Privacy versus Safety: handling change <http://bitcointalk.org/index.php?topic=434.0> thread. But it has not been implemented yet.\n\nPerhaps a bounty is in order?"],["q","> Quote from: Insti on August 11, 2010, 01:08:08 AM\n> On the upside, (although it is probably of no consolation to you) there is now a decent bounty for anyone who can find an address collision...\nSo, they aren't lost forever? I guess it is more likely to generate the key of the address of someone else then from this specific address.","Quote from: BioMike on August 11, 2010, 05:38:22 AM"],["t","According to the theory, generating a address collision is so remotely unlikely as to never happen.\n(You're more likely to get struck by lightning, win all the worlds lotteries, and then get abducted by aliens on the same day.)\n\nHowever if you manage to find a weakness in a) the encryption method or  b) Bitcoins implementation of it. it may make it easy enough that you don't have to get abducted by aliens as well.\n\nSo they practically are lost forever."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8699#msg8699"},{"f":"caveden","d":1281513241,"b":[["q","Until this thread I was totally unaware of this behavior and risk. The usual behavior of a \"backup\" of a file is to preserve the contents of that file, and the intuitive understand of the wallet.dat file is that it \"contains\" the coins. I understand this is a case of the system behaving as designed, but the information that you need to backup your wallet after every transaction and each transaction makes your old wallet backups useless needs to be communicated much more clearly to users, I think. It also seems to me that it would be useful to add features for 'automatic backup' of a wallet after each transaction and easy support for multiple wallets - a \"savings account\" and a \"checking account\" so to speak.\n\nSorry about your loss, Stone Man.","Quote from: gridecon on August 11, 2010, 01:44:09 AM"],["t","+1\n\nThis shocked me actually. The poor guy didn't do anything stupid.\n\nAutomatic backups are really important after knowing that. And while that cannot be implemented, I think a sort of information message explained this in short words should be displayed every time someone sends coins. A popup saying something like, if I have T coins and I send S coins:\n\"S coins where sent to address X.\n(T-S) coins where sent to address Y, which belongs to you, in order to improve privacy. Please, realize that old backups you might have of your wallet will now be useless. You should make a new one.\"\n\nThis simple message would have avoided this awful lost. (of course, you may also add a \"Don't display this again\" check box)\n\nRegards"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8703#msg8703"},{"f":"QuantumMechanic","d":1281514219,"b":[["t","I think Satoshi proposed a protection against this in the following post:"],["q","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.\n\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.\n\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.","Quote from: satoshi on July 17, 2010, 04:27:39 PM"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8705#msg8705"},{"f":"caveden","d":1281515032,"b":[["t","This is indeed a good solution. Solves more than one problem actually."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8709#msg8709"},{"f":"skull88","d":1281523555,"b":[["t","Good to know this, I thougt I was save with my backups, but it could have happened to me to.\nStoneman didn't really do anything stupid.  Undecided"]],"u":"https://bitcointalk.org/index.php?topic=782.msg8732#msg8732"},{"f":"Ground Loop","d":1281547884,"b":[["t","News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.\n\nAs a countermeasure, I've manually split my wallet up into five new wallets of distributed value.  Now only one is at risk at any given time."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8768#msg8768"},{"f":"vess","d":1281548991,"b":[["t","A simple solution to this would be to store your wallet.dat on an encrypted partition that goes to an S3-based storage system, like Dropbox. They'll keep versions for you on update.\n\nThis would make a nice opt-in service that could be sold in the native client as a way to help fund research, by the way. The data storage needs are incredibly small."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8771#msg8771"},{"f":"lachesis","d":1281549440,"b":[["q","News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.","Quote from: Ground Loop on August 11, 2010, 05:31:24 PM"],["t","You were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1.\n\nI think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8772#msg8772"},{"f":"gridecon","d":1281559568,"b":[["q","> Quote from: Ground Loop on August 11, 2010, 05:31:24 PM\n> News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.\nYou were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1.\n\nI think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.","Quote from: lachesis on August 11, 2010, 05:57:20 PM"],["t","Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.\n\nIn other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8795#msg8795"},{"f":"FreeMoney","d":1281560202,"b":[["q","> Quote from: lachesis on August 11, 2010, 05:57:20 PM\n> > Quote from: Ground Loop on August 11, 2010, 05:31:24 PM\n> > News to me is that *all* your coins are at risk.  I thought it was just clumps of coins (previously received transactions) involved in the transaction, not my aggregate balance.  Yikes.\n> You were right before. The reason all of his coins were lost is that he first transfered all ฿9000 to himself, merging them into a single TxIn. If he had skipped that step and gone straight to sending himself ฿1, he would have only lost the smallest payment that he had previously received that was over ฿1.\n>\n> I think the client needs to communicate TxIns and TxOuts better to the user. I don't know how to do that without being confusing, but there are real privacy, safety, and security implications in which coins the client chooses to transfer.\n\nWait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to \"empty your wallet\" for EACH transaction. According to the description I read, when you send coins from address A in your wallet to address B externally, the transaction is actually done by sending ALL the coins out from address A, and the ones that aren't going to address B get sent to address C which is your own address - in other words, even if I'm only paying you a single bitcoin out of my 9000, I mail 1 bitcoin to you and 8999 to myself at a new address.\n\nIn other words (unless I'm confused), every transaction you make will result in your old, backed-up wallet addresses become emptied out.","Quote from: gridecon on August 11, 2010, 08:46:08 PM"],["t","My understanding is that it finds an address or addresses that have at least the number of coins you want to send and sends the change to a new address.\n\nSo if he had addresses with 1000, 2000, 2500, and 3500. It would have selected one of them (the lowest one?) and sent 1 away and sent all but 1 back to a new address of his. In this case he would not lose them all, just the remainder of what was in that one address.\n\nIt appears he had only 1 address with coins in it. This is probably because he got them all from the market in one go. If that is not the case, then I don't know why he would lose them all."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8796#msg8796"},{"f":"gridecon","d":1281560939,"b":[["t","Ok, re-reading carefully and checking the referenced thread, I finally understand this in detail. It's not that bitcoin \"empties your wallet\" at each transaction - it fully empties an address used to send coins. In this particular case, the user had previously sent themselves the 9000 coins in a lump, resulting in all those coins being held at a single address.\n\nSo far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is \"really important\" that information might be of value. "]],"u":"https://bitcointalk.org/index.php?topic=782.msg8799#msg8799"},{"f":"Insti","d":1281561901,"b":[["t","Your 'wallet' is more like your own personal bank\nIt contains many different accounts. (in Bitcoin these are called Addresses)\n\nEach Address has a balance associated with it, how much money is in it.\nYour Wallet balance is the sum of all the balances of the Addresses in your wallet.\n\nWhen you perform a transaction, it empties enough Addresses to make up the required output amount, but since it has to completely empty each Address there is often money left over in this case the 'change' is returned to you at a new Address.\n\nIn this case Stone Man did a transaction that sent all the money from 700+ addresses into a single address and therefore had a wallet containing only one Address that had any money in it.\n\nThat Address/Account was emptied as part of the 1BTC transaction and the 8999 change was returned to a new Address to which he lost the private key.\n\nIf he had not consolidated all his coins into one Address, he would have lost far fewer coins.\n\nI think the moral of the story might be: \"Don't put all your eggs in one basket\""],["q","So far as I can tell, there is no way from the GUI client to actually get at the information of what coins in your balance are held at what addresses? Given that the addresses are what is \"really important\" that information might be of value.","Quote from: gridecon on August 11, 2010, 09:08:59 PM"],["t","No you can't find out which addresses have which balances using the current GUI.\n\nI think it is \"very important\" information. \nI also think it is important to be able to chose which addresses are the source of transactions.\n\nThis is an example of why the wallet metaphor is bad."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8800#msg8800"},{"f":"satoshi","d":1281563211,"b":[["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.","Quote from: sirius-m on August 11, 2010, 02:01:53 AM"],["t","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)"],["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.","Quote from: gridecon on August 11, 2010, 08:46:08 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=782.msg8803#msg8803","s":1,"n":343,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/343/"}]},{"id":"p176","k":"p","s":"bitcointalk","t":"Compile error in SVN r127","u":"https://bitcointalk.org/index.php?topic=784","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/176/","m":[{"f":"jgarzik","d":1281489642,"b":[["t","Building r127 here, we see some missing casts, apparently:"],["c","rpc.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>"],["t","The following patch seems to solve the problem:"],["c","--- 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\n \n     if (GetTimeMillis() - nHPSTimerStart > 8000)\n-        return (int64)0;\n-    return (int64)dHashesPerSec;\n+        return (int64_t)0;\n+    return (int64_t)dHashesPerSec;\n }\n "]],"u":"https://bitcointalk.org/index.php?topic=784.msg8647#msg8647"},{"f":"satoshi","d":1281490950,"b":[["t","Updated SVN.  Thanks.\n\nThere's little hope of not repeatedly stumbling over that in the future.  It doesn't break the compile for me."]],"u":"https://bitcointalk.org/index.php?topic=784.msg8651#msg8651","s":1,"n":341,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/341/"}]},{"id":"p177","k":"p","s":"bitcointalk","t":"Where is the separate discussion devoted to possible Bitcoin weaknesses.","u":"https://bitcointalk.org/index.php?topic=788","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/177/","m":[{"f":"throughput","d":1281541542,"b":[["t","Just to be able to ask \"What if ...?\" and have all ideas collected in one place.\n\nFor example.\n\nIt seems, that a generating node does not need to receive all that transactions at all.\nThe only data it needs is the previous block hash.\nRight?\n\nNext.\nIt is possible to connect to almost every publicly accessible node, right?\nWe can collect their addresses and establish connections to almost all of them.\nAnd send them all the data we want.\nLike fake (or not so) transactions in huge volumes.\nWhat if it is possible to throttle their generating capability by forcing them to receive and verify\nvery large amounts of (possibly invalid) transactions (or perhaps another trash)?\n\nIf that is true, then we can lower the difficulty, right?\nJust do this for a long period of time.\nWhen it lowers to an acceptable for our supercomputer (botnet) value,\nwe may connect it to the network, but not directly.\nConnect it via special node, that does forward messages in a special way, to filter the trash data we are still flooding.\nSo, the supercomputer will receive the blocks and will participate in generation, the others will be flooded and will get\nonly a small portion of generated BTCs.\n\nThen, if we are not interested in generated BTCs, we may start generating a blockchain fork.\nImmediately after the difficulty drops, we start to generate alternative version of blockchain in a isolated environment.\nSince difficulty does not change immediately, we can try to outperform the rest of the network, while they are chewing our\ntrash data. Fast enough we present everybody with the longest chain, but then the difficulty raises back.\nBy doing this  it is possible to wipe our previous spend transactions, if they are made after the blockchain fork.\nSo, is it possible that we recover them and get back unspent transactions? And spend them again?\nHow will previous transactions incorporate into the new blockchain if they were \"respent\" in that manner?\n\nAnd then it can be repeated.\nIf I'm wrong, just say: \"you are wrong\".\nBut you may also give me a hint why."]],"u":"https://bitcointalk.org/index.php?topic=788.msg8757#msg8757"},{"f":"Gavin Andresen","d":1281543056,"b":[["t","Bitcoin's p2p network is subject to various kinds of denial of service attacks.\n\nThere, I said it.\n\nDo you have constructive suggestions for how to fix it, or are you the kind of person who just enjoys breaking things because you can?\n\nIdeas that have been bouncing around my head that may or may not work:\n\n+ have clients tell each other how many transactions per unit of time they're willing to accept.  If a client sends you more (within some fuzz factor), drop it.  Compile in a default that's based on estimated number of transactions for a typical user and estimate on the number of current users.\n\n+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).\n\nThis is an active area of research; see, for example: http://scholar.google.com/scholar?q=ddos+attacks+by+subverting+membership"]],"u":"https://bitcointalk.org/index.php?topic=788.msg8761#msg8761"},{"f":"Red","d":1281543431,"b":[["t","Knightmb said increasing connections and bandwidth had little effect on khash speed.\n\nGame over. Try again?"]],"u":"https://bitcointalk.org/index.php?topic=788.msg8762#msg8762"},{"f":"Gavin Andresen","d":1281544807,"b":[["q","> Quote from: gavinandresen on August 11, 2010, 04:10:56 PM\n> + require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).\n\nIsn't that a brilliant idea? Like hashcash?\n\nYou would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power.","Quote from: davidonpda on August 11, 2010, 04:19:43 PM"],["t","I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea!  Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)..."]],"u":"https://bitcointalk.org/index.php?topic=788.msg8765#msg8765"},{"f":"lachesis","d":1281550032,"b":[["q","> Quote from: davidonpda on August 11, 2010, 04:19:43 PM\n> > Quote from: gavinandresen on August 11, 2010, 04:10:56 PM\n> > + require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).\n>\n> Isn't that a brilliant idea? Like hashcash?\n>\n> You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power.\n\nI was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea!  Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)...","Quote from: gavinandresen on August 11, 2010, 04:40:07 PM"],["t","Unfortunately, as simple to implement as it is, in order to be effective it would have to be a breaking change.\n\nOlder clients won't send the proof of work because they don't know to. So an attacker could just claim that their client version was, say, 308 - too old for the protection. So your node would have to choose between dropping support for older clients and being secure against this sort of attack or continuing to support older clients and being insecure against this.\n\nI'm not saying we shouldn't do it, but I think we ought to get a list of important breaking changes together before we make one. Users really don't like being told that they have to upgrade every other day.\n\nAlso, I don't know how the message relay protocol works. I guess each node could just relay that Tx with the same nonce and hash that the first one gave it. There's no danger of \"reusing\" a hash since a duplicate transaction is by nature invalid (although it could still harass the nodes).\n\nSome detection and blacklisting code would be useful too. If an IP sends you a certain number of invalid transactions within a certain time, disconnect and refuse to accept connections from them for a certain period of time. If they do it again upon reconnecting, block them for longer... etc."]],"u":"https://bitcointalk.org/index.php?topic=788.msg8776#msg8776"},{"f":"Red","d":1281552385,"b":[["q","+ have clients tell each other how many transactions per unit of time they're willing to accept.  If a client sends you more (within some fuzz factor), drop it.  Compile in a default that's based on estimated number of transactions for a typical user and estimate on the number of current users.\n\n+ require some proof-of-work as part of the client-to-client connection process (helps prevent 'Sybil' attacks).","Quote from: gavinandresen on August 11, 2010, 04:10:56 PM"],["t","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.\n\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.\n\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.\n\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.\n\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\n----ps----\n\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.\n "]],"u":"https://bitcointalk.org/index.php?topic=788.msg8782#msg8782"},{"f":"satoshi","d":1281566425,"b":[["t","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.\n\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.\n\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."],["q","Bitcoin's p2p network is subject to various kinds of denial of service attacks.\n\nThere, I said it.","Quote from: gavinandresen on August 11, 2010, 04:10:56 PM"],["t","+1\n\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."]],"u":"https://bitcointalk.org/index.php?topic=788.msg8804#msg8804","s":1,"n":344,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/344/"}]},{"id":"p178","k":"p","s":"bitcointalk","t":"BSD detection","u":"https://bitcointalk.org/index.php?topic=790","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/178/","m":[{"f":"dkaparis","d":1281567616,"b":[["t","There is this piece of code in headers.h:\n\n#ifdef __WXMAC_OSX__\n#define __WXMAC__ 1\n#define __WXOSX__ 1\n#define __BSD__ 1\n#endif\n#endif\n\nIn my testing it's not caught on FreeBSD 8.1\n\nI propose it be changed to:\n\n#if (defined(__unix__) || defined(unix)) && !defined(USG)\n#include <sys/param.h>\n#endif\n\nAnd then checks for BSD should be\n#ifdef BSD\nThis is the recommended way of detecting BSD in the FreeBSD Porter's Handbook <http://www.freebsd.org/doc/en/books/porters-handbook/porting-versions.html>.\n\nThis change is already done in my CMake tree."]],"u":"https://bitcointalk.org/index.php?topic=790.msg8807#msg8807"},{"f":"satoshi","d":1281571326,"b":[["q","There is this piece of code in headers.h:\n\n#ifdef __WXMAC_OSX__\n#define __WXMAC__ 1\n#define __WXOSX__ 1\n#define __BSD__ 1\n#endif\n#endif","Quote from: dkaparis on August 11, 2010, 11:00:16 PM"],["t","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__."],["q","#if (defined(__unix__) || defined(unix)) && !defined(USG)\n#include <sys/param.h>\n#endif","Quote"],["t","Will that definitely cause BSD to be defined on Mac?"]],"u":"https://bitcointalk.org/index.php?topic=790.msg8814#msg8814","s":1,"n":346,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/346/"},{"f":"dkaparis","d":1281601477,"b":[["q","> Quote\n> #if (defined(__unix__) || defined(unix)) && !defined(USG)\n> #include <sys/param.h>\n> #endif\nWill that definitely cause BSD to be defined on Mac?","Quote from: satoshi on August 12, 2010, 12:02:06 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=790.msg8861#msg8861"},{"f":"satoshi","d":1281647660,"b":[["t","This is in SVN rev 130.  Check that it compiles right."],["c","#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"]],"u":"https://bitcointalk.org/index.php?topic=790.msg8919#msg8919","s":1,"n":348,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/348/"}]},{"id":"p179","k":"p","s":"bitcointalk","t":"Bugfixes in SVN rev 130","u":"https://bitcointalk.org/index.php?topic=795","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/179/","m":[{"f":"satoshi","d":1281648031,"b":[["t","Misc bugfixes in rev 130:\n\nfix -datadir with relative path\nautostart is now off by default except on windows\nfix occasional \"vector iterator not dereferencable\" assertion when compiled with msvc\nfix readlink compile warning on linux build\nuse sys/param.h and BSD define instead of __BSD__\n-paytxfee switch, e.g. -paytxfee=0.01"]],"u":"https://bitcointalk.org/index.php?topic=795.msg8920#msg8920","s":1,"n":349,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/349/"},{"f":"jgarzik","d":1281656352,"b":[["q","-paytxfee switch, e.g. -paytxfee=0.01","Quote from: satoshi on August 12, 2010, 09:20:31 PM"],["t","So, -paytxfee sets nTransactionFee.\n\nCan someone explain how nTransactionFee causes a client to behave?\n\nAnd more specifically, what happens when node A sets 1000.0 and all other nodes use 0.01?"]],"u":"https://bitcointalk.org/index.php?topic=795.msg8941#msg8941"},{"f":"aceat64","d":1281667336,"b":[["q","> Quote from: satoshi on August 12, 2010, 09:20:31 PM\n> -paytxfee switch, e.g. -paytxfee=0.01\n\nSo, -paytxfee sets nTransactionFee.\n\nCan someone explain how nTransactionFee causes a client to behave?\n\nAnd more specifically, what happens when node A sets 1000.0 and all other nodes use 0.01?","Quote from: jgarzik on August 12, 2010, 11:39:12 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=795.msg8957#msg8957"},{"f":"satoshi","d":1281669323,"b":[["t","No, that's not what it is.\n\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.\n\nIt's just there in case we need it.  It probably won't be needed, and it can be explained more if we do."]],"u":"https://bitcointalk.org/index.php?topic=795.msg8960#msg8960","s":1,"n":353,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/353/"}]},{"id":"p180","k":"p","s":"bitcointalk","t":"Version 0.3.9 rc1, please test","u":"https://bitcointalk.org/index.php?topic=806","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/180/","m":[{"f":"satoshi","d":1281721200,"b":[["t","Here's a test build if you'd like to help test before 0.3.9 is released.\n(or if you'd rather get upgrading out of the way now instead of waiting)\n\nDownloads:  (binaries only)\nhttp://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip\n(http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)\n\nSHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip\nSHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz\n\nEdit:\nLinux please test rc2 instead.  This adds a -4way switch for tcatm's 4-way SSE2.  This will only be for Linux:\nhttp://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz\n\nSHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz\n\nPlease report back your results\nhttp://bitcointalk.org/index.php?topic=820"]],"u":"https://bitcointalk.org/index.php?topic=806.msg9046#msg9046","s":1,"n":355,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/355/"},{"f":"lachesis","d":1281732554,"b":[["t","What's new? Do we have an official changelog yet?"]],"u":"https://bitcointalk.org/index.php?topic=806.msg9100#msg9100"},{"f":"Tilka","d":1281881480,"b":[["q","What's new? Do we have an official changelog yet?","Quote from: lachesis on August 13, 2010, 08:49:14 PM"],["t","Unfortunately we don't have an official changelog yet (except for the SVN revision descriptions).\n\nHere is my unofficial changelog:\n\n• fix: makefile.osx\n\n• change: enable SSE2 in 64 bit builds\n\n• change: connection rules\n- always make 8 outbound connections\n- only one connection per a.b.*.* range\n\n• add: switch \"-maxconnections=#\" (discussed here <http://bitcointalk.org/index.php?topic=766.0>)\n\n• change: JSON-RPC API prints floats with 8 decimal places\n\n• change: \"bitcoind help <command>\" instead of \"bitcoind <command> -?\" (based on a patch by jgarzik <http://bitcointalk.org/index.php?topic=637.0>)\n\n• add: JSON-RPC \"gethashespersec\" (based on a patch by lachesis <http://bitcointalk.org/index.php?topic=609.0>)\n\n• add: \"version\" and \"hashespersec\" fields in JSON-RPC \"getinfo\"\n\n• fix: \"-datadir=<path>\" with relative path (bug described here <http://bitcointalk.org/index.php?topic=601.0>)\n\n• change: autostart disabled by default except on Windows (requested here <http://bitcointalk.org/index.php?topic=720.0>)\n\n• fix: occasional \"vector iterator not dereferencable\" assertion when compiled with msvc\n\n• fix: readlink compile warning on Linux build\n\n• fix: BSD detection (bug described here <http://bitcointalk.org/index.php?topic=790.0>)\n\n• add: \"-paytxfee=#\" switch (explained here <http://bitcointalk.org/index.php?topic=795.0>)\n\nPlease tell me if you know of any other forum threads discussing the bugs/changes so I can add them to the list."]],"u":"https://bitcointalk.org/index.php?topic=806.msg9439#msg9439"},{"f":"lachesis","d":1281893577,"b":[["q","Unfortunately we don't have an official changelog yet (except for the SVN revision descriptions).\n...\nPlease tell me if you know of any other forum threads discussing the bugs/changes so I can add them to the list.","Quote from: Tilka on August 15, 2010, 02:11:20 PM"],["t","That's a great changelog. I sent you ฿2 for your trouble. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=806.msg9464#msg9464"},{"f":"jgarzik","d":1281894387,"b":[["t","Don't wanna take credit where it's not due Smiley\n\nthe hashes/sec patch was from lachesis, and the extended-help might have been based on my idea, but the code was somewhat different."]],"u":"https://bitcointalk.org/index.php?topic=806.msg9467#msg9467"},{"f":"satoshi","d":1281895901,"b":[["q","the extended-help might have been based on my idea, but the code was somewhat different.","Quote from: jgarzik on August 15, 2010, 05:46:27 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=806.msg9475#msg9475","s":1,"n":365,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/365/"}]},{"id":"p181","k":"p","s":"bitcointalk","t":"Proposed change to sendtoaddress API call","u":"https://bitcointalk.org/index.php?topic=807","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/181/","m":[{"f":"Gavin Andresen","d":1281727703,"b":[["t","I'm proposing one small change to Bitcoin's JSON-RPC api:  return a transaction ID when Bitcoins are successfully sent.\n\nWhy?  Because I want to keep a complete audit trail for any coins going into or coming out of my application's wallet; I want to keep track of the particular transactions in the bitcoin network that correspond to actions my application takes.  The alternative is to call sendtoaddress and then call listtransactions, but that won't work properly if two similar transactions (same amount to same address) occur at about the same time.\n\nSo I propose doing the simplest thing possible: modify the JSON-RPC sendtoaddress call so it returns the string 'sent:' followed by the 256-bit-hexadecimal transactions id.\n\nThis could break any applications that look for exactly the string 'sent' (which is what sendtoaddress does now).  The fix would be to modify the apps to see if the string began with 'sent'.\n\nAlternatives I thought about but think I don't like:\n + make it a new api call so old apps do not break (sendtoaddress2 ? yuck)\n + return just the transaction id on successful send instead of 'sent:...'\n + return an array with more information (maybe [ \"tx_id\": \"...\", \"fee\" : 0.0 ] )\n\nComments/criticisms?"]],"u":"https://bitcointalk.org/index.php?topic=807.msg9073#msg9073"},{"f":"jgarzik","d":1281728420,"b":[["t","100% agreed with your suggestion, about the need for txn_id association.\n\nHowever, it seems better to avoid API breakage, because this API is so heavily used.  It is almost guaranteed that anyone automating bitcoins is using sendtoaddress.\n\nEither create a \"send2\" RPC call, or add an \"[extended-JSON=0]\" parameter to the existing sendtoaddress RPC call, or something similar that preserves existing application data flows."]],"u":"https://bitcointalk.org/index.php?topic=807.msg9075#msg9075"},{"f":"knightmb","d":1281728474,"b":[["t","Just add a flag (like true/false) to the function with the default \"false\" so it works with older uses of the function call.\n\nLike\n\nsendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return transaction ID, default false]\n\nSo\nsendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 \"Blah Comment\" \"Blah From\" true\nreturns\nsent XYZ....\n\nBut\nsendtoaddress 1FtDzyajiHKa9QbXiNxqztB 1.00 \"Blah Comment\" \"Blah From\"\nreturns\nsent\nAlso without having to break compatibility.\n\nI think it would be a handy addition."]],"u":"https://bitcointalk.org/index.php?topic=807.msg9076#msg9076"},{"f":"Gavin Andresen","d":1281729677,"b":[["t","RE: adding a flag:  great idea!\n\nIf you set the flag, I don't see any reason to prepend 'sent' to the transaction ID; better to just return the transaction ID on successful send.\n\nPatches:"],["c","diff --git a/rpc.cpp b/rpc.cpp\nindex 920fe90..8714b7e 100644\n--- a/rpc.cpp\n+++ b/rpc.cpp\n@@ -342,10 +342,11 @@ Value getaddressesbylabel(const Array& params, bool fHelp)\n \n Value sendtoaddress(const Array& params, bool fHelp)\n {\n-    if (fHelp || params.size() < 2 || params.size() > 4)\n+    if (fHelp || params.size() < 2 || params.size() > 5)\n         throw runtime_error(\n-            \"sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to]\"\n-            \"<amount> is a real and is rounded to the nearest 0.01\");\n+            \"sendtoaddress <bitcoinaddress> <amount> [comment] [comment-to] [return-tx-id-flag]\"\n+            \"<amount> is a real and is rounded to the nearest 0.01\"\n+            \"returns string 'sent' if return-tx-id-flag is false (default), otherwise returns transaction id.\");\n \n     string strAddress = params[0].get_str();\n \n@@ -361,9 +362,15 @@ Value sendtoaddress(const Array& params, bool fHelp)\n     if (params.size() > 3 && params[3].type() != null_type && !params[3].get_str().empty())\n         wtx.mapValue[\"to\"]      = params[3].get_str();\n \n+    bool fReturnTxID = false;\n+    if (params.size() > 4)\n+        fReturnTxID = params[4].get_bool();\n+\n     string strError = SendMoneyToBitcoinAddress(strAddress, nAmount, wtx);\n     if (strError != \"\")\n         throw runtime_error(strError);\n+    if (fReturnTxID)\n+        return wtx.GetHash().ToString();\n     return \"sent\";\n }\n \n@@ -1103,6 +1110,7 @@ int CommandLineRPC(int argc, char *argv[])\n         if (strMethod == \"setgenerate\"            && n > 0) ConvertTo<bool>(params[0]);\n         if (strMethod == \"setgenerate\"            && n > 1) ConvertTo<boost::int64_t>(params[1]);\n         if (strMethod == \"sendtoaddress\"          && n > 1) ConvertTo<double>(params[1]);\n+        if (strMethod == \"sendtoaddress\"          && n > 4) ConvertTo<bool>(params[4]);\n         if (strMethod == \"listtransactions\"       && n > 0) ConvertTo<boost::int64_t>(params[0]);\n         if (strMethod == \"listtransactions\"       && n > 1) ConvertTo<bool>(params[1]);\n         if (strMethod == \"getamountreceived\"      && n > 1) ConvertTo<boost::int64_t>(params[1]); // deprecated"]],"u":"https://bitcointalk.org/index.php?topic=807.msg9086#msg9086"},{"f":"jgarzik","d":1281730410,"b":[["t","What happens when we desire to return additional information, beyond tx-id?\n\nFor the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things."]],"u":"https://bitcointalk.org/index.php?topic=807.msg9090#msg9090"},{"f":"Gavin Andresen","d":1281731166,"b":[["q","What happens when we desire to return additional information, beyond tx-id?\n\nFor the sake of future compatibility, it seems like the flag should present a choice between returning (a) just the current 'sent', or (b) a JSON map containing tx-id, and perhaps other things.","Quote from: jgarzik on August 13, 2010, 08:13:30 PM"],["t","A 'gettransaction tx_id' API call is on my short list.\n\nWhat do other folks think; should sendtoaddress .... true   return just the tx_id, and you have to make another API call to get details if you need them?\nOr should it return an Array?"]],"u":"https://bitcointalk.org/index.php?topic=807.msg9096#msg9096"},{"f":"jgarzik","d":1281740474,"b":[["t","Do you need 'gettransaction', given the existence of 'getblock'?"]],"u":"https://bitcointalk.org/index.php?topic=807.msg9126#msg9126"},{"f":"satoshi","d":1281742754,"b":[["t","It's too soon to start junking up the API for backward compatibility at all costs.\n\nJust return \"<txid>\"."]],"u":"https://bitcointalk.org/index.php?topic=807.msg9134#msg9134","s":1,"n":357,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/357/"}]},{"id":"p182","k":"p","s":"bitcointalk","t":"Potential disaster scenario","u":"https://bitcointalk.org/index.php?topic=813","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/182/","m":[{"f":"gebler","d":1281789834,"b":[["t","The difficulty for generating bitcoins is periodically adjusted using a method\nthat has worked well this far.  However, I am afraid there are plausible\nscenarios where the current method would misbehave quite spectacularly.\n\nOne scenario goes like this:\n\n1) As bitcoins become more known, competition among minters continues to\n    increase, with corresponding increases in difficulty.  The increased\n    difficulty will eventually make bitcoin minting clearly unprofitable for\n    those who do not have access to good energy prices and cheap access to an\n    energy-efficient HW/SW combination.\n\n2) Some bitcoin users may continue to mint bitcoins even though it is not\n    profitable for them.  This could be due to ideology, the fun factor, or\n    just ignorance.  But it is quite plausible that the vast majority of\n    bitcoins will be minted by those who profit from it.  Let's say that 99% of\n    all bitcoins are eventually minted by for-profit-minters.\n\n3) The competition among for-profit-minters will drive profit margins down, to\n    the point where it is profitable to continue minting, but barely so.  Let's\n    say that the typical profit margin during one difficulty adjustment period\n    (2016 blocks) is 10%.\n\n4) Since bitcoin minting is a decentralized uncoordinated process, we can\n    expect random fluctuations in bitcoin minting activity.  This does not\n    affect the difficulty during a specific 2016-block period, so the minting\n    activity can e.g. increase by 20% during a period without making minting\n    unprofitable within that period.\n\nGiven the above assumptions, we now have a disaster at hand at the next\ndifficulty adjustment.  As bitcoin production was 20% more than target,\ndifficulty is adjusted upwards by 20%.  But the profit margin was only 10%, so\nfor-profit-minters would now lose money if they continued minting.  They will\ntherefore stop minting, and as they make up 99% of the minting capacity,\ngenerating the next 2016 blocks will take 100 times longer than normal.\nEverything that depends on block generation will slow to a crawl, and this\nslowness will persist for a very long time, since the next 2016 blocks will\ntake 100 times longer to generate (almost 4 years rather than two weeks).\n\nNow, if this was to happen, I guess a new client could be released that resets\nthe difficulty to some sensible number and started using a better algorithm\nfor difficulty adjustment.  But it would be much better to do it proactively\nbefore it becomes a problem (perhaps with a predetermined \"flag day\"\nactivating the new algorithm at a certain time in the future, giving the new\nclient a chance to propagate).\n\nA simple(?) modification of the algorithm would be to apply the adjustment\nafter a certain amount of time rather than at a certain block number.  The\nswitch could still be synced to take effect for the next block, so time\nsynchronization between clients would not need to be super exact to have the\nvast majority of them agree on when the new difficulty is to be applied.\n\nAlso, the difficulty adjustment should probably take into account the\nadjustments of the number of bitcoins minted per event (now 50, halved every 4\nyears).  Halving the number of bitcoins generated each time is equivalent to\ndoubling the difficulty as far as profitability is concerned, and such a\ndrastical drop in profitability is unnecessary if it can be avoided easily.\nI'm not sure if the current adjustment algorithm already takes that into\naccount somehow, but I couldn't see any obvious adjustment for it in the\nsource code."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9186#msg9186"},{"f":"NewLibertyStandard","d":1281794484,"b":[["t","I think there is a limit to the amount that the difficulty can increase at each step.\n\nThe more the bitcoin network grows, the less likely it is to have large spikes in difficulty. The likelihood of a jump of that magnitude from a single entity is very unlikely. If that kind of jump does occur, it will more likely be from a large interested demographic discovering Bitcoin all at once, such as if it was featured in a major magazine. Bitcoin will cope with such increases and subsequent decreases just fine.\n\nIn the very unlikely event of blocks taking hours or days to be completed, the transaction fee feature would quickly be added back to the program and people would start including a ฿0.01 transaction fee with each transaction they sent. The mega-minter would have a modified client which would monitor how many bitcoins in transaction fees were available and once it was enough to be profitable, they would turn on their mega-hash-cruncher and you'd get your block within ten minutes on average.\n\nIt doesn't much matter whether minting is profitable or not. In not too many years, total transaction fees per block will be higher than new bitcoins per block."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9195#msg9195"},{"f":"gebler","d":1281798884,"b":[["q","I think there is a limit to the amount that the difficulty can increase at each step.\n\nThe more the bitcoin network grows, the less likely it is to have large spikes in difficulty. The likelihood of a jump of that magnitude from a single entity is very unlikely. If that kind of jump does occur, it will more likely be from a large interested demographic discovering Bitcoin all at once, such as if it was featured in a major magazine. Bitcoin will cope with such increases and subsequent decreases just fine.","Quote from: NewLibertyStandard on August 14, 2010, 02:01:24 PM"],["t","There is a limit to the difficulty adjustment, but for upward adjustments it is 300% (factor of 4 between new and old) rather than the 20% in my scenario, so it wouldn't help. \n\nI would argue that a 20% difficulty adjustment is in no sense extreme - the last five adjustments were 44%, 35%, 300%, 93%, and 21%.  This hasn't been a problem up to now, but obviously not because a 20% adjustment would be too extreme, but more likely because it hasn't been enough to make minting unprofitable (or otherwise uninteresting).  My scenario does not assume that a single entity is responsible for a jump in difficulty - it is just as problematic if e.g. publicity makes minting 20% more popular at a time when the profit margin is less than 20%.  The extreme effects come from the proportion of minters who are unwilling to continue minting at a loss.  If this proportion is large while the profit margin is low, the system becomes very unstable.\n\nAlso, if I am right about the 4-year halving of bitcoins generated (i.e. that it doesn't affect the difficulty adjustment) such events alone would be equivalent to a 100% upward difficulty adjustment.  And it seems very reasonable to assume that most minters will have a lower profit margin than 100% in the future."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9209#msg9209"},{"f":"NewLibertyStandard","d":1281800133,"b":[["t","It's already not interesting to mint bitcoins. Also, for the average person, I think they're hardly profitable. Even if the average person can sell bitcoins at slightly above production costs, it's difficult to invest more than pocket change worth of electricity per day. Profit on pocket change in exchange for hearing your fan running full blast all day everyday is not very interesting to the average person. If there is a sudden spike in new users, they're not going to all show up at the beginning of a difficulty cycle, stay until the cycle until it's over and then all leave. Most will not last a week generating bitcoins on our already boring to generate network, so as all these flaky new users quit generating, we'll have half a week without them and half a week with them. Those that do stick around will help adjust difficulty back to what it should be.\n\nAnd like I said about the worst case scenario, if we're going on a week without generating a block, then we start including some transaction fees and somebody from the community rents a cloud to get to the next adjustment.\n\nIn short, I don't think there's much anything to worry about. But you're welcome to go on worrying about it. Wink"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9211#msg9211"},{"f":"lachesis","d":1281807525,"b":[["t","The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.\n\nIn addition, as Bitcoin grows, people will develop dedicated hardware that maximizes the khash/dollar spent. In addition, people will tune the software in more and more precise ways to squeeze slightly more khash/second out of the same hardware. The people who invest a large fixed cost to do that will receive a correspondingly lower variable cost per Bitcoin minted in return, so they'll be able to mint at price levels that would drive others out.\n\nFinally, at the point that this becomes an issue, everyone will be including transaction fees with their transactions to incentivize minting."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9223#msg9223"},{"f":"gebler","d":1281810863,"b":[["q","It's already not interesting to mint bitcoins. Also, for the average person, I think they're hardly profitable.","Quote from: NewLibertyStandard on August 14, 2010, 03:35:33 PM"],["t","Well, there might be an important psychological difference between being marginally profitable and by clearly losing money.  The range of efficiency in bitcoin minting is such that some people may be profitable at a difficulty level where most are clearly losing money.  If this happens, I suspect the share of nonprofit minting activity would dwindle quite quickly.  We are then in the unstable situation I warned about."],["q","In short, I don't think there's much anything to worry about. But you're welcome to go on worrying about it.  Wink","Quote from: NewLibertyStandard on August 14, 2010, 03:35:33 PM"],["t","Of course I'm worrying - my entire bitcoin fortune (150 BC) is at stake here!  Wink"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9232#msg9232"},{"f":"FreeMoney","d":1281812006,"b":[["t","You ignore all kinds of things that help solve this.\n\nTransaction fees will increase if blocks come more slowly because it will be more desirable to get your transactions in the next block.\n\nIf an entity calculates that (fixed costs + variable costs < revenue) adjusted for risk the it is pretty unlikely that they will hit the (variable costs > revenue) easily at all and that is the shutdown point.\n\nThese minters will usually have and use bitcoins themselves. This gives two extra incentives to operate at a \"loss\". They want their transactions to get processed, and they want to maintain bitcoin as a working system."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9235#msg9235"},{"f":"gebler","d":1281814243,"b":[["q","The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.","Quote from: lachesis on August 14, 2010, 05:38:45 PM"],["t","Actually, I was not assuming that.  In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%.  The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be above 20% - then the typical profit margin would not be 10%).\n\nRegarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost.  There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9243#msg9243"},{"f":"FreeMoney","d":1281815142,"b":[["q","> Quote from: lachesis on August 14, 2010, 05:38:45 PM\n> The problem with your analysis is that you assume that all for-profit minters will have the same profit margin. They won't. Among other things, larger minters will have economies of scale in their favour, making them more profitable.\n\nActually, I was not assuming that.  In the scenario, the profit margin of 10% was the typical profit margin, by which I meant that most of the minting was done by players with a profit margin around 10%.  The scenario assumed the fluctuation in minting activity to be 20%, so it allows quite a lot of variance around the 10% mean without affecting the outcome as long as the bulk is within the 0%-20% interval (and the bulk cannot very well be above 20% - then the typical profit margin would not be 10%).\n\nRegarding the effect of transaction fees, they may alleviate the problem somewhat, but at an unnecessary cost.  There will be some balance between monetary costs and convenience costs, but avoiding the costs altogether seems preferable to me.","Quote from: gebler on August 14, 2010, 07:30:43 PM"],["t","What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.\n\nHaving a secure, open, P2P, pseudonymous, limited quantity money, is worth a ton. People who agree will pay the .001BTC or whatever to make a transaction if that's about what it ends up costing.  "]],"u":"https://bitcointalk.org/index.php?topic=813.msg9246#msg9246"},{"f":"gebler","d":1281816361,"b":[["q","What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.","Quote from: FreeMoney on August 14, 2010, 07:45:42 PM"],["t","Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm. "]],"u":"https://bitcointalk.org/index.php?topic=813.msg9249#msg9249"},{"f":"FreeMoney","d":1281817311,"b":[["q","> Quote from: FreeMoney on August 14, 2010, 07:45:42 PM\n> What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.\n\nSure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.","Quote from: gebler on August 14, 2010, 08:06:01 PM"],["t","Really? Source?"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9254#msg9254"},{"f":"knightmb","d":1281817775,"b":[["q","> Quote from: FreeMoney on August 14, 2010, 07:45:42 PM\n> What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.\n\nSure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.","Quote from: gebler on August 14, 2010, 08:06:01 PM"],["t","I'll bite.  Grin\n\nHow would you fix the algorithm?"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9257#msg9257"},{"f":"gebler","d":1281818937,"b":[["q","> Quote from: gebler on August 14, 2010, 08:06:01 PM\n> I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.\n\nReally? Source?","Quote from: FreeMoney on August 14, 2010, 08:21:51 PM"],["t","Sorry, I was wrong about that.  I though I had read something on the forum to that effect, but now I can't find it.  Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9262#msg9262"},{"f":"FreeMoney","d":1281819012,"b":[["q","> Quote from: FreeMoney on August 14, 2010, 08:21:51 PM\n> > Quote from: gebler on August 14, 2010, 08:06:01 PM\n> > I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.\n>\n> Really? Source?\n\nSorry, I was wrong about that.  I though I had read something on the forum to that effect, but now I can't find it.  Looking at old sources, I see that the 4x cap was there as early as bitcoin-0.1.0.rar, so this is definitely not a new modification.","Quote from: gebler on August 14, 2010, 08:48:57 PM"],["t","I thought so, but still, some changes can be made. What is the change that solves this problem?"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9263#msg9263"},{"f":"gebler","d":1281819074,"b":[["q","> Quote from: gebler on August 14, 2010, 08:06:01 PM\n> > Quote from: FreeMoney on August 14, 2010, 07:45:42 PM\n> > What if I had a factory and hired you as a consultant? Would you tell me avoiding costs altogether was the best thing? Many, many costs are worth it.\n>\n> Sure, I just thought this was an unnecessary cost, best avoided by fixing the algorithm before it causes real problems and associated costs.  I understand that the 4x limit to the difficulty adjustment was added quite recently, so there is some precedent in fixing problematic aspects of the algorithm.\nI'll bite.  Grin\n\nHow would you fix the algorithm?","Quote from: knightmb on August 14, 2010, 08:29:35 PM"],["t","It's in my original post:"],["q","A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.\n\nAlso, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.","Quote from: gebler on August 14, 2010, 12:43:54 PM"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9265#msg9265"},{"f":"knightmb","d":1281819896,"b":[["q","It's in my original post:\n\n> Quote from: gebler on August 14, 2010, 12:43:54 PM\n> A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.\n>\n> Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.","Quote from: gebler on August 14, 2010, 08:51:14 PM"],["t","How will you account for latency and time hacking then?"]],"u":"https://bitcointalk.org/index.php?topic=813.msg9268#msg9268"},{"f":"gebler","d":1281822746,"b":[["q","> Quote from: gebler on August 14, 2010, 08:51:14 PM\n> It's in my original post:\n>\n>\n> > Quote from: gebler on August 14, 2010, 12:43:54 PM\n> > A simple(?) modification of the algorithm would be to apply the adjustment after a certain amount of time rather than at a certain block number.  The switch could still be synced to take effect for the next block, so time synchronization between clients would not need to be super exact to have the vast majority of them agree on when the new difficulty is to be applied.\n> >\n> > Also, the difficulty adjustment should probably take into account the adjustments of the number of bitcoins minted per event (now 50, halved every 4 years).  Halving the number of bitcoins generated each time is equivalent to doubling the difficulty as far as profitability is concerned, and such a drastical drop in profitability is unnecessary if it can be avoided easily. I'm not sure if the current adjustment algorithm already takes that into account somehow, but I couldn't see any obvious adjustment for it in the source code.\nHow will you account for latency and time hacking then?","Quote from: knightmb on August 14, 2010, 09:04:56 PM"],["t","Could you elaborate on what kind of scenarios you see where the proposed algorithm would be more vulnerable than the current one? Note that the current algorithm also uses wallclock time in the difficulty adjustment calculation and is synchronized using newly generated blocks."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9273#msg9273"},{"f":"GoldRush","d":1281826173,"b":[["t","You greatly under estimate the power of the profit motive and a market.  Bitcoins will continue to be generated as people find more clever ways to reduce hardware and power costs.  A lot of people are generating them at zero cost by using their employer's computer.  It's unfair to the employer, but it is the reason why bitcoins will continue to generate.  The current algorithm for difficulty is fine the way it is.\n\nBut let's assume you are correct and people stop generating bitcoins early.  So what?  There will always be a market price for the remaining bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9285#msg9285"},{"f":"NewLibertyStandard","d":1281832524,"b":[["q","But let's assume you are correct and people stop generating bitcoins early.  So what?  There will always be a market price for the remaining bitcoins.","Quote from: trebronics on August 14, 2010, 10:49:33 PM"],["t","Transactions are verified by generating blocks, so although I don't think it will happen, blocks being too difficult to generate would cause the economy to grind to a halt."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9308#msg9308"},{"f":"GoldRush","d":1281837677,"b":[["t","Why would it \"grind to a halt\"?  Economies don't function just because money is being printed.  Are you using the same argument for the US dollar and assuming our \"economy would grind to a halt\" if the government didn't print more dollars?  Of course not."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9334#msg9334"},{"f":"theymos","d":1281838512,"b":[["q","Why would it \"grind to a halt\"?  Economies don't function just because money is being printed.  Are you using the same argument for the US dollar and assuming our \"economy would grind to a halt\" if the government didn't print more dollars?  Of course not.","Quote from: trebronics on August 15, 2010, 02:01:17 AM"],["t","Blocks are used to verify transactions. For example, Bitcoin Market requires two confirmations. If a block takes two hours to make, then it would take four hours to put Bitcoins into Bitcoin Market. This would not be good.\n\nWhen people start adding transaction fees, the value of the current block will steadily rise until it is solved. If this gets very high, everyone will attempt to \"win the jackpot\". The market will solve the problem.\n\nBotnets will probably be supporting Bitcoin in the future, so it doesn't really matter anyway."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9337#msg9337"},{"f":"gebler","d":1281861076,"b":[["q","A lot of people are generating them at zero cost by using their employer's computer.  It's unfair to the employer, but it is the reason why bitcoins will continue to generate.","Quote from: trebronics on August 14, 2010, 10:49:33 PM"],["t","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.  "]],"u":"https://bitcointalk.org/index.php?topic=813.msg9408#msg9408"},{"f":"satoshi","d":1281890236,"b":[["t","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\n\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.\n\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.\n\nThere's also kids putting it on their parent's power bill, employees their employer, botnets, etc.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=813.msg9454#msg9454","s":1,"n":364,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/364/","qt":["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\n\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."],"qc":["mining"]}]},{"id":"p183","k":"p","s":"bitcointalk","t":"Big endinan code problems","u":"https://bitcointalk.org/index.php?topic=816","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/183/","m":[{"f":"chromicant","d":1281823680,"b":[["t","I've seen a lot of messages about some big-endian \"issues\" (ok, no worky) with the bitcoin client. Before I sit and try to analyze all the source code, are there any known \"bad bits\" of the code that assume LE?\n\nI have some idle G4 and Sparc machines that can happily be put to use...plus an old decrepit Alpha that needs to be tested to see if it still boots..."]],"u":"https://bitcointalk.org/index.php?topic=816.msg9280#msg9280"},{"f":"teknohog","d":1281827274,"b":[["t","I also have a couple of G4 machines, but I think this issue is about much more than getting these old(ish) machines to good use. It is something like the Y2038 problem that some people are already discussing; will everyone keep using x86 all those decades, or should we drop the assumption of that particular architecture?\n\nIt is a nice fact that bitcoin happens to compile and run on ARM, one of the most serious contenders of the x86 monopoly, at least in the mobile and embedded space. Nevertheless, a digital currency is too important to be limited in computing architectures. Don't banks tend to use big iron?"]],"u":"https://bitcointalk.org/index.php?topic=816.msg9290#msg9290"},{"f":"MoonShadow","d":1281831004,"b":[["q","I've seen a lot of messages about some big-endian \"issues\" (ok, no worky) with the bitcoin client. Before I sit and try to analyze all the source code, are there any known \"bad bits\" of the code that assume LE?\n\nI have some idle G4 and Sparc machines that can happily be put to use...plus an old decrepit Alpha that needs to be tested to see if it still boots...","Quote from: chromicant on August 14, 2010, 10:08:00 PM"],["t","Do you think that you might have replaced them sometime in the next 28 years?"]],"u":"https://bitcointalk.org/index.php?topic=816.msg9303#msg9303"},{"f":"teknohog","d":1283019050,"b":[["t","I have been thinking about an interim solution, inspired by the fact that many architectures can run in either endianness. AFAIK, Virtual PC used this feature of the PowerPC to run Windows on a Mac. Apparently, Linux also supports running little-endian PPC binaries on an otherwise big-endian system.\n\nIt will not be as simple as compiling with -mlittle-endian, as the libraries should likely have the same endianness. It might be possible to cross-compile a little-endian system, compile a static binary in the chroot, and run the resulting binary in the usual big-endian system. Or it could be running in the chroot, if that is easier to accomplish.\n\nSo far, I have not managed to build such a system, but it might be possible with a suitable cross-compiler. I already use Gentoo and Crossdev for such things, but I have not found a suitable target machine type for this."]],"u":"https://bitcointalk.org/index.php?topic=816.msg11521#msg11521"},{"f":"Gespenster","d":1283081719,"b":[["t","The ByteReverse macro should probably be skipped before doing SHA-256 transforms."]],"u":"https://bitcointalk.org/index.php?topic=816.msg11583#msg11583"},{"f":"lfm","d":1283100070,"b":[["q","The ByteReverse macro should probably be skipped before doing SHA-256 transforms.","Quote from: Gespenster on August 29, 2010, 11:35:19 AM"],["t","before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.\n\nin fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed."]],"u":"https://bitcointalk.org/index.php?topic=816.msg11593#msg11593"},{"f":"Gespenster","d":1283102296,"b":[["q","> Quote from: Gespenster on August 29, 2010, 11:35:19 AM\n> The ByteReverse macro should probably be skipped before doing SHA-256 transforms.\n\nbefore and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.\n\nin fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.","Quote from: lfm on August 29, 2010, 04:41:10 PM"],["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=816.msg11595#msg11595"},{"f":"satoshi","d":1283120076,"b":[["t","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.\n\nBig-endian is on its way out anyway."]],"u":"https://bitcointalk.org/index.php?topic=816.msg11610#msg11610","s":1,"n":432,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/432/","sj":"Re: Big endian code problems"}]},{"id":"p184","k":"p","s":"bitcointalk","t":"tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10","u":"https://bitcointalk.org/index.php?topic=820","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/184/","m":[{"f":"satoshi","d":1281887529,"b":[["t","0.3.10 has tcatm's 4-way SSE2 as an option switch.\n\nUse the switch \"-4way\" to turn it on.  Without the switch you get Crypto++ ASM SHA-256.\n\nI could only get this working with Linux.\n\nDownload:\nGet 0.3.10 from http://bitcointalk.org/index.php?topic=827.0\n\nPlease report back your CPU and results!  I think it's pretty clear that Core 2 and lower are slower, i5 faster.  I don't think we've heard any i7 results yet.  We need to know about the different models of AMD or other less common CPUs."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9452#msg9452","s":1,"n":363,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/363/"},{"f":"knightmb","d":1281891736,"b":[["t","I did a quick test, will report back when I try it on more machines.\n\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)\n\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)\n\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)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9457#msg9457","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"satoshi","d":1281896606,"b":[["t","I hope someone can test an i5 or AMD to check that I built it right.  I don't have either to test with.\n\nI'm also curious if it performs much worse on 32-bit linux vs 64-bit."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9478#msg9478","s":1,"n":366,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/366/","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"sgtstein","d":1281896800,"b":[["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=820.msg9479#msg9479","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"satoshi","d":1281897807,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9483#msg9483","s":1,"n":367,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/367/","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"sgtstein","d":1281897985,"b":[["t","Okay, makes sense. I have an i7 930 I'll try and test out with too."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9484#msg9484","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"tcatm","d":1281909041,"b":[["q","If 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.","Quote from: knightmb on August 15, 2010, 05:02:16 PM"],["t","That's unlikely. The loop accesses 432 bytes of data. That should fit in most caches."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9552#msg9552","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"Ground Loop","d":1281916180,"b":[["t","5,911 khash with -4way\n11,260 without\n(Dual Xeon E5450, 64-bit, 8 threads)"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9592#msg9592","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"tcatm","d":1281916998,"b":[["t","-4way: 12518 khash/s\nwithout: 6550 khash/s\n\nIt's a little bit slower than my patch (~14000kash/s).\n\nedit: I ran the binary on an older AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ with the same effect we see on older intel cpus:\n-4way: 1120khash/s\nwithout: 2012khash/s"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9597#msg9597","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"tcatm","d":1281917318,"b":[["t","Did anyone verify it to produce correct results on 32 bit hosts?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9600#msg9600","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"gebler","d":1281918777,"b":[["t","Running 32-bit Linux on an AMD Athlon 64 X2, I get the following results:\n\n  normal: 2850 khash/s\n  with -4way: 1708 khash/s\n\nI haven't checked if the hashes are correct, just the speed."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9610#msg9610","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"aceat64","d":1281919074,"b":[["t","I created a wiki page so we can keep track of the results: http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9613#msg9613","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"tcatm","d":1281919419,"b":[["t","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%."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9617#msg9617","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"HostFat","d":1281919643,"b":[["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%.","Quote from: tcatm on August 16, 2010, 12:43:39 AM"],["t","Good Cheesy\nWill this also work on Windows OS?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9620#msg9620","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"tcatm","d":1281919804,"b":[["q","> Quote from: tcatm on August 16, 2010, 12:43:39 AM\n> 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%.\nGood Cheesy\nWill this also work on Windows OS?","Quote from: Joozero on August 16, 2010, 12:47:23 AM"],["t","Didn't try it, but CFLAGS are not OS dependent at all so I guess it'll work."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9621#msg9621","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"NewLibertyStandard","d":1281923341,"b":[["q","I created a wiki page so we can keep track of the results: http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2","Quote from: aceat64 on August 16, 2010, 12:37:54 AM"],["t","You might want to add columns for whether hyper-threading is enabled, number of physical cores and how many cores Bitcoin is using. Without 4way, I get very slightly better results when I have half of my virtual cores hashing. 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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9630#msg9630","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"aceat64","d":1281924808,"b":[["q","> Quote from: aceat64 on August 16, 2010, 12:37:54 AM\n> I created a wiki page so we can keep track of the results: http://www.bitcoin.org/wiki/doku.php?id=4-way_sse2\nYou might want to add columns for whether hyper-threading is enabled, number of physical cores and how many cores Bitcoin is using. Without 4way, I get very slightly better results when I have half of my virtual cores hashing. 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.","Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM"],["t","I've updated the page with your suggestions, I've also added footnotes to explain some of the fields."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9640#msg9640","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"jgarzik","d":1281925852,"b":[["t","My -4way results:  slower for two older boxes, faster for newer one.\n\n(\"model name\" comes from Linux's /proc/cpuinfo, which reports directly from CPU)\n\n1) model name   : Intel(R) Pentium(R) D CPU 3.00GHz\n\ntotal cores: 2\nwithout -4way:    0.999 Mhash/sec\nwith -4way: 0.850 Mhash/sec\n\n2) model name   : Dual Core AMD Opteron(tm) Processor 280\n\ntotal cores: 4\nwithout -4way:   4.6 Mhash/sec\nwith -4way:    4.0 Mhash/sec\n\n3) model name   : Genuine Intel(R) CPU             000  @ 3.20GHz\n\ntotal cores: 4\nwithout -4way:   5.7 Mhash/sec\nwith -4way:    7.0 Mhash/sec"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9647#msg9647","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"satoshi","d":1281927477,"b":[["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%.","Quote from: tcatm on August 16, 2010, 12:43:39 AM"],["t","GCC 4.3.3 doesn't support -march=amdfamk10.  I get:\nsha256.cpp:1: error: bad value (amdfamk10) for -march= switch"],["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.","Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM"],["t","Hey, you may be onto something!\n\nhyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.\n\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.\n\nHow much of an improvement do you get with hyperthreading?\n\nSome numbers?  What CPU is that?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9655#msg9655","s":1,"n":384,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/384/","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"lfm","d":1281928234,"b":[["t","model name      : AMD Phenom(tm) II X4 940 Processor  at 3.0 ghz  linux 64\n\nwith -4way     \"hashespersec\" : 11132770\n\nwithout      \"hashespersec\" : 5877668"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9658#msg9658"},{"f":"gridecon","d":1281928544,"b":[["t","I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9659#msg9659"},{"f":"Vasiliev","d":1281928627,"b":[["q","> Quote from: tcatm on August 16, 2010, 12:43:39 AM\n> 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%.\nGCC 4.3.3 doesn't support -march=amdfamk10.  I get:\nsha256.cpp:1: error: bad value (amdfamk10) for -march= switch","Quote from: satoshi on August 16, 2010, 02:57:57 AM"],["t","try -march=amdfam10"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9660#msg9660","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"satoshi","d":1281928984,"b":[["q","try -march=amdfam10","Quote from: Vasiliev on August 16, 2010, 03:17:07 AM"],["t","That works.\n\nThat's strange...  are we sure that's the same thing?  tcatm, try amdfam10 and make sure you get the same speed measurement."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9661#msg9661","s":1,"n":385,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/385/","sj":"Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2"},{"f":"Vasiliev","d":1281929255,"b":[["t","http://www.google.com/search?q=amdfamk10\n\nI think he misremembered it since AMD arches are K#."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9663#msg9663"},{"f":"lfm","d":1281929435,"b":[["t","model name      : Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz,   linux 64\n\nno difference at about 4950 khash/s"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9664#msg9664"},{"f":"jgarzik","d":1281929728,"b":[["t","Update for"],["c","cpu family : 6\nmodel  : 26\nmodel name : Genuine Intel(R) CPU             000  @ 3.20GHz\nstepping : 4"],["t","Machine has 4 cores, each with 2 hyperthreads.  /proc/cpuinfo shows 8 virtual processors.\n\nwithout -4way, setgen 4:    5.7 Mhash/sec\nwithout -4way, setgen 8:    5.0 Mhash/sec\n\nwith -4way, setgen 4:   7.0 Mhash/sec\nwith -4way, setgen 8:   9.3 Mhash/sec\n\nSo, the old wisdom of \"hyperthreading slows things down\" is now shattered, on this machine."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9665#msg9665"},{"f":"Ground Loop","d":1281933260,"b":[["t","No winners for 4way in my other three Intel machines either:\n\nIntel(R) Core(TM)2 Duo CPU     E8500 @ 3.16GHz (64-bit Linux)\n4way: 1565  std: 3002\n\nIntel(R) Xeon(TM) CPU 3.00GHz (32-bit Linux)\n4way: 1243  std: 2048\n\nIntel(R) Core(TM)2 CPU          6300  @ 1.86GHz\n4way: 932   std: 1733\n\n(All running 0.3.10, -1 proclimit)\nExperiments with proclimit weren't any better."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9674#msg9674"},{"f":"satoshi","d":1281933419,"b":[["q","cpu family : 6\nmodel  : 26\nmodel name : Genuine Intel(R) CPU             000  @ 3.20GHz\nstepping : 4","Quote from: jgarzik on August 16, 2010, 03:35:28 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9676#msg9676","s":1,"n":386,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/386/"},{"f":"NewLibertyStandard","d":1281934951,"b":[["q","I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?","Quote from: gridecon on August 16, 2010, 03:15:44 AM"],["t","o_O... good luck hashing, you're gonna need it!"],["q","> Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM\n> 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.\nHey, you may be onto something!\n\nhyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.\n\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.\n\nHow much of an improvement do you get with hyperthreading?\n\nSome numbers?  What CPU is that?","Quote from: satoshi on August 16, 2010, 02:57:57 AM"],["t","Here are the results from my very poor memory on an i7 860 2.8 GHz with Ubuntu 10.04 amd64. Some of the numbers may be a bit off.\n\nWithout 4way, with HT, 4/8 virtual cores, 4.5-5 Mhash/sec\nWithout 4way, with HT, 8/8 virtual cores, a bit less than above, but basically the same\n\nWith 4way, with HT, 8/8 virtual cores, 6.5-8 Mhash/sec (It may be my imagination, but it seems noticeably more variable.)\nWith 4way, with HT, 4/8 virtual cores, 5-6 Mhash/sec\n\nWithout 4way, without HT, 4/4 physical cores, 4.5-5 Mhas/sec (But a bit slower than the first result.)\nWith 4way, without HT, 4/4 physical cores, 5-6 Mhash/sec"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9680#msg9680"},{"f":"gridecon","d":1281936615,"b":[["q","> Quote from: gridecon on August 16, 2010, 03:15:44 AM\n> I have two quadcore Phenom II 64-bit linux machines (ubuntu 9.10 both) and the -4way option increases my hashing speed so much I'm suspicious. I get about 5-6khash/sec on these boxes previously and without -4way option. With -4way I get over 11khash/sec! In other words, the -4way switch almost DOUBLES the reported hashing speed. This level of improvement seems more than expected and makes me wonder if my boxes are really doing the hashing that much faster or if there could possible be an issue where the math operations are actually being skipped over for some reason, causing illusory speed and an inability to actually generate blocks?\no_O... good luck hashing, you're gonna need it!","Quote from: NewLibertyStandard on August 16, 2010, 05:02:31 AM"],["t","I guess that should read either mhash/sec or THOUSANDS of khash/sec...but hey, what's 3 orders of magnitude among friends?\n\nPerhaps that typographical error is why nobody has answered whether or not a nearly 100% speeded from the -4way option is at all realistic? I'm not convinced the crypto hashing is really taking place at the rate of 11000khash/sec on my desktop box."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9688#msg9688"},{"f":"jgarzik","d":1281936836,"b":[["q","> Quote from: jgarzik on August 16, 2010, 03:35:28 AM\n> cpu family : 6\n> model  : 26\n> model name : Genuine Intel(R) CPU             000  @ 3.20GHz\n> stepping : 4\ncpu 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.","Quote from: satoshi on August 16, 2010, 04:36:59 AM"],["t","Does bitcoin perform any self-tests at startup, to verify that hashing is working?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg9689#msg9689"},{"f":"NewLibertyStandard","d":1281939404,"b":[["t","More importantly, about how long should it take 10 Mhash/sec to verify difficulty 1 blocks?\n\nAfter the 64-bit Linux hashing bug was fixed I generated a block or two in short order, but since that one or two blocks, I have not generated a single block. It's starting to seem a little fishy.\n\nI'm currently testing Bitcoin on two Linux 64-bit computers. Is there anything in the code blocking early block verification?\n\nEdit: Never mind. I used the Bitcoin Generation Calculator <http://www.alloscomp.com/bitcoin/calculator.php> and divided out the difficulty. Everything is fine here, I've generated a couple blocks with 4way. About to start testing without 4way.\n\nAnother Edit: My test only verifies that hashing works. It does not verify whether I'm really getting the displayed speed."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9691#msg9691"},{"f":"tcatm","d":1281957304,"b":[["t","@satoshi: Oops, I meant -march=amdfam10. Sorry.\n\n@everyone confused about improvement on Phenoms: I developed the code on a Phenom (940) and verified it (at least in 64bit mode) and the improvement you see is real.\n\nConcerning Hyperthreading: It seems to give a little performance gain, maybe from running load/store instructions in parallel with aritmethic instructions. There's only a tiny bit of plain x86 instructions for glueing the function into the ABI. They take less than ~2% of the total CPU time (measured with gprof)."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9721#msg9721"},{"f":"teknohog","d":1281961911,"b":[["t","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.\n\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"],["c","sha256.cpp:8:23: error: xmmintrin.h: No such file or directory\nsha256.cpp:34: error: ‘__m128i’ does not name a type"],["t","but hopefully this is easy to fix."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9729#msg9729"},{"f":"satoshi","d":1281965881,"b":[["t","I wrapped sha256.cpp in\n#ifdef FOURWAYSSE2\n#endif // FOURWAYSSE2\n\ntry it now."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9736#msg9736","s":1,"n":388,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/388/"},{"f":"tommy","d":1281973375,"b":[["t","model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+\n\nw/o -4way  \"hashespersec\" : 2539397\n\nwith -4way  \"hashespersec\" : 2108791\n\nLinux, Debian, 32 bit."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9755#msg9755"},{"f":"teknohog","d":1281976891,"b":[["q","I wrapped sha256.cpp in\n#ifdef FOURWAYSSE2\n#endif // FOURWAYSSE2\n\ntry it now.","Quote from: satoshi on August 16, 2010, 01:38:01 PM"],["t","Thanks, works fine now."]],"u":"https://bitcointalk.org/index.php?topic=820.msg9769#msg9769"},{"f":"hugolp","d":1282069587,"b":[["t","Model: Intel Atom n330 (2 cores, 4 virtual).\n\nOS: Ubuntu 10.04 64bit\n\nUsing the -4way option I get half the speed than using no option. "]],"u":"https://bitcointalk.org/index.php?topic=820.msg9935#msg9935"},{"f":"denaje","d":1282158364,"b":[["t","64-bit Gentoo / Intel Core i7\n\nW/O 4way: 4324294\nWith 4way: 7649415\n\n32-bit Ubuntu VM on XP host /  Intel Core 2 Duo\n\nW/O 4way: 1751518\nWith 4way: 793100"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10090#msg10090"},{"f":"Ground Loop","d":1282172408,"b":[["t","So is it accurate to say that, so far, only Intel Core i7 processors and certain (Phenom?) AMD processors enjoy a speed bump from -4way?"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10163#msg10163"},{"f":"nelisky","d":1282172545,"b":[["q","So is it accurate to say that, so far, only Intel Core i7 processors and certain (Phenom?) AMD processors enjoy a speed bump from -4way?","Quote from: Ground Loop on August 18, 2010, 11:00:08 PM"],["t","And i5, at least on my macbookpro"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10164#msg10164"},{"f":"Ground Loop","d":1282173266,"b":[["t","Any non-Mac i5 love?\nWindows i5 64-bit got slower here.\n[correction -- not true.  Windows doesn't have -4way, and the Linux machines are Xeons.]"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10167#msg10167"},{"f":"vess","d":1282200087,"b":[["t","My Core i5 laptop (Ubuntu) doubled in speed. Actually, it didn't double in speed. It stayed the same speed, but only uses half the CPU now. I can't get it to go back to full CPU usage. That said, my laptop is a lot cooler when generating blocks now. I'll post back if I see it successfully go up to 100% usage."]],"u":"https://bitcointalk.org/index.php?topic=820.msg10214#msg10214"},{"f":"satoshi","d":1282244863,"b":[["q","Any non-Mac i5 love?\nWindows i5 64-bit got slower here.","Quote from: Ground Loop on August 18, 2010, 11:14:26 PM"],["t","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."],["q","And i5, at least on my macbookpro","Quote from: nelisky on August 18, 2010, 11:02:25 PM"],["t","Good, so I take it that's a confirmation that it's working on Mac as well?\n\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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg10281#msg10281","s":1,"n":402,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/402/"},{"f":"nelisky","d":1282249699,"b":[["q","> Quote from: nelisky on August 18, 2010, 11:02:25 PM\n> And i5, at least on my macbookpro\nGood, so I take it that's a confirmation that it's working on Mac as well?\n\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.","Quote from: satoshi on August 19, 2010, 07:07:43 PM"],["t","Yep, it's working all right. The number I had posted were from an old svn revision patched with tcatm's changes, but today I compiled trunk and while I had to once again tweak the makefile, after I did it works great with the numbers matching what I experienced before.\n\nChanges I did for my system are below, and while some are cosmetic, like removing wx-config from making bitcoind, just to avoid the warnings if you don't have it installed, others are system specific, like the DEPS dir, and the fact I don't have 32bit libs which makes the link step fail if -arch i386 is there.\nThe bsddb changes are, I believe, a typo. Includes and Libs point to db46, but then the object list for the linker states db48. Anyway, here's the diff for what got me going:"],["c","Index: makefile.osx\n===================================================================\n--- makefile.osx (revision 139)\n+++ makefile.osx (working copy)\n@@ -6,29 +6,29 @@\n # Laszlo Hanyecz (solar@heliacal.net)\n \n CXX=llvm-g++\n-DEPSDIR=/Users/macosuser/bitcoin/deps\n+DEPSDIR=/opt/local\n \n INCLUDEPATHS= \\\n- -I\"$(DEPSDIR)/include\"\n+ -I\"$(DEPSDIR)/include\"  -I\"$(DEPSDIR)/include/db46\"\n \n LIBPATHS= \\\n- -L\"$(DEPSDIR)/lib\"\n+ -L\"$(DEPSDIR)/lib\"  -L\"$(DEPSDIR)/lib/db46\"\n \n-WXLIBS=$(shell $(DEPSDIR)/bin/wx-config --libs --static)\n+WXLIBS=\n \n LIBS= -dead_strip \\\n- $(DEPSDIR)/lib/libdb_cxx-4.8.a \\\n- $(DEPSDIR)/lib/libboost_system.a \\\n- $(DEPSDIR)/lib/libboost_filesystem.a \\\n- $(DEPSDIR)/lib/libboost_program_options.a \\\n- $(DEPSDIR)/lib/libboost_thread.a \\\n+ $(DEPSDIR)/lib/db46/libdb_cxx-4.6.a \\\n+ $(DEPSDIR)/lib/libboost_system-mt.a \\\n+ $(DEPSDIR)/lib/libboost_filesystem-mt.a \\\n+ $(DEPSDIR)/lib/libboost_program_options-mt.a \\\n+ $(DEPSDIR)/lib/libboost_thread-mt.a \\\n  $(DEPSDIR)/lib/libcrypto.a\n \n-DEFS=$(shell $(DEPSDIR)/bin/wx-config --cxxflags) -D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0\n+DEFS=-D__WXMAC_OSX__ -DNOPCH -DMSG_NOSIGNAL=0 -DFOURWAYSSE2\n \n DEBUGFLAGS=-g -DwxDEBUG_LEVEL=0\n # ppc doesn't work because we don't support big-endian\n-CFLAGS=-mmacosx-version-min=10.5 -arch i386 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)\n+CFLAGS=-mmacosx-version-min=10.5 -arch x86_64 -O3 -Wno-invalid-offsetof -Wformat $(DEBUGFLAGS) $(DEFS) $(INCLUDEPATHS)\n HEADERS=headers.h strlcpy.h serialize.h uint256.h util.h key.h bignum.h base58.h \\\n     script.h db.h net.h irc.h main.h rpc.h uibase.h ui.h noui.h init.h\n \n@@ -42,6 +42,7 @@\n     obj/rpc.o \\\n     obj/init.o \\\n     cryptopp/obj/sha.o \\\n+    obj/sha256.o \\\n     cryptopp/obj/cpu.o\n \n \n@@ -55,7 +56,7 @@\n  $(CXX) -c $(CFLAGS) -O3 -DCRYPTOPP_DISABLE_ASM -o $@ $<\n \n bitcoin: $(OBJS) obj/ui.o obj/uibase.o\n- $(CXX) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(WXLIBS) $(LIBS)\n+ $(CXX) $(shell $(DEPSDIR)/bin/wx-config --cxxflags) $(CFLAGS) -o $@ $(LIBPATHS) $^ $(shell $(DEPSDIR)/bin/wx-config --libs --static) $(LIBS)\n \n \n obj/nogui/%.o: %.cpp $(HEADERS)"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10299#msg10299"},{"f":"ArtForz","d":1282409791,"b":[["t","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.\n\n• AMD K8: 2 64bit units\n\n• intel Core/Core2: 3 64bit units\n\n• AMD K10: 2 128bit units\n\n• intel nehalem: 3 128bit units\n\nK10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II\nnehalem = xeon 34xx/35xx/36xx/55xx/56xx/65xx/75xx, i3/i5/i7"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10609#msg10609"},{"f":"satoshi","d":1282519310,"b":[["t","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.\n\nThere's no hope for Core/Core2 then.  They only have half the SSE2 hardware.\n\nStrange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one."]],"u":"https://bitcointalk.org/index.php?topic=820.msg10720#msg10720","s":1,"n":408,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/408/"},{"f":"Ground Loop","d":1282542317,"b":[["t","Intel Atom 230 @ 1.60GHz.  Linux 32-bit.\n(Acer Aspire Revo)\n\nStock: 438 khash/sec (1 proc gives 354)\n4way:  254 khash/sec\n\nSo you can take this one off the powerhouse list. Smiley\n Grin"]],"u":"https://bitcointalk.org/index.php?topic=820.msg10754#msg10754"},{"f":"sgtstein","d":1282671068,"b":[["t","Anybody catch the new AMD Bulldozer press release? If I understand correctly, it should be capable of processing 8 64bit hashes, per core, at the same time. Would be quite a speed boost using this same code design.\n\nSlashdot <http://hardware.slashdot.org/story/10/08/24/1521203/AMD-Details-Upcoming-Bulldozer-Architecture> has the article.\nPC Perspective <http://www.pcper.com/article.php?aid=985&type=expert> has the details.\n\nWas also covered by AnandTech <http://www.anandtech.com/show/2872> back in November, 2009."]],"u":"https://bitcointalk.org/index.php?topic=820.msg11032#msg11032"},{"f":"satoshi","d":1282689836,"b":[["q","• AMD K10: 2 128bit units\n\n• intel nehalem: 3 128bit units","Quote from: ArtForz on August 21, 2010, 04:56:31 PM"],["t","This probably explains why hyperthreading increases performance with -4way.  If three SSE2 units is excessive, then hyperthreading would help keep them all busy."]],"u":"https://bitcointalk.org/index.php?topic=820.msg11068#msg11068","s":1,"n":411,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/411/"},{"f":"tcatm","d":1282955228,"b":[["t","I just reviewed the sourcecode as I had a few ideas to optimize it further and I noticed that 4way is partly broken:\n\nfrom main.cpp:"],["c","                for (int j = 0; j < NPAR; j++)\n                {   \n                    if (thash[7][j] == 0)\n                    {                       \n                        for (int i = 0; i < sizeof(hash)/4; i++)\n                          ((unsigned int*)&hash)[i] = thash[i][j];\n                        pblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n                    }   \n                }   "],["t","The 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.\n\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?"],["c","                unsigned int min_hash = ~1;\n       for (int j = 0; j < NPAR; j++)\n                {   \n                    if (thash[7][j] == 0)\n                    {   \n                        if(thash[6][j] < min_hash) {\n                          min_hash = thash[6][j];\n                          for (int i = 0; i < sizeof(hash)/4; i++)\n                            ((unsigned int*)&hash)[i] = thash[i][j];\n                          pblock->nNonce = ByteReverse(tmp.block.nNonce + j);\n                        }   \n                    }   \n                } "]],"u":"https://bitcointalk.org/index.php?topic=820.msg11467#msg11467"},{"f":"satoshi","d":1283005635,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=820.msg11503#msg11503","s":1,"n":430,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/430/"}]},{"id":"p185","k":"p","s":"bitcointalk","t":"overflow bug SERIOUS","u":"https://bitcointalk.org/index.php?topic=823","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/185/","m":[{"f":"lfm","d":1281899051,"b":[["t","seems a block at height 74638 has expoited a bug in the net. It uses an integer overflow to make a negative total transaction. The two transaction outputs are:\n\n out Value:92233720368.54(7ffffffffff85ee0) out Value:92233720368.54(7ff\nffffffff85ee0)\n\nWe need a fix asap\n\nEdit:\n(satoshi)\n0.3.10 patch download links here:\nhttp://bitcointalk.org/index.php?topic=827.0"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9494#msg9494"},{"f":"kencausey","d":1281900358,"b":[["t","Original post: http://bitcointalk.org/index.php?topic=822.0"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9500#msg9500"},{"f":"NewLibertyStandard","d":1281904004,"b":[["t","Whether to stop generating depends on the possible solution. If there are ever bad blocks, I can imagine an officially patched Bitcoin could be hard coded to exclude bad transactions contained in the block chain so that although the bad transactions would still be sitting in the chain, they would be ignored. I recommend people keep on generating if you were previously generating but be cautious about transactions until we hear back from Satoshi.\n\nThe recommendation <http://bitcointalk.org/index.php?topic=823.msg9531#msg9531> is to stop generating."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9518#msg9518"},{"f":"Gavin Andresen","d":1281904782,"b":[["t","Until there is a better fix... after a very small amount of testing this seems to work:"],["c","--- a/main.h\n+++ b/main.h\n@@ -473,8 +473,12 @@ public:\n \n         // Check for negative values\n         foreach(const CTxOut& txout, vout)\n+ {\n             if (txout.nValue < 0)\n                 return error(\"CTransaction::CheckTransaction() : txout.nValue negative\");\n+ if (txout.nValue > 21000000*COIN)\n+ return error(\"CTransaction::CheckTransaction() : txout.nValue over-max\");\n+ }\n \n         if (IsCoinBase())\n         {\n@@ -520,6 +524,8 @@ public:\n         int64 nValueOut = 0;\n         foreach(const CTxOut& txout, vout)\n         {\n+ if (txout.nValue > 21000000*COIN)\n+ continue; // ignore over-max-value...\n             if (txout.nValue < 0)\n                 throw runtime_error(\"CTransaction::GetValueOut() : negative value\");\n             nValueOut += txout.nValue;"],["t","You'll need to re-download the part of the block chain before the bad block-- remove the blkindex.dat and blk0001.dat files.   I started with knightmb's blockchain <http://knightmb.dyndns.org/files/bitcoin/blocks/> snapshot."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9524#msg9524"},{"f":"jgarzik","d":1281904969,"b":[["t","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\n\nEDIT:  I was unable to patch directly using this, perhaps CRLF problems.\n\nI applied your changes manually, and uploaded the result here: http://yyz.us/bitcoin/patch.bitcoin-gavin-overflow-quick-fix"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9526#msg9526"},{"f":"satoshi","d":1281905949,"b":[["t","Here's the preliminary change.  Look right?  I have more changes to make, this isn't all of it.  Will SVN shortly."],["c","    bool CheckTransaction() const\n    {\n        // Basic checks that don't depend on any context\n        if (vin.empty() || vout.empty())\n            return error(\"CTransaction::CheckTransaction() : vin or vout empty\");\n\n        // Check for negative and overflow values\n        int64 nTotal = 0;\n        foreach(const CTxOut& txout, vout)\n        {\n            if (txout.nValue < 0)\n                return error(\"CTransaction::CheckTransaction() : txout.nValue negative\");\n            if (txout.nValue > 21000000 * COIN)\n                return error(\"CTransaction::CheckTransaction() : txout.nValue too high\");\n            nTotal += txout.nValue;\n            if (nTotal > 21000000 * COIN)\n                return error(\"CTransaction::CheckTransaction() : txout total too high\");\n        }\n\n        if (IsCoinBase())\n        {\n            if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)\n                return error(\"CTransaction::CheckTransaction() : coinbase script size\");\n        }\n        else\n        {\n            foreach(const CTxIn& txin, vin)\n                if (txin.prevout.IsNull())\n                    return error(\"CTransaction::CheckTransaction() : prevout is null\");\n        }\n\n        return true;\n    }"],["t","Don't sticky the topic, nobody looks up there.  There'll be enough posts to bump."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9530#msg9530","s":1,"n":368,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/368/"},{"f":"satoshi","d":1281906405,"b":[["t","It would help if people stop generating.  We will probably need to re-do a branch around the current one, and the less you generate the faster that will be.\n\nA first patch will be in SVN rev 132.  It's not uploaded yet.  I'm pushing some other misc changes out of the way first, then I'll upload the patch for this."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9531#msg9531","s":1,"n":369,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/369/"},{"f":"kencausey","d":1281906593,"b":[["t","I'm afraid the community is just too big and distributed now to expect much in the way of voluntary quick action on anything, especially generation which I'm sure many have on automatic and largely unmoderated."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9533#msg9533"},{"f":"Gavin Andresen","d":1281906633,"b":[["t","Looks good to me.\n\nCan you easily hardcode a check for the bad block's hash at startup and orphan it and subsequent blocks if they're on the best-block chain?\nIt's painful to have to re-download all or most of the chain to fix this..."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9534#msg9534"},{"f":"NewLibertyStandard","d":1281906918,"b":[["q","Looks good to me.\n\nCan you easily hardcode a check for the bad block's hash at startup and orphan it and subsequent blocks if they're on the best-block chain?\nIt's painful to have to re-download all or most of the chain to fix this...","Quote from: gavinandresen on August 15, 2010, 09:10:33 PM"],["t","Or just a quick re-verification of all blocks. After all, it is 5x faster <http://bitcointalk.org/index.php?topic=550.0> than it used t be. Wink"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9535#msg9535"},{"f":"satoshi","d":1281907435,"b":[["t","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?  "]],"u":"https://bitcointalk.org/index.php?topic=823.msg9539#msg9539","s":1,"n":370,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/370/"},{"f":"theymos","d":1281907569,"b":[["q","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? ","Quote from: satoshi on August 15, 2010, 09:23:55 PM"],["t","http://knightmb.dyndns.org/files/bitcoin/blocks/"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9540#msg9540"},{"f":"NewLibertyStandard","d":1281907748,"b":[["t","I prefer to just re-download them.\n\nBlock verification after the patch but before everyone upgrades is going to be SLOW! It'll probably cause the next difficulty adjustment to decrease significantly. Of course everyone will probably have upgraded by the time the next adjustment rolls around, so we'll probably roll through it relatively quickly."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9543#msg9543"},{"f":"kencausey","d":1281908190,"b":[["t","Edit: Hmm, I see there is an info file included which might just clue me in.\n\nHow about explaining to us stupid newbies what we would do with the blockchain once we download it?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9545#msg9545"},{"f":"jgarzik","d":1281908321,"b":[["q","How about explaining to us stupid newbies what we would do with the blockchain once we download it?","Quote from: kencausey on August 15, 2010, 09:36:30 PM"],["t","It means replacing files in the bitcoin data directory.  It is not recommended, unless you know what you're doing.\n\nEasiest and safest way is to backup wallet.dat then redownload everything."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9547#msg9547"},{"f":"satoshi","d":1281908419,"b":[["t","Patch is uploaded to SVN rev 132!\n\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.\n\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.\n\nI'll build releases shortly. "]],"u":"https://bitcointalk.org/index.php?topic=823.msg9548#msg9548","s":1,"n":371,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/371/"},{"f":"NewLibertyStandard","d":1281908431,"b":[["q","How about explaining to us stupid newbies what we would do with the blockchain once we download it?","Quote from: kencausey on August 15, 2010, 09:36:30 PM"],["t","While Bitcoin is not running, you put it in your Bitcoin data directory. ~/.bitcoin on Linux. If you want to re-download the whole chain, you just delete the file from the data directory while Bitcoin is not running.\n\nI'm going to be move my blk00x.dat files and blkindex.dat file out of by data directory and restart the client. Those are the correct files, right?\n\nEdit: I'll also backup the whole directory, like I usually do before upgrades."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9549#msg9549"},{"f":"jgarzik","d":1281909057,"b":[["q","If 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.","Quote from: satoshi on August 15, 2010, 09:40:19 PM"],["t","Anybody wanna volunteer to create blk*.dat for block chain <= 64637 ?\n\nMaybe the official binaries could simply ship a known-good block chain, to save time and bandwidth?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9553#msg9553"},{"f":"NewLibertyStandard","d":1281909911,"b":[["t","Will the bug fix include the 4-way SSE2 patch <http://bitcointalk.org/index.php?topic=820.msg9452#msg9452> of 0.3.9 rc2? Thanks for letting me know that it is included <http://bitcointalk.org/index.php?topic=823.msg9557#msg9557>, theymos. Please release another release candidate when you have a moment if it is not included."],["q","What about the transactions from 74000 to the invalid block. Are those all invalid now as well?","Quote from: davidonpda on August 15, 2010, 10:02:05 PM"],["t","Only the blocks including and after the invalid block are invalid. All previous blocks are valid."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9556#msg9556"},{"f":"theymos","d":1281909962,"b":[["q","What about the transactions from 74000 to the invalid block. Are those all invalid now as well?","Quote from: davidonpda on August 15, 2010, 10:02:05 PM"],["t","Only this aberrant transaction and coins generated after it in the block chain will be removed. All other transactions will continue to exist."],["q","Will the bug fix include the 4-way SSE2 patch included in 0.3.9rc2?","Quote from: NewLibertyStandard"],["t","It's included."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9557#msg9557"},{"f":"knightmb","d":1281910423,"b":[["t","Oh, yeah, just noticed this topic. I can't remember when those block chains were snapshot, but I'll update it to be more descriptive (like block 64,000, etc.)\n\nGood thing I keep those around.  Grin\n\nMy web server sits on a fiber, so it won't be a big deal everyone starts to download those files at once (at least for the more technical people).\n\n[edit] Shutting down all the remaining servers and super-nodes I left running. Hope that helps."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9558#msg9558"},{"f":"Insti","d":1281910645,"b":[["t","knightmb, do you still have any of your monster network available to turn on to help build the new valid chain?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9560#msg9560"},{"f":"knightmb","d":1281910697,"b":[["q","knightmb, do you still have any of your monster network available to turn on to help build the new valid chain?","Quote from: Insti on August 15, 2010, 10:17:25 PM"],["t","Not anymore, was shutdown on the last day of the month for July, all I have left are about a 2 dozen servers, but near nothing of what I had before."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9561#msg9561"},{"f":"NewLibertyStandard","d":1281911246,"b":[["t","Here's something for your Signature if you're interested."],["c","[i][color=red][b]*** WARNING ***[/b][/color]  DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638). We are investigating a problem. ([url=http://bit.ly/afalQU]more[/url])[/i]"],["t","I shortened the URL since the signature can only contain 300 characters. Also, can we get some color on the news warning? It's not very noticeable."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9563#msg9563"},{"f":"knightmb","d":1281911423,"b":[["t","I can build a block chain to the desired number using a combo of the old block chain and a client with the latest block chain (minus the bad stuff), what number should I shot for?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9564#msg9564"},{"f":"kencausey","d":1281911467,"b":[["t","74637 is the last good block"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9565#msg9565"},{"f":"knightmb","d":1281911643,"b":[["q","74637 is the last good block","Quote from: kencausey on August 15, 2010, 10:31:07 PM"],["t","Ok, good, I've relabeled the old block chain on my site, I'll try to get as close to that number as I can. Basically, I'm just loading up two clients, one with the old chain, another with the sorta bad chain at the end. I'm going to let the first client get as close to the number as I can before stopping it. Then snapshot off that block chain. Since it does about 500 at a time, I'll probably be able to get it close to 74,501"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9566#msg9566"},{"f":"BitLex","d":1281911748,"b":[["t","i'v got one of a w7-machine count 74602, if that helps."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9567#msg9567"},{"f":"NewLibertyStandard","d":1281912295,"b":[["q","I already said that I have it right at 74637.\n\nSatoshi said it needs to be before 74,000","Quote from: davidonpda on August 15, 2010, 10:41:29 PM"],["t","So long as a the person who creates it has a patched client and downloads the whole chain, optimally from another computer on their local network, then it should stop at the right place automatically."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9570#msg9570"},{"f":"BitLex","d":1281912767,"b":[["q","Satoshi said it needs to be before 74,000","Quote from: davidonpda on August 15, 2010, 10:41:29 PM"],["t","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.\n\njust wanted to save knightmb some time, but yours is bigger than mine anyway.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9571#msg9571"},{"f":"satoshi","d":1281913088,"b":[["t","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.\n\ntcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago.\n\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.\n\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\n\nThe 0.3.10 linux build will have the -4way option when I build it.\n\nHere are the patch downloads for Windows:\n\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe\nhttp://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip\n\nSHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe\nSHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip\n\nSteps:\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.\n\nOr if you don't want to mess with downloading blk files, you can just do this:\n\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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9573#msg9573","s":1,"n":372,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/372/"},{"f":"knightmb","d":1281913144,"b":[["t","Yeah, a little confusing  Huh\n\nSo I don't need to create one, or do I need to take what you guys already have and just throw it up on the FTP?\n\nCan you dump block data from a windows machine onto a Linux/Mac machine?\n\n[edit] 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.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9574#msg9574"},{"f":"NewLibertyStandard","d":1281913171,"b":[["t","I can't stand the suspense! Do any Jr. Members or higher happen to have an unofficial SVN rev 134 Linux 64-bit build compiled that they'd be willing to share? Yeah, I know the official build is about to be released in a few minutes. It's not terribly important.\n\nEdit: Updated the SVN version number as per satoshi's comment a moment ago.\n\nAh, never mind. Since the SVN version was just updated and the Windows builds were just released, I'll wait. Embarrassed"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9575#msg9575","sj":"Oh the Suspense!"},{"f":"satoshi","d":1281914244,"b":[["q","[edit] 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.  Wink","Quote from: knightmb on August 15, 2010, 10:59:04 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9576#msg9576","s":1,"n":373,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/373/"},{"f":"kencausey","d":1281914314,"b":[["t","I just used your old file knightmb and on a rather old system it didn't take me very long to catch up, so I'm inclined to say \"don't bother\"."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9577#msg9577"},{"f":"theymos","d":1281914466,"b":[["q","What block number is it?","Quote from: satoshi on August 15, 2010, 11:17:24 PM"],["t","It's around 67k. It only took me about 3 minutes to get to the current block."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9578#msg9578"},{"f":"HostFat","d":1281915163,"b":[["t","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 Smiley\nNow everyone have always to check the website, and I think that this is bad."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9582#msg9582"},{"f":"knightmb","d":1281915339,"b":[["t","Cool, works for me!  Grin"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9583#msg9583"},{"f":"satoshi","d":1281915370,"b":[["t","Starting at 67000 is perfect.  \n\nYeah, at the moment you'll stop at 74638.  It should start slowly creeping up as more nodes upgrade and generate.\n\nLinux build links below.\n\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.\n\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\n\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"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9584#msg9584","s":1,"n":374,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/374/"},{"f":"satoshi","d":1281915427,"b":[["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 Smiley\nNow everyone have always to check the website, and I think that this is bad.","Quote from: Joozero on August 15, 2010, 11:32:43 PM"],["t","Agree, wanted to do that for a long time, haven't had time to do it.\n\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.\n\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9586#msg9586","s":1,"n":375,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/375/"},{"f":"knightmb","d":1281915460,"b":[["q","> Quote from: knightmb on August 15, 2010, 10:59:04 PM\n> [edit] 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.  Wink\nJust 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.","Quote from: satoshi on August 15, 2010, 11:17:24 PM"],["t","I've put the block number with the file, so you'll know exactly where each stops at. \n\nBitCoinBlocks_Linux_67309.zip\nBitCoinBlocks_Windows_67300.zip\n\nI've leave them be. Glad to know I could help  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9587#msg9587"},{"f":"kencausey","d":1281915926,"b":[["q","... It already is on block 74638. I assume that means that block is now a good one?","Quote from: davidonpda on August 15, 2010, 11:31:37 PM"],["t","I had some confusion on this myself and got clarification in #bitcoin-dev:\n\nThe bad block was number 74638, the last good one was 74637.  The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9588#msg9588"},{"f":"HostFat","d":1281916078,"b":[["q","Agree, wanted to do that for a long time, haven't had time to do it.\n\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.\n\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list","Quote"],["t","Good Cheesy\n\nAnyway I usually check the website, I was thinking to a solution for newbie-users ( that they are more to come on future )\nA small bug can be a big problem with a network with a lot of newbie and/or not-informed users. ( and none of them will ever give a look to a source like this: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Tongue )\n\n( sorry for my english, I hope you are still understanding me Grin )"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9589#msg9589"},{"f":"kencausey","d":1281916776,"b":[["t","Updated and combined instructions:\n\n1.  Stop generating immediately, close your current client if you have not updated to 0.3.10.\n\n2.  Download 0.3.10:\n\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\n\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\n\n3. (optional)  Download a previously known good blockchain:\n\nhttp://knightmb.dyndns.org/files/bitcoin/blocks/\nhttp://rapidshare.com/files/413168038/BitcoinBlocks.torrent\n\nand replace your blk0001.dat and blkindex.dat files with those from the relevant download for your platform.\n\n3b.  If you don't download, delete or move the blk0001.dat and blkindex.dat files.\n\n4.  Start 0.3.10 and watch it catch up to block 74637 and beyond and help restart things.\n\nEdit:\nEdit 2: Add more explanation\n\n4b.  Currently the network has a combination of good and bad nodes (those running versions older than 0.3.10).  If you only connect to nodes running old versions, you will be stuck at 74638 blocks.  You can fix this by running the client with the options \"-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14\".  This specifically connects you to a number of 'known good' nodes and ensures that you receive transactions generated within the network of updated clients.  As the number of out of date clients in the network decreases, this will become unnecessary.  If you want more nodes or just different ones, you can find a larger list at http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodes ."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9595#msg9595"},{"f":"BitLex","d":1281917556,"b":[["t","my forwarded node counts 74642 as i type (36conn.),\n3 other nodes are still at 74638 (8conn. each)"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9602#msg9602"},{"f":"NewLibertyStandard","d":1281918059,"b":[["t","Ya know, in a way, this actually temporarily decreases the difficulty to generate blocks until everyone upgrades. Yeah, it'll be slower, but that just gives each client more time to try to generate the difficult hash."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9606#msg9606"},{"f":"Ground Loop","d":1281918595,"b":[["t","Question about fallout:  I had a transaction that I submitted after the bad block, using the bad block chain.\n\nWhat is the status of that transaction?\nFrom what I can tell, my (updated) sending client wallet shows the deducted amount.\n\nWill it get reincorporated into the fixed chain, and will the recipient be able to spend it?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9609#msg9609"},{"f":"kosovito","d":1281919157,"b":[["t","I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9615#msg9615"},{"f":"satoshi","d":1281920445,"b":[["q","Question about fallout:  I had a transaction that I submitted after the bad block, using the bad block chain.\n\nWhat is the status of that transaction?\nFrom what I can tell, my (updated) sending client wallet shows the deducted amount.\n\nWill it get reincorporated into the fixed chain, and will the recipient be able to spend it?","Quote from: Ground Loop on August 16, 2010, 12:29:55 AM"],["t","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.\n\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. "]],"u":"https://bitcointalk.org/index.php?topic=823.msg9623#msg9623","s":1,"n":379,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/379/"},{"f":"satoshi","d":1281920544,"b":[["q","I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?","Quote from: kosovito on August 16, 2010, 12:39:17 AM"],["t","If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes.  \n\nFor today, try adding these parameters: \n-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14\n\nSee\nhttp://bitcointalk.org/index.php?topic=828"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9624#msg9624","s":1,"n":380,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/380/"},{"f":"GoldRush","d":1281920555,"b":[["t","Most people running clients are not reading this message thread.  So...  Silly questions:\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9625#msg9625"},{"f":"kencausey","d":1281920773,"b":[["t","I added the addnode options and info about the 'stuck at 74638 blocks' issue at http://bitcointalk.org/index.php?topic=823.msg9595#msg9595"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9627#msg9627"},{"f":"satoshi","d":1281921125,"b":[["q","Most people running clients are not reading this message thread.  So...  Silly questions:\n\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?","Quote from: trebronics on August 16, 2010, 01:02:35 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9628#msg9628","s":1,"n":381,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/381/"},{"f":"Ground Loop","d":1281924127,"b":[["q","Ya know, in a way, this actually temporarily decreases the difficulty to generate blocks until everyone upgrades. Yeah, it'll be slower, but that just gives each client more time to try to generate the difficult hash.","Quote from: NewLibertyStandard on August 16, 2010, 12:20:59 AM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9632#msg9632"},{"f":"satoshi","d":1281924970,"b":[["t","The bad chain is also slowed down as more nodes upgrade.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9642#msg9642","s":1,"n":382,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/382/"},{"f":"knightmb","d":1281925325,"b":[["t","I'm chucking as much CPU at this as I can.  Yeah, bit of an unfair advantage I guess until everyone upgrades.  Lips sealed\nMy wife's PC already generated 2 of the new blocks (LOL), luck is on her side I guess."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9644#msg9644"},{"f":"lachesis","d":1281925737,"b":[["q","... Of the nodes I'm connected to, more than half are already 0.3.10. ...","Quote from: satoshi on August 16, 2010, 02:16:10 AM"],["t","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)."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9646#msg9646"},{"f":"satoshi","d":1281926301,"b":[["t","On Windows, findstr /c:\"version message\" debug.log\n\nIt looks like the bad chain was on block 74678 recently.  Can't wait to overtake it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9648#msg9648","s":1,"n":383,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/383/"},{"f":"bdonlan","d":1281926395,"b":[["q","The bad chain is also slowed down as more nodes upgrade.\n\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.","Quote from: satoshi on August 16, 2010, 02:16:10 AM"],["t","I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9649#msg9649"},{"f":"mizerydearia","d":1281927000,"b":[["q","4b.  Currently the network has a combination of good and bad nodes (those running versions older than 0.3.10).  If you only connect to nodes running old versions, you will be stuck at 74638 blocks.  You can fix this by running the client with the options \"-addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=76.235.234.64 -addnode=74.137.15.169 -addnode=68.68.99.14\"","Quote from: kencausey on August 15, 2010, 11:59:36 PM"],["t","http://www.bitcoin.org/wiki/doku.php?do=show&id=74638_nodes"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9652#msg9652"},{"f":"NewLibertyStandard","d":1281928192,"b":[["q","> Quote from: satoshi on August 16, 2010, 02:16:10 AM\n> The bad chain is also slowed down as more nodes upgrade.\n>\n> We'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.\nI think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/","Quote from: bdonlan on August 16, 2010, 02:39:55 AM"],["t","We want to keep the older clients connected so that when the correct chain overtakes the incorrect chain, they will switch back to the correct chain. Although I don't know the specifics of how far back in the chain the old chain will accept a branched chain."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9657#msg9657"},{"f":"knightmb","d":1281931059,"b":[["q","> Quote from: bdonlan on August 16, 2010, 02:39:55 AM\n> > Quote from: satoshi on August 16, 2010, 02:16:10 AM\n> > The bad chain is also slowed down as more nodes upgrade.\n> >\n> > We'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.\n> I think it'd probably be a good idea still to come out with another version that rejects connections from older versions - otherwise the network might remain rather fragmented for a while. :/\nWe want to keep the older clients connected so that when the correct chain overtakes the incorrect chain, they will switch back to the correct chain. Although I don't know the specifics of how far back in the chain the old chain will accept a branched chain.","Quote from: NewLibertyStandard on August 16, 2010, 03:09:52 AM"],["t","The old clients should accept it all the way back to the last snapshot of release, so this being found so quickly and so long after the last release, it should work in theory. Here's a good test of the theory  Grin"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9668#msg9668"},{"f":"Ground Loop","d":1281935270,"b":[["q","> Quote from: Ground Loop on August 16, 2010, 12:29:55 AM\n> Question about fallout:  I had a transaction that I submitted after the bad block, using the bad block chain.\n>\n> What is the status of that transaction?\n> From what I can tell, my (updated) sending client wallet shows the deducted amount.\n>\n> Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?\nRight, 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.\n\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.","Quote from: satoshi on August 16, 2010, 01:00:45 AM"],["t","Interesting.. fascinating to watch this work its way through the bowels of the system.\nIt was block 73746 that I generated.\n    CTxOut(nValue=50.00000000, scriptPubKey=0x8DDD5C7DADB2D43AC5F186)\n08/12/10 02:35 generated 50.00\n\nAnd I sent 49.00 of it to 19Nzg21hQQDAY5GTdTTuUVPA4MaE7AusXz (using the broken chain)\n\nNow I'm waiting for that node to figure out it was received, and it's using the new chain."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9682#msg9682"},{"f":"satoshi","d":1281963578,"b":[["t","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.\n\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.\n\nThanks to everyone for the quick response!"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9734#msg9734","s":1,"n":387,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/387/"},{"f":"throughput","d":1281969310,"b":[["t","Would it be useful to have RPC command to chop off the tail of the chain manually,\ninstead of removind and redownloading the whole chain?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9746#msg9746"},{"f":"laszlo","d":1281996780,"b":[["t","So at this point, would a client that has not upgraded also have the correct chain?"]],"u":"https://bitcointalk.org/index.php?topic=823.msg9833#msg9833"},{"f":"NewLibertyStandard","d":1281996932,"b":[["q","So at this point, would a client that has not upgraded also have the correct chain?","Quote from: laszlo on August 16, 2010, 10:13:00 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9834#msg9834"},{"f":"satoshi","d":1281999295,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=823.msg9841#msg9841","s":1,"n":395,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/395/"}]},{"id":"p186","k":"p","s":"bitcointalk","t":"Version 0.3.10 - block 74638 overflow PATCH!","u":"https://bitcointalk.org/index.php?topic=827","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/186/","m":[{"f":"satoshi","d":1281916102,"b":[["t","Version 0.3.10 patches the block 74638 overflow bug.   http://bitcointalk.org/index.php?topic=823\n\nThe Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's.  Try the \"-4way\" switch to enable it and check if it's faster for you. \n\nDownload from sourceforge:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/\n\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\nSHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip\n\nIt is no longer necessary to delete blk*.dat.  The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain."]],"u":"https://bitcointalk.org/index.php?topic=827.msg9590#msg9590","s":1,"n":376,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/376/"}]},{"id":"p187","k":"p","s":"bitcointalk","t":"0.3.10.1 Question on where block should be","u":"https://bitcointalk.org/index.php?topic=828","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/187/","m":[{"f":"Anonymous","d":1281917358,"b":[["t","adg"]],"u":"https://bitcointalk.org/index.php?topic=828.msg9601#msg9601","sj":"sfg"},{"f":"BitLex","d":1281917629,"b":[["q","my forwarded node counts 74642 as i type (36conn.),\n3 other nodes are still at 74638 (8conn. each)","Quote from: BitLex on August 16, 2010, 12:12:36 AM"],["t","the port-forwarded isnt a fast one though, limited to one core at about 700khash/s."]],"u":"https://bitcointalk.org/index.php?topic=828.msg9603#msg9603"},{"f":"theymos","d":1281917880,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=828.msg9605#msg9605"},{"f":"satoshi","d":1281918508,"b":[["t","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.\n\nIt'll help if you port forward so you can get lots of connections."]],"u":"https://bitcointalk.org/index.php?topic=828.msg9608#msg9608","s":1,"n":377,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/377/"},{"f":"satoshi","d":1281919040,"b":[["t","For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP?  Then we can -addnode= them and make sure to connect to at least one 0.3.10 node."]],"u":"https://bitcointalk.org/index.php?topic=828.msg9612#msg9612","s":1,"n":378,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/378/"}]},{"id":"p188","k":"p","s":"bitcointalk","t":"[PATCH] Automatic block validation","u":"https://bitcointalk.org/index.php?topic=832","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/188/","m":[{"f":"bdonlan","d":1281927475,"b":[["t","I've written a patch to help automatically validate cached blocks after validation fixes such as the one that was pushed out today. You can find it at\n\nhttp://fushizen.net/~bd/blockverify.patch\n\nor\n\nhttp://github.com/bdonlan/bitcoin/commit/b205251959448ca99123f2bc95b088bf06d4ef3b\n\nUpon first run with this patch, all blocks will be verified, and any invalid blocks, as well as blocks orphaned by removal of such blocks, will be removed from the block index. A version stamp\n(BLOCK_VERIFY_TOKEN in db.cpp) will be then written to the db; this will cause the next run to skip the verification pass. Any future validation fixes can then simply bump BLOCK_VERIFY_TOKEN to force a revalidation of the block chain.\n\nNote that I may be missing some important steps when deleting the old blocks - in particular, no attempt is made to update the wallet, or to prune stored uncommitted transactions. Review would be helpful."]],"u":"https://bitcointalk.org/index.php?topic=832.msg9654#msg9654"},{"f":"bdonlan","d":1281933190,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=832.msg9673#msg9673"},{"f":"satoshi","d":1281972354,"b":[["t","That's a difficult approach.\n\nWe need to cause a reorg, which will disconnect the invalid chain.\n\nThis is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.\n\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)\n\nThis isn't perfect yet.  It still needs to receive one valid block to trigger the reorg.  \n\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."],["c","bool CTxDB::LoadBlockIndex()\n{\n    ...\n\n    // Verify blocks in the main chain\n    vector<CBlockIndex*> vChain;\n    for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)\n    {\n        vChain.push_back(pindex);\n        CBlock block;\n        if (!block.ReadFromDisk(pindex))\n            return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\n        if (!block.CheckBlock())\n        {\n            bnBestChainWork = pindex->pprev->bnChainWork;\n            foreach(CBlockIndex* pindex2, vChain)\n                pindex2->bnChainWork = 0;\n        }\n    }\n\n    return true;\n}"]],"u":"https://bitcointalk.org/index.php?topic=832.msg9754#msg9754","s":1,"n":389,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/389/"},{"f":"satoshi","d":1281978482,"b":[["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.","Quote from: satoshi on August 16, 2010, 03:25:54 PM"],["t","This is what I ended up doing in SVN rev 139.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=832.msg9775#msg9775","s":1,"n":392,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/392/"}]},{"id":"p189","k":"p","s":"bitcointalk","t":"checkpointing the block chain","u":"https://bitcointalk.org/index.php?topic=834","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/189/","m":[{"f":"mkrogh","d":1281951623,"b":[["t","Hi\n\nI think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.\n\nThis is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.\n\nIf a small country, say Luxembourg, started a bitcoin instance for  themselves, they would never know if the German or French government would be hiding a longer chain,\njust in case.\n\nIf a large bank wanted to disturb the current bitcoin system, they could just spend more CPU power than the current system, start from scratch and generate a completely new chain. They could intervene at any point including the beginning. All work so far would be invalidated. \n\nIf a village wanted a small local payment system, they would constantly be in danger of attacks. The mafia could execute a lot of double spending, and then suddenly arrive with a long chain that invalidated all their payments, even though the merchants thought they had acquired the coins.\n\nAnyone, bar the largest most high powered instances of bitcoin, will have this constant threat hanging over them.\n\nThe issue appears with network splits as well. After rejoining, one part completely ruins the other part, especially for coins that were present on both sides of the split to start with.\n\nI think, there should be some guarantee that the chain will not be invalidated further back in time than a day, a month, or 100 blocks or whatever.\n\nThis problem is related to the problem of how many blocks you want to see before accept a payment (double spending problem). Satoshi has a calculation of this in the\npdf file. However, you need to know the CPU power of the visible honest part relative to the other part (p and q). The problem is that you never know how large the dishonest, or invisible, part is, because it can be hidden as long it wants to. Or it can be formed in the future. You never know.\n\nWhat about this proposal? A node checkpoints blocks that are older than some threshold. The threshold could be a difficulty weighted block count, say a 100 blocks of 8 zero\nbits. If a node receives a block chain that requires changing something that is older than its checkpoint, it refuses the chain. Each node would have its own checkpoint. But the honest nodes would be close. Their deviation would be small compared to the size of the threshold (100 blocks).\n\nWhat would happen when two nodes disagree further back in time than the threshold of one of them. They should be considered forked currencies. One currency became two.\nSo the village, or Luxembourg, could ignore a hidden outside world, except for the very last part of the block chain.\n\nThe small village could use a very low threshold. The latency within the village is milliseconds. The could have block generation every 10 seconds. They could have a threshold of 5 blocks for instance. There is no valid reason, for a node, to stay hidden for that long in the village. If a computer loses its connection, it will just download the chain when it get online again; if it will tries to push a long block chain down the throat of the rest of the village, it has effectively created a new currency for itself."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9712#msg9712"},{"f":"Red","d":1281974950,"b":[["t","There is some checkpointing in the code that works like that. But it is not dynamic. It only updates when the dev team decides to add a new check point. But that does validate your point.\n\nBut I learned there are some addition protections as well but I haven't read that code yet. Something like refusing chains if they change more that X hours work. It probably worth reviewing other threads to find it. Knightmb was involved in that discussion if it helps to find it."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9760#msg9760"},{"f":"lfm","d":1281975087,"b":[["q","I think it is a problem that you can never really trust that the chain will not be massively invalidated, and replaced by a longer one.\n\nThis is an issue for all but the largest instances of bitcoin. A global widespread bitcoin system wouldn't have this issue, but anyone else would.\n\nIf a small country, say Luxembourg, started a bitcoin instance for  themselves, they would never know if the German or French government would be hiding a longer chain, just in case.","Quote from: mkrogh on August 16, 2010, 09:40:23 AM"],["t","These are simply good reasons for not starting your own little separate independent bitcoin chain. For the best security stay with the main big chain. Instances such as yesterday's should be so rare you don't need to worry about them. The problem of being out powered by some other big entity is well understood and is minimized by staying with the biggest bitcoin chain there is.\n\nNote that the current bitcoin net is still tiny and you shouldn't really rely on it yet for anything serious in my opinion."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9762#msg9762"},{"f":"aceat64","d":1281975251,"b":[["t","1) The point of Bitcoin is to be a global currency, it doesn't make sense to use Bitcoin as a replacement for a national currency\n2) Block chain checkpoints are already done at each release of the client software\n3) To generate a longer chain from scratch doesn't require more power (CPU time) then the network currently has, it requires more power then the network has put into the chain since the start. The current chain has had unbelievable amounts of CPU time go into generating it."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9763#msg9763"},{"f":"mkrogh","d":1281979994,"b":[["q","1) The point of Bitcoin is to be a global currency, it doesn't make sense to use Bitcoin as a replacement for a national currency","Quote from: aceat64 on August 16, 2010, 04:14:11 PM"],["t","You can say that, but it would be nice to use it on a smaller scale. It is interesting to think about how to achieve this without making the system too vulnerable.\nCheckpoints could be one possibility. Maybe there are others."],["q","2) Block chain checkpoints are already done at each release of the client software\n[\\quote]\nA decentralized system does not have centralized upgrades, and there is no one program that everybody will use.\nDo you envision a global currency with only one client program?\nAnd where in the chain is the checkpoint placed exactly, and what node decides this.\n \n\n> Quote\n> 3) To generate a longer chain from scratch doesn't require more power (CPU time) then the network currently has, it requires more power then the network has put into the chain since the start. The current chain has had unbelievable amounts of CPU time go into generating it.\nOf course time matters. But, you don't know how long the hidden part has been working. And if it has more power, it will eventually have done more work as well. But I agree, that for one giant global system, this might not be a big issue.\n\nHow would people react if some governments declared that they didn't like the system, and would now start an independent chain to make all current coins worthless. That in itself might create a panic, and destroy the system. With more recent checkpoints, the system would be less speculative.\n\nLet me turn it around. With a global bitxoin system, what is a good reason that nodes can not freeze all blocks older than say 10 hours of accumulated difficulty. Where is the downside? Is it really considered a desired feature that a part of the network can be hidden for many hours and come back again with a long chain? Or is it just that checkpoints\nhaven't been implemented because the system is still so new?\n\nCheers.","Quote"]],"u":"https://bitcointalk.org/index.php?topic=834.msg9778#msg9778"},{"f":"aceat64","d":1281985520,"b":[["q","Let me turn it around. With a global bitxoin system, what is a good reason that nodes can not freeze all blocks older than say 10 hours of accumulated difficulty. Where is the downside? Is it really considered a desired feature that a part of the network can be hidden for many hours and come back again with a long chain? Or is it just that checkpoints\nhaven't been implemented because the system is still so new?","Quote from: mkrogh on August 16, 2010, 05:33:14 PM"],["t","Under such a system, a bad chain (such as the one we fixed yesterday) would get locked in if it lasted more then 10 hours. I'm sorry, but automatic checkpoints are a bad idea."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9797#msg9797"},{"f":"mkrogh","d":1281988696,"b":[["t","What is a bad chain?\n\nCould you elaborate more on why checkpoints are bad?\n\n "]],"u":"https://bitcointalk.org/index.php?topic=834.msg9810#msg9810"},{"f":"satoshi","d":1281990053,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9816#msg9816","s":1,"n":394,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/394/","qt":["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."],"qc":["proof-of-work"]},{"f":"mkrogh","d":1281992087,"b":[["t","Satoshi, the checkpoint is not used to make a judgement of which chain is better, but just to make sure that very old coins will not be invalidated in the \"open\" part of the network.\n\nThe software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.\n\nIf a longer chain, predating the checkpoint arrived, the node would reject it. This would effectively fork the currency, but so what. In practice, it would just exclude the hidden\npart. The \"honest\" part would continue along. Too bad for those with a long hidden chain. But they chose to be offline for too long.\n\nThe network, I see, is one of a lot of online nodes, visible to anyone who wants to see them. This is the core of the network. They will communicate so often, that no one will get 1000 blocks ahead of others. They will transmit their results continously, not collect them in a batch of 1000 blocks.\n\nThen there are potential offline nodes, dishonest nodes etc. If they suddenly show up with a very long chain, there is no reason not to reject them. Or I don't see that reason.\n\nThe public internet will never get fragmented, in a major way,for days. And bitcoin is not suitable for such a situation, even though you technically can make it so by erasing all blocks in all but one of the fragmented components after the rejoin. \n\nYou have a manual checkpoint, you say, which exactly shows that checkpoints are possible."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9822#msg9822"},{"f":"MoonShadow","d":1281993303,"b":[["q","The software could just declare that there is a checkpoint 1000 blocks back. This is an individual checkpoint for each node, and the checkpoints would move forward every time a new block arrives. The checkpoint could never move backwards.\n\nIf a longer chain, predating the checkpoint arrived, the node would reject it. ","Quote from: mkrogh on August 16, 2010, 08:54:47 PM"],["t","Rather than reject it, it could save a backup of the original and accept the new chain tentitively if it's moving back more than, say, two weeks.  So about 2000 blocks.  And it could also notify the user that it has a new blockchain that reports a reversal of fortune so far back, and give the user the chance to find out about it before accepting the new blockchain.  Odds are that if the user doesn't know what is happening, he soon will since every other user paying attention at the time will also know there is something to look into.  Bitcoin is a very well automated system, but absolute automation is not often wise.  Talented support needs to know that something is broken asap.  This is another example of a 'watchdog' process and/or function that could add security to the network.  I think that, even though this should have been submitted to the test network, the release of this mal-formed transaction has highlighted an issue fairly early in the lifespan of Bitcoin.  Which allowed the small community to respond to it quickly and effectively.  This would become much harder to do in the future, if many people start using it, since most of them will not be programmers, and many won't be paing the level of attention to the client as the beta system currently needs."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9824#msg9824"},{"f":"NewLibertyStandard","d":1281998548,"b":[["t","The checksum is just the hash at a single particular block such that new chains can be started and can grow, but once a client with the checksum included reaches that block block number, it won't accept any hash except the checksum.\n\nIs that correct?\n\nSo if someone wanted to create an alternative chain with the same genesis block, they would need to checksum a block after the genesis with a different hash before they connected to the live network. If they ever reached the checksum in the official client, they would need to make sure that checksum was not included in their own Bitcoin client.\n\nHow is the strength of the chain calculated? Is it length and checksum only or does it measure a single block at difficulty 500 as more valid than ten blocks at difficulty one? I presume that it's probably length and checksum only which would mean that all transactions before the checksum are pretty well safe forever, but blocks after the checksum are only as strong as the current strength of the network until the next checksum comes along."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9839#msg9839"},{"f":"satoshi","d":1281999708,"b":[["q","How is the strength of the chain calculated?","Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM"],["t","Total proof-of-work."]],"u":"https://bitcointalk.org/index.php?topic=834.msg9843#msg9843","s":1,"n":396,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/396/"}]},{"id":"p190","k":"p","s":"bitcointalk","t":"blocks minus 1","u":"https://bitcointalk.org/index.php?topic=837","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/190/","m":[{"f":"satoshi","d":1281974365,"b":[["t","I'd like to reduce the number of blocks displayed in the status bar by 1.   When you first load the program, it'll display 0 blocks instead of 1:\n\"0 connections    0 blocks     0 transactions\"\n\nIt's always been \"nBestHeight + 1\" because it's counting the genesis block.  Technically, yes, the genesis block is a block.  It's a hardcoded block that you start out with.  You can't not have the genesis block.  Maybe think of it as a reference coin that you measure other coins against.  The block count people are looking for is the number of blocks they've downloaded.\n\nThe main benefit is that blocks will be equal to the block number of the current best block.  If blocks is 10, then the highest block number you have is 10.  It means you have block 10 and you don't have block 11.\n\nIt would reduce the confusion we had here:"],["q","> Quote from: davidonpda on August 15, 2010, 11:31:37 PM\n> ... It already is on block 74638. I assume that means that block is now a good one?\n\nI had some confusion on this myself and got clarification in #bitcoin-dev:\n\nThe bad block was number 74638, the last good one was 74637.  The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one.","Quote from: kencausey on August 15, 2010, 11:45:26 PM"]],"u":"https://bitcointalk.org/index.php?topic=837.msg9757#msg9757","s":1,"n":390,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/390/"},{"f":"ByteCoin","d":1281974688,"b":[["t","Agreed. Seems like a change for the better."]],"u":"https://bitcointalk.org/index.php?topic=837.msg9758#msg9758"},{"f":"Tilka","d":1281976464,"b":[["t","+1\n\nOfftopic: Does this forum have some kind of upvote plugin or something?"]],"u":"https://bitcointalk.org/index.php?topic=837.msg9768#msg9768"},{"f":"Insti","d":1281977691,"b":[["q","+1","Quote from: Tilka on August 16, 2010, 04:34:24 PM"],["t","+1"],["q","Offtopic: Does this forum have some kind of upvote plugin or something?","Quote"],["t","+1"]],"u":"https://bitcointalk.org/index.php?topic=837.msg9772#msg9772"},{"f":"satoshi","d":1281978387,"b":[["t","Done in SVN rev 137"]],"u":"https://bitcointalk.org/index.php?topic=837.msg9774#msg9774","s":1,"n":391,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/391/"}]},{"id":"p191","k":"p","s":"bitcointalk","t":"Checking the block chain on load","u":"https://bitcointalk.org/index.php?topic=841","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/191/","m":[{"f":"satoshi","d":1281989266,"b":[["t","SVN rev 139 does a basic check of the block chain after loading.\n\nWith this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork.  There wasn't time to do a careful implementation of this at the time.\n\nIt might take longer than we want, since it has to load all the blocks.  If it's too slow, we could have it only go back to a certain block number."]],"u":"https://bitcointalk.org/index.php?topic=841.msg9813#msg9813","s":1,"n":393,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/393/"},{"f":"Insti","d":1281991399,"b":[["t","I assume it will take more than 1 second to do.\nDo we have to do this every time it starts up Sad\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=841.msg9820#msg9820"},{"f":"satoshi","d":1282156108,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=841.msg10082#msg10082","s":1,"n":399,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/399/"}]},{"id":"p192","k":"p","s":"bitcointalk","t":"Bitcoins are most like shares of common stock","u":"https://bitcointalk.org/index.php?topic=845","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/192/","m":[{"f":"epaulson","d":1282070718,"b":[["t","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.\n\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.).\n\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.\n\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).\n\nIn essence, Bitcoins are like a \"direct public offering\" of stock in the Bitcoin enterprise."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9937#msg9937"},{"f":"Red","d":1282072315,"b":[["t","I want to be the first to say \"No, they are not!\"\n\nI'll edit this to support that statement later. :-)\n\n--- Edit ---\n\nIt is very important to any new venture to NOT define it in terms of a well known scam. No one here would say bitcoin is like a Ponzi scheme except without the scam part.\n\nBut that is what you are doing by saying, it's like issuing stock in a corporation, except without all that bother of actually creating a product. Let's just consider the stock the product and get right to selling it! It's a limited edition product, so its price will vary based upon supply and demand.\n\nTrust me, that metaphor has been used for thousands of scams. It is equivalent to a \"red flag\" warning to all authorities.\n\nYou are really much better saying bitcoins are like sets of collectable poker chips. Some people will want them, some will not. If lots of people want them you can sell each poker chip separately."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9940#msg9940"},{"f":"bytemaster","d":1282073227,"b":[["t","This is by far the best way to think about bit coins.  It clearly explains why they have value, where the value comes from (productive employee/owners).  \n\nThe only reason not to think about it this way is legal issues regarding issuing stock.   But this is the fundamental problem with all regulations, there are always \"multiple ways to think about the same thing\".  Changing the description does not change the nature of things though."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9943#msg9943"},{"f":"bytemaster","d":1282073726,"b":[["t","Stock represents a \"share\" of ownership where the sum of all shares equals 100%\n\nThus each bitcoin represents a percentage of the total.\n\nBit coins have a \"market cap\" of $1.38M\n\nThe only \"moral\" inflation is a \"stock split\". "]],"u":"https://bitcointalk.org/index.php?topic=845.msg9944#msg9944"},{"f":"Red","d":1282074169,"b":[["q","Bit coins have a \"market cap\" of $1.38M","Quote from: bytemaster on August 17, 2010, 07:35:26 PM"],["t","1.38M BTC right? It is much less in USD at the moment I think."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9946#msg9946"},{"f":"MoonShadow","d":1282075095,"b":[["q","I 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.).","Quote from: epaulson on August 17, 2010, 06:45:18 PM"],["t","This is not quite right either, I think.  However, I have heard the explaination that the US FRN is akin to a national stock with a reverse dividend, so if this manner of thinking about it helps some people wrap their heads around it, then I won't object.  That is, other than to say that this is an analogy only.\n\nPersonally, I don't think that there is anything we really can compare Bitcoins to that anyone really would have any prior experience with.  Bitcoin is something altogether new in the realm of trade.  It is a solution to a set of problems, and (potentially) serves as a solution well.  I don't, personally, think that it's a good idea to compare Bitcoin to *anything*.  Expecially since most people, including most people that seem to post often on this forum, lack a true understanding of what these other comparitive things are.  The best thing to say to describe Bitcoin is to talk about *Bitcoin*, and accurately describe how the system works as well as what it was designed to accomplish. \n\nThink about this, children have experience with money very young, but have you ever tried to explain what money actually is to a child?  Complete understanding of a monetary system is not a requirement of it's successful use."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9954#msg9954"},{"f":"FreeMoney","d":1282075713,"b":[["q","> Quote from: bytemaster on August 17, 2010, 07:35:26 PM\n> Bit coins have a \"market cap\" of $1.38M\n\n1.38M BTC right? It is much less in USD at the moment I think.","Quote from: Red on August 17, 2010, 07:42:49 PM"],["t","Yeah, I don't know where he got that from.\n\n3.75M BTC have been \"released\" The \"marginal bitcoin\" is trading for about 7 cents right now. I don't really know if it's useful to multiply those numbers together, but if you do you don't get $1.38M anyway."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9966#msg9966"},{"f":"Red","d":1282083374,"b":[["t","Edited above and reposted so you don't have to look up.\n\nI really wanted pride of place on this one.\n\n------------\n\nIt is very important to any new venture to NOT define it in terms of a well known scam. No one here would say bitcoin is like a Ponzi scheme except without the scam part.\n\nBut that is what you are doing by saying, it's like issuing stock in a corporation, except without all that bother of actually creating a product. Let's just consider the stock the product and get right to selling it! It's a limited edition product, so its price will vary based upon supply and demand.\n\nTrust me, that metaphor has been used for thousands of scams. It is equivalent to a \"red flag\" warning to all authorities.\n\nYou are really much better saying bitcoins are like sets of collectable poker chips. Some people will want them, some will not. If lots of people want them you can sell each poker chip separately."]],"u":"https://bitcointalk.org/index.php?topic=845.msg9987#msg9987"},{"f":"bytemaster","d":1282091723,"b":[["t","$0.06 per BTC   * 23,000,000 total potential shares = $1.38M market cap.   Most shares are held by the \"corporation\" which is exchanging them for processing power over time.   \n\nThis is just one way of looking at the coins.   I contend that if some rich dude held 95% of all gold and he was selling gold for processing time at a fixed rate that it would not be considered monetary inflation any more than an individual with 1% of all gold in saving deciding to spend it.   The fact that this \"rich dude\" is the the bitcoin algorithm does not change the fact that there are only 23,000,000 possible BTC.\n\n   "]],"u":"https://bitcointalk.org/index.php?topic=845.msg9998#msg9998"},{"f":"MoonShadow","d":1282093624,"b":[["q","$0.06 per BTC   * 23,000,000 total potential shares = $1.38M market cap.   Most shares are held by the \"corporation\" which is exchanging them for processing power over time.   \n\nThis is just one way of looking at the coins.   I contend that if some rich dude held 95% of all gold and he was selling gold for processing time at a fixed rate that it would not be considered monetary inflation any more than an individual with 1% of all gold in saving deciding to spend it.   The fact that this \"rich dude\" is the the bitcoin algorithm does not change the fact that there are only 23,000,000 possible BTC.","Quote from: bytemaster on August 18, 2010, 12:35:23 AM"],["t","Isn't the limit just shy of 21,000,000 possible BTC?"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10002#msg10002"},{"f":"FreeMoney","d":1282096027,"b":[["q","Isn't the limit just shy of 21,000,000 possible BTC?","Quote from: creighto on August 18, 2010, 01:07:04 AM"],["t","That's right. It is under 21M because amounts less than .00000001 get rounded away."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10004#msg10004"},{"f":"Red","d":1282098077,"b":[["t","Just for reference:\n\nMarket capitalization/capitalisation (often market cap) is a measurement of size of a business enterprise (corporation) equal to the share price times the number of shares outstanding (shares that have been authorized, issued, and purchased by investors) of a public company.\n\nI don't think the un-generated shares would be counted. They would be authorized shares, but they have not been issued through their IPO phase yet."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10010#msg10010"},{"f":"fresno","d":1282102811,"b":[["t","\"the US FRN is akin to a national stock with a reverse dividend,..\" ROTFLOL!\n\nI challenge this group to think simple!\n\nBitcoin is something we use, but Bitcoin is not the use! It is simply a machine. Don't give it names it doesn't deserve."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10022#msg10022"},{"f":"nelisky","d":1282128062,"b":[["q","\"the US FRN is akin to a national stock with a reverse dividend,..\" ROTFLOL!\n\nI challenge this group to think simple!\n\nBitcoin is something we use, but Bitcoin is not the use! It is simply a machine. Don't give it names it doesn't deserve.","Quote from: fresno on August 18, 2010, 03:40:11 AM"],["t","Bingo! I've been following this thread and others thinking to myself \"why the money obsession?\". Even those that argue on different economic philosophies compare to money, use money, use the lack of money, money, money, money...\n\nI compare Bitcoins to beans... when we played cards as kids we used beans as measure of wins / losses. We didn't trade it for money, we didn't play for \"make believe money\", we played for beans. It worked because we all agreed that beans where the game measure, and because there was a limited supply of them (in our game table, that is).\n\nIf we had some special engineered beans instead of Bitcoins, that took a full hour to produce a batch and for some quantic weirdness could only be produced one batch at a time in the whole universe, but anyone could try and grow them, we could use those instead of BTCs, with the obvious caveat of not being virtual, of course... They wouldn't be money, they would pretty much not have any value except for what you and your peers agree it had. It's the same. If I think you whispering 545 decimals from pi to my ear is worth me giving you a deed to my house, does that make pi, or it's value, a currency?"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10042#msg10042"},{"f":"fresno","d":1282140409,"b":[["q","I compare Bitcoins to beans... when we played cards as kids we used beans as measure of wins / losses. We didn't trade it for money, we didn't play for \"make believe money\", we played for beans. It worked because we all agreed that beans where the game measure, and because there was a limited supply of them (in our game table, that is).\n\nIf we had some special engineered beans instead of Bitcoins, that took a full hour to produce a batch and for some quantic weirdness could only be produced one batch at a time in the whole universe, but anyone could try and grow them, we could use those instead of BTCs, with the obvious caveat of not being virtual, of course... They wouldn't be money, they would pretty much not have any value except for what you and your peers agree it had...","Quote from: nelisky on August 18, 2010, 10:41:02 AM"],["t","You could trade beans for marbles or baseball cards, but they would be totally independent of the bean thing, right?"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10050#msg10050"},{"f":"Red","d":1282147330,"b":[["q","I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking.","Quote from: epaulson on August 17, 2010, 06:45:18 PM"],["t","I'd like to submit that I think the most apt description of bitcoin is that it is most like a Global Exchange Trading System (GETS) which is a variation on the LETS concept that isn't for hippies.\n\nDescriptively it differs because it's community is loosely knit and global rather than an intertwined small-town. As such, there can be no commonly trusted party to operate and monitor the system, so that function is trusted to redundancy and mathematics. (block list)\n\nLETS communities can rely on \"local knowledge\" of peoples historical behavior and intentions. As such it is perfectly reasonable for them to advance credit to people (negative balances) in certain situations. In a GETS community advanced knowledge of all parties and intentions is not practical or even preferred. As such, GETS operates on a zero credit policy. (no negative balances)\n\nAlso, since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit for accounting purposes. Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.\n\n----\nI think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10060#msg10060"},{"f":"MoonShadow","d":1282156027,"b":[["q","> Quote from: epaulson on August 17, 2010, 06:45:18 PM\n> I think the most apt description of Bitcoins is that they are shares of stock in this communal Bitcoin enterprise we are undertaking.\n\nI'd like to submit that I think the most apt description of bitcoin is that it is most like a Global Exchange Trading System (GETS) which is a variation on the LETS concept that isn't for hippies.\n\nDescriptively it differs because it's community is loosely knit and global rather than an intertwined small-town. As such, there can be no commonly trusted party to operate and monitor the system, so that function is trusted to redundancy and mathematics. (block list)\n\nLETS communities can rely on \"local knowledge\" of peoples historical behavior and intentions. As such it is perfectly reasonable for them to advance credit to people (negative balances) in certain situations. In a GETS community advanced knowledge of all parties and intentions is not practical or even preferred. As such, GETS operates on a zero credit policy. (no negative balances)\n\nAlso, since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit for accounting purposes. Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.\n\n----\nI think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy.","Quote from: Red on August 18, 2010, 04:02:10 PM"],["t","Well done, indeed!  I think that you have nailed it one the head.  A Global Exchange Trading System.  I think that you should write an expanded article along these lines, if you are willing, and post it both on the wiki and wherever else that you would like.  So that we can establish early that Bitcoin is a 'trading system' and *not* a currency (hard or otherwise) and *not* a commodity or intended to be traded  as such.\n\nAre you willing, Red?"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10081#msg10081"},{"f":"Red","d":1282160409,"b":[["q","Are you willing, Red?","Quote from: creighto on August 18, 2010, 06:27:07 PM"],["t","Wow! That is high praise from you Creighto!\n\nI'm willing to start a new thread about it. I'm also willing to contribute to the project. However, by nature I'm very lazy! I often fail to complete projects like this.\n\nHowever, should my laziness consume things, you've already demonstrated your aptitude for the project. After all, it was your analogy to begin with!\n\nCheers!"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10105#msg10105"},{"f":"fresno","d":1282239646,"b":[["q","... since GETS trade globally, there is no \"national currency\" that can be used for equivalence. As such, GETS defines it's own unit \"for accounting purposes\". Since this currency must necessarily vary against some national currencies, the LETS strict \"no interest\" principle cannot be preserved.\n\n----\nI think if people understood LETS they would intuitively understand GETS. The rest of the bitcoin details are just one possible GETS monetary policy.","Quote from: Red on August 18, 2010, 04:02:10 PM"],["t","Has anyone noticed that the FRN is exactly that, \"it's own unit for accounting purposes\"?\n\nThe lawful United States dollar is defined in law as 371 4/16th grains of silver. This has been slightly modified, but never repealed. The \"dollar\" is actually a unit of measure, you can look it up. Bet they didn't tell you that in school!\n\nThe Federal Reserve Note is \"denominated in dollars\", or as Red above states, they have defined their own unit for accounting purposes. Write the Fed a letter, press them on the subject. The will reply that the FRN is \"backed by the full faith and credit of the U.S. government.\" What they won't admit is that the FRN is NOT a U.S. dollar as defined in law. It is \"denominated\" as one only because you agree to the terms in commercial contract.\n\nWhy did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10268#msg10268"},{"f":"Insti","d":1282243564,"b":[["q","Has anyone noticed that the FRN is exactly that, \"it's own unit for accounting purposes\"?\n\nThe lawful United States dollar is defined in law as 371 4/16th grains of silver. This has been slightly modified, but never repealed. The \"dollar\" is actually a unit of measure, you can look it up. Bet they didn't tell you that in school!\n\nThe Federal Reserve Note is \"denominated in dollars\", or as Red above states, they have defined their own unit for accounting purposes. Write the Fed a letter, press them on the subject. The will reply that the FRN is \"backed by the full faith and credit of the U.S. government.\" What they won't admit is that the FRN is NOT a U.S. dollar as defined in law. It is \"denominated\" as one only because you agree to the terms in commercial contract.\n\nWhy did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others.","Quote from: fresno on August 19, 2010, 05:40:46 PM"],["t","I thought that it proved that we can use whatever words we want and define them however we want and just because 'they' use the word 'dollar' to mean something does not mean we can use a word spelled the same way to mean something completely different."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10273#msg10273"},{"f":"ichi","d":1282245670,"b":[["q","Why did we take this little tour? Because it illustrates that we can define our terms. And that it is foolish to use their terms -- money, cash, dollar, currency, and a crapload of others.","Quote from: fresno on August 19, 2010, 05:40:46 PM"],["t","So, fresno, do you consider \"GETS\" to be one of \"their terms\"?\n\nIf so, please share your preferred term for Bitcoin.  I have read your comment that you already did, and I'm too lazy to find it.  Please indulge me  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=845.msg10286#msg10286"},{"f":"fresno","d":1282252414,"b":[["q","I thought that it proved that we can use whatever words we want and define them however we want and just because 'they' use the word 'dollar' to mean something does not mean we can use a word spelled the same way to mean something completely different.","Quote from: Insti on August 19, 2010, 06:46:04 PM"],["t","Yes, we can in theory. But do we have the organization to defend our terms? Do we even agree on what those terms might be?\n\nWe have anonymity, and we're below their radar at the moment. But that will change as soon as they see us as a threat. If you haven't seen the wheels of justice grinding in all their hypocritical glory, you are ripe for an amazement. Any appeals to \"fairness\" are going to get you slapped down hard.\n\nI say the best way not to get shot at is to not be a target, and certainly not to donate the ammo. Don't claim to be money. It's that easy.\n\nichi: Why should I do your work for you? If you want to argue, then bring something to the table."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10307#msg10307"},{"f":"ichi","d":1282276294,"b":[["q","I say the best way not to get shot at is to not be a target, and certainly not to donate the ammo. Don't claim to be money. It's that easy.","Quote from: fresno on August 19, 2010, 09:13:34 PM"],["t","I can't imagine that governments would ignore Bitcoin just because it didn't claim to be money.  It's the fact that it can anonymously mediate exchanges (including exchanges with currencies) that makes it a threat.\n\nThe solution, IMHO, is careful design and implementation, not semantics (or pleading)."],["q","ichi: Why should I do your work for you? If you want to argue, then bring something to the table.","Quote from: fresno on August 19, 2010, 09:13:34 PM"],["t","OK, would one of y'all be so kind as to post a forum URL for the prior proposal?\n\nRe anonymity, many Bitcoin users seem far too unconcerned, IMHO."]],"u":"https://bitcointalk.org/index.php?topic=845.msg10365#msg10365"},{"f":"satoshi","d":1282927166,"b":[["t","Bitcoins have no dividend or potential future dividend, therefore not like a stock.\n\nMore like a collectible or commodity."]],"u":"https://bitcointalk.org/index.php?topic=845.msg11403#msg11403","s":1,"n":427,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/427/","qt":["Bitcoins have no dividend or potential future dividend, therefore not like a stock.\n\nMore like a collectible or commodity."],"qc":["bitcoin-economics"]}]},{"id":"p193","k":"p","s":"bitcointalk","t":"Difficulty: More nodes active, or faster nodes?","u":"https://bitcointalk.org/index.php?topic=846","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/193/","m":[{"f":"Ground Loop","d":1282073138,"b":[["t","The recent upticks in difficulty have been remarkable.  At 511.77, I've even stopped off those machines where I don't pay for marginal power consumption.  My calculation is that the wear/tear from elevated temperatures and full-speed fans has more risk and cost than the BTC value.   (You can question my math.)\n\nBut my question is this: Are we seeing the rise of mega-power machines, or just an exponential increase in the number of nodes?  That is, are the top-producing machines making leaps in power (over average), or are my machines still about average, just dwarfed by the number of participating machines?  Is there any way to tell? (node counts?)\n\nI totally understand that difficulty reflects the state-of-the-art in client khash improvements, but it's clear that my own computers also represent a rapidly diminishing part of the total network generation rate.  As the network gets larger, my chance of finding The Block every 10 minutes shrinks.  I'm thrilled, not bitter Smiley , but I'm curious to understand what has transpired over the past three weeks to make it so dramatic.\n\nCheers."]],"u":"https://bitcointalk.org/index.php?topic=846.msg9942#msg9942"},{"f":"lfm","d":1282074972,"b":[["q","The recent upticks in difficulty have been remarkable.  At 511.77, I've even stopped off those machines where I don't pay for marginal power consumption.  My calculation is that the wear/tear from elevated temperatures and full-speed fans has more risk and cost than the BTC value.   (You can question my math.)","Quote from: Ground Loop on August 17, 2010, 07:25:38 PM"],["t","This is just what one should naturally expect. Some people have more tolerance for the cost of mining than others."],["q","But my question is this: Are we seeing the rise of mega-power machines, or just an exponential increase in the number of nodes?  That is, are the top-producing machines making leaps in power (over average), or are my machines still about average, just dwarfed by the number of participating machines?  Is there any way to tell? (node counts?)","Quote"],["t","I'd guess both. There is Art with his GPUs who claims to have about %10 of the generating power.\n\nThen I see about 850 connections to the IRC channel. Not sure what its been like historically."]],"u":"https://bitcointalk.org/index.php?topic=846.msg9952#msg9952"},{"f":"MoonShadow","d":1282078271,"b":[["t","I would be willing to bet that someone used one of these...\n\nhttp://en.wikipedia.org/wiki/Field-programmable_gate_array\n\nto do this...\n\nhttp://www.springerlink.com/content/765kta4qr92daea8/\n\nwhich is something that I, myself, obviously has considered.  Whoever is doing it is probably representing a great deal of the current hash percentage, and hogging a pretty good amount of the new bitcoins.  Considering that up to four of these programmable arrays are used by modern ham radios for this...\n\nhttp://www.dsptools.com/Radio.htm\n\nand this...\n\nhttp://www.softrockradio.org/\n\nThe successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match.  It would look like a super-computer from our perspectives.  As a ham radio operator myself, I was aware of these devices, but I don't presently own any.  Even connected to my netbook over USB2, the khas/sec rate would be sick.  The program for these things are normally kept on the master computer's harddisk, and only take a few seconds to swap out; so a ham could use his software radio whenever he wants to, and then rewrite all of his FPGA's with the sha-256 algorithim before going to bed, and make money while he sleeps.\n\nAnother possibilty is that someone owned or bought one of these...\n\nhttp://www.via.com.tw/en/initiatives/padlock/features.jsp\n\nor some other cryptographic coproccesor on a daughtercard.\n\nI'm sure once Bitcoin takes off, anyone with enough of the coins to have a deep personal interest in the strength of the currency will be running clients with hardware exceleration for the sha-256 has function.\n\nThat also makes me wonder if there are PCI daughtercards with FPGA's on them yet.  The last time that I looked into them, they were only available as external setups."]],"u":"https://bitcointalk.org/index.php?topic=846.msg9973#msg9973"},{"f":"superbitcoin","d":1282080508,"b":[["t","block generation on the VIA C7:\n\nhttp://bitcointalk.org/index.php?topic=758.0"]],"u":"https://bitcointalk.org/index.php?topic=846.msg9980#msg9980"},{"f":"lfm","d":1282080794,"b":[["q","I would be willing to bet that someone used one of these Field-programmable gate array to do this...\n\nhttp://www.springerlink.com/content/765kta4qr92daea8/\n\nwhich is something that I, myself, obviously has considered.  Whoever is doing it is probably representing a great deal of the current hash percentage, and hogging a pretty good amount of the new bitcoins.","Quote from: creighto on August 17, 2010, 08:51:11 PM"],["t","..."],["q","The successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match.  It would look like a super-computer from our perspectives.","Quote"],["t","A lot of hand waving there. For some concrete numbers it quotes 53 MB/s and since we only hash 192 bytes at a time, you might think it would do 0.27 mhash/s (but it probably would be less) which is actually within the range of a desktop."],["q","Another possibility is that someone owned or bought one of these...\n\nhttp://www.via.com.tw/en/initiatives/padlock/features.jsp","Quote"],["t","Ya, someone might! They measure out about 1.5 mhash/s. There are many ordinary Intel or AMD CPUs can do much better than that (with a little more electric power input tho)."]],"u":"https://bitcointalk.org/index.php?topic=846.msg9981#msg9981"},{"f":"MoonShadow","d":1282081926,"b":[["q","> Quote\n> The successful coding of the sha-256 algorithim into a fpga and recoding of the bitcoin client's generation function to use one or more such fpga's would produce a khash per second rate that no desktop could match.  It would look like a super-computer from our perspectives.\n\nA lot of hand waving there. For some concrete numbers it quotes 53 MB/s and since we only hash 192 bytes at a time, you might think it would do 27 mhash/s (but it probably would be less) which I beleive is actually within the range of a desktop with a couple GPUs.","Quote from: lfm on August 17, 2010, 09:33:14 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=846.msg9983#msg9983"},{"f":"satoshi","d":1282154500,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=846.msg10076#msg10076","s":1,"n":398,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/398/"}]},{"id":"p194","k":"p","s":"bitcointalk","t":"New screenshots to the front page?","u":"https://bitcointalk.org/index.php?topic=850","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/194/","m":[{"f":"sirius","d":1282115815,"b":[["t","Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero."]],"u":"https://bitcointalk.org/index.php?topic=850.msg10033#msg10033"},{"f":"hugolp","d":1282119370,"b":[["q","Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero.","Quote from: sirius-m on August 18, 2010, 07:16:55 AM"],["t","You think Windows Aero is pretty?  Shocked"]],"u":"https://bitcointalk.org/index.php?topic=850.msg10035#msg10035"},{"f":"sirius","d":1282120513,"b":[["q","> Quote from: sirius-m on August 18, 2010, 07:16:55 AM\n> Do you think we could find some prettier screenshots to the bitcoin.org front page? Maybe Mac screenshot or Windows Aero.\n\nYou think Windows Aero is pretty?  Shocked","Quote from: hugolp on August 18, 2010, 08:16:10 AM"],["t","Better than XP"]],"u":"https://bitcointalk.org/index.php?topic=850.msg10038#msg10038"},{"f":"satoshi","d":1282150724,"b":[["t","Definitely.  The old screenshots of 0.1 are very outdated.\n\nWindows Aero is a good choice.  Windows is still the largest user group.  Mind what's behind it for the transparent parts.\n\nWhat to have displayed in the transaction list?  Not completely filled up with stuff, just a few things."]],"u":"https://bitcointalk.org/index.php?topic=850.msg10067#msg10067","s":1,"n":397,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/397/"}]},{"id":"p195","k":"p","s":"bitcointalk","t":"28 days without generation, i have 4200khash/s","u":"https://bitcointalk.org/index.php?topic=862","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/195/","m":[{"f":"kosovito","d":1282166435,"b":[["t","Hi. I know difficulty is high, but is normal having a machine with 4200khas/second Huh\n\nIn the past, i generated a bunch."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10128#msg10128"},{"f":"Insti","d":1282168607,"b":[["t","Have you upgraded to 0.3.10?\nWhat build are you running? (Downloaded/Self compiled)\nWhat architecture/OS?\nAre you usually a lucky/unlucky person?"]],"u":"https://bitcointalk.org/index.php?topic=862.msg10137#msg10137"},{"f":"kosovito","d":1282169357,"b":[["t","Yes, i always updated\nI run official downloaded build\nVista 64\nI think i am lucky\n\nthanks"]],"u":"https://bitcointalk.org/index.php?topic=862.msg10148#msg10148"},{"f":"Ground Loop","d":1282171582,"b":[["t","Statistically, you're not very lucky.  In fact, out of a hundred people, you would be one of the two least lucky ones.\n\nI suspect something is Not Right with your setup.  Either you're running an old version, firewalled, or somehow not keeping up with the block chain.  Are you at block 75040 or greater?\n\nI'm especially concerned that your 'span' of attempts has also covered lower difficulty eras.  That makes you even less lucky.\n\nThe last time I was that unlucky, I was running a broken 64-bit Linux build. Smiley\n "]],"u":"https://bitcointalk.org/index.php?topic=862.msg10156#msg10156"},{"f":"Willsway","d":1282171945,"b":[["t","I currently have a Core2Duo which is outperforming a i7 and several Quad Core machines even though they all get an equal opportunity to generate uninterrupted. I don't think we should underestimate the \"Luck\" factor. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=862.msg10160#msg10160"},{"f":"kosovito","d":1282172111,"b":[["t","Im not firewalled, also, i reinstalled many times bitcoin, every versión, i updated too. Also im in 75043 block\n\nThe worst thing about bitcoin (at least for me) is the fact you CANT test if all is fine, if youre generating coins without problems."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10161#msg10161"},{"f":"sgtstein","d":1282173359,"b":[["q","The worst thing about bitcoin (at least for me) is the fact you CANT test if all is fine, if youre generating coins without problems.","Quote from: kosovito on August 18, 2010, 10:55:11 PM"],["t","This is actively being worked on. Not sure on timeline, but it is in the works to be sent out either with the program or as a standalone program."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10168#msg10168"},{"f":"lachesis","d":1282176290,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10177#msg10177"},{"f":"satoshi","d":1282246830,"b":[["t","Make sure your computer's date and time are correct."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10290#msg10290","s":1,"n":403,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/403/"},{"f":"lachesis","d":1282277689,"b":[["t","My time is correct, and my debug.log shows nothing out of the ordinary. I'm stumped here, guys!"]],"u":"https://bitcointalk.org/index.php?topic=862.msg10375#msg10375"},{"f":"kosovito","d":1282313539,"b":[["t","My computer have date and time correct.\n\nI uninstalled bitcoin, i deleted absolutely all files, blocks, debug, ALL, except of course wallet.dat.\n\nAnd a reinstalled, i hope this can be works.\n\nA question, can be wallet.dat, make any problem??"]],"u":"https://bitcointalk.org/index.php?topic=862.msg10438#msg10438"},{"f":"satoshi","d":1282518062,"b":[["t","Search debug.log for \"proof-of-work found\".  If you find any, then check for any errors right after that."],["q","How big of a margin on the time is allowed for things to work right.","Quote from: davidonpda on August 19, 2010, 07:43:01 PM"],["t","The margin is 2 hours.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=862.msg10717#msg10717","s":1,"n":407,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/407/"}]},{"id":"p196","k":"p","s":"bitcointalk","t":"Convert Bitcoin to GTK: Yes?  No?  wx is better?","u":"https://bitcointalk.org/index.php?topic=867","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/196/","m":[{"f":"mizerydearia","d":1282202633,"b":[["t","Who is skilled enough to convert official Linux Bitcoin client to use GTK instead of wx?\n\nIs this development worthy or desirable enough to pursue or is wx acceptable?\n\nq: let me get this straight. You're asking if someone will put up a bounty for a conversion that you want? (bounty idea dismissed due to seeming weird/strange to some)\na: I don't want it. Is GTK better than QT or anytihng else?  I'm not familiar.\n\n\"I would like it if Bitcoin used GTK instead of wxWidgets but I won't pretend that I have a clue about how hard or easy that change might be\"\n\nsomeone: wx seems to work now as far as I can tell\nsomeone else: wx is an utter nightmare\n\nq: why \"convert\" Satoshi's front end? Why not just build a new one that uses the rpc calls?\n\nthere actually isn't much that needs to be done to make bitcoind's methods useful enough to do the same things the GUI does:\nin particular:\n * list sending addresses\n * show unaccepted blocks in listtransactions (maybe)\n * select a range of transactions to show"]],"u":"https://bitcointalk.org/index.php?topic=867.msg10216#msg10216"},{"f":"sirius","d":1282203057,"b":[["t","Hmm... would it run on Maemo with the same code then? Any other advantages?"]],"u":"https://bitcointalk.org/index.php?topic=867.msg10218#msg10218","sj":"Re: Convert Bitcoin to GTK (BTC Bounty Anyone?)"},{"f":"theymos","d":1282203288,"b":[["t","bitcoind's commands should be expanded and binaries for it should be released so that third-party UI development can be made easier. Like Tor."]],"u":"https://bitcointalk.org/index.php?topic=867.msg10219#msg10219"},{"f":"mizerydearia","d":1282203546,"b":[["t","It would be interesting for bitcoin to be designed in a way that an ncurses ui could be designed.\n \"you certainly can build a ncurses front end to the deamon now. Its not a problem for bitcoin\""]],"u":"https://bitcointalk.org/index.php?topic=867.msg10220#msg10220"},{"f":"Olipro","d":1282204273,"b":[["t","Yeah, my opinion on this is that the GUI should be separated from the underlying code. BUT... there's no need to throw the baby out with the bathwater and I firmly believe that the current wxWidgets interface should be maintained until such a time as something superior comes along.\n\nMy personal feeling is that whilst separate daemon/GUI binaries can work, it also tends to be messy, I'd be far more in favour of having the core code and then separate source that you compile with it according to your target OS, that way everything is still a single binary and can be integrated as idealistically as possible.\n\nTo put this in practice, imagine 3 SVN trunks; the first is BitCoin core, the other two are LINGUI and WINGUI - the latter two being dependant on code from the first."]],"u":"https://bitcointalk.org/index.php?topic=867.msg10223#msg10223"},{"f":"BioMike","d":1282205118,"b":[["t","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.\n\nI think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own \"client\" running (see http://bitcointalk.org/index.php?topic=851.0) with the daemon (who doesn't need WxWidgets anymore) and it works very nicely. So, in my case I don't have any dependency on WxWidgets any more."]],"u":"https://bitcointalk.org/index.php?topic=867.msg10226#msg10226"},{"f":"lfm","d":1282213699,"b":[["q","I think I would go with theymos in that the gui and daemon should be separated (or put the whole protocols and stuff in a library with bindings for different languages for that matter). I've already gotten my own \"client\" running (see http://bitcointalk.org/index.php?topic=851.0) with the daemon ...","Quote from: BioMike on August 19, 2010, 08:05:18 AM"],["t","So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why."]],"u":"https://bitcointalk.org/index.php?topic=867.msg10228#msg10228"},{"f":"teknohog","d":1282229999,"b":[["q","So what do you mean the gui and the daemon should be separated? They already are. You can build the separate daemon. Do you need a separate build of only the gui? I can't see why.","Quote from: lfm on August 19, 2010, 10:28:19 AM"],["t","Bitcoin is a P2P network, so the program should be running all the time. However, I don't need to be looking at a GUI all that time, so it makes sense to have a daemon. Currently, you have to stop the daemon when you want to start the GUI version, which breaks the network for a moment.\n\nSome P2P applications like aMule do this properly. The daemon is running all the time, and when you want to interact with it, you start the separate GUI, which connects to the daemon. Most importantly, the GUI can run on a different machine from the daemon.\n\nSuch a setup would be great for mobile Bitcoin usage. You run the daemon on your \"server\" machine, and you connect to it with a GUI on your mobile device. I think this has been already discussed in a different context, but the same mechanism applies.\n\nHowever, you can already use the JSON-RPC mechanism to build a separate GUI, so there is no immediate need to change the mainline client. "]],"u":"https://bitcointalk.org/index.php?topic=867.msg10250#msg10250"},{"f":"satoshi","d":1282243476,"b":[["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.","Quote from: BioMike on August 19, 2010, 08:05:18 AM"],["t","wxWidgets 2.9 is their first UTF-8 version.  We are UTF-8 on all platforms including Windows.\n\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.\n\nThis is a problem that will solve itself.  With time, 2.9 will become a more mainline release."]],"u":"https://bitcointalk.org/index.php?topic=867.msg10272#msg10272","s":1,"n":400,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/400/"}]},{"id":"p197","k":"p","s":"bitcointalk","t":"HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)","u":"https://bitcointalk.org/index.php?topic=868","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/197/","m":[{"f":"aceat64","d":1282203877,"b":[["t","I wrote up a basic guide on how to compile Bitcoin on Ubuntu. I hope it proves useful to anyone still having issues compiling the graphical client.\n\nhttp://lickthesalt.com/2010/08/19/compiling-bitcoin-on-ubuntu-10-04-karmic/"]],"u":"https://bitcointalk.org/index.php?topic=868.msg10221#msg10221"},{"f":"Willsway","d":1282230221,"b":[["t","An excellent guide. Thank you so much for your efforts - it will certainly help me Smiley"]],"u":"https://bitcointalk.org/index.php?topic=868.msg10251#msg10251"},{"f":"satoshi","d":1282244148,"b":[["t","That's a really well written walkthough.  Someone should confirm if they followed it and didn't run into any snags."]],"u":"https://bitcointalk.org/index.php?topic=868.msg10275#msg10275","s":1,"n":401,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/401/"}]},{"id":"p198","k":"p","s":"bitcointalk","t":"Hypothetical question on lost coins / transfers","u":"https://bitcointalk.org/index.php?topic=870","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/198/","m":[{"f":"Anonymous","d":1282245877,"b":[["t","sdfgsfhg"]],"u":"https://bitcointalk.org/index.php?topic=870.msg10288#msg10288","sj":"sdfh"},{"f":"FreeMoney","d":1282247046,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=870.msg10292#msg10292"},{"f":"satoshi","d":1282249730,"b":[["t","That's right.  You don't need to be re-broadcasting your transactions for it to work.\n\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.\n\nIn some types of forks, your transaction would have gotten into both forks already, so you're already good either way."]],"u":"https://bitcointalk.org/index.php?topic=870.msg10300#msg10300","s":1,"n":405,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/405/"}]},{"id":"p199","k":"p","s":"bitcointalk","t":"Need a post writing up some things users should know","u":"https://bitcointalk.org/index.php?topic=873","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/199/","m":[{"f":"satoshi","d":1282248841,"b":[["t","I'm not sure what to call it, but we could use a post that lists these things users should know.  If someone has time to write it, here's the list:\n\n- Make sure your clock is set correctly.\n\n- Microsoft Security Essentials.  This never got written up proper.\n\n- Warning not to mess around with your wallet.dat file.  It's a database file, it's not as simple as you think.  In this Beta version, we haven't had time to try and tinker-proof it yet.  It may not work as expected if you start swapping it around."]],"u":"https://bitcointalk.org/index.php?topic=873.msg10297#msg10297","s":1,"n":404,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/404/"},{"f":"mizerydearia","d":1282274418,"b":[["t","I posted the above comment onto the wiki for posting a list these things users should know: http://www.bitcoin.org/wiki/doku.php?id=things_you_should_know"],["q","mizeryderia, you just copied and pasted satoshis post without adding any value.\n\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.","Quote from: Insti on August 20, 2010, 10:18:58 AM"],["t","I apologize.  I wasn't sure what to add."]],"u":"https://bitcointalk.org/index.php?topic=873.msg10355#msg10355"},{"f":"Insti","d":1282299538,"b":[["t","mizeryderia, you just copied and pasted satoshis post without adding any value.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=873.msg10419#msg10419"},{"f":"satoshi","d":1282517460,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=873.msg10715#msg10715","s":1,"n":406,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/406/"},{"f":"nelisky","d":1282523890,"b":[["q","- Warning not to mess around with your wallet.dat file.  It's a database file, it's not as simple as you think.  In this Beta version, we haven't had time to try and tinker-proof it yet.  It may not work as expected if you start swapping it around.","Quote from: satoshi on August 19, 2010, 08:14:01 PM"],["t","So how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?\n\nThis part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage."]],"u":"https://bitcointalk.org/index.php?topic=873.msg10725#msg10725"},{"f":"mizerydearia","d":1282527093,"b":[["t","see http://bitcointalk.org/index.php?topic=921.0 for continued discussion about backups"],["q","> Quote from: satoshi on August 19, 2010, 08:14:01 PM\n> - Warning not to mess around with your wallet.dat file.  It's a database file, it's not as simple as you think.  In this Beta version, we haven't had time to try and tinker-proof it yet.  It may not work as expected if you start swapping it around.\n\nSo how simple is it? I'm just now thinking about foolproof backups on the lottery site I posted about yesterday, and I'm struggling to find information on this. Can bitcoind dump it in a safe state, or at least flush it on request? If I backup the file mid transaction, do I loose the whole thing or just the update in progress? When do I need to backup? Every outgoing transfer is obvious, there are key pairs created automagically, but what about transfers received? the key pair we already had, no new address needed to be created afaict. Or does bitcoin do the same change dance on the receive side too?\n\nThis part is, I believe, the most critical of them all. While MSE and clock skews may prevent normal program usage, the wallet backup issues have made people loose a bunch of coins which, obviously, sucks and doesn't do much on supporting continued usage.","Quote from: nelisky on August 23, 2010, 12:38:10 AM"],["t","This comment seems worthy of having this thread appear threaded so that discussion could expand exponentially.  In the case that this forum is not threaded, however, I will briefly state (without getting offtopic) that there should be some sort of established procedures or mechanisms to handle either regular interval or triggered backups without interrupting the Bitcoin process.  It seems that it is essential to \"perfect\" data reliability/availability as best as possible so as to provide more incentive for adoption.\n\nActually, it's not so offtopic."],["q","- Warning not to mess around with your wallet.dat file.  It's a database file, it's not as simple as you think.  In this Beta version, we haven't had time to try and tinker-proof it yet.  It may not work as expected if you start swapping it around.","Quote from: satoshi on August 19, 2010, 08:14:01 PM"],["t","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.\n\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.\n\nsee http://bitcointalk.org/index.php?topic=921.0 for continued discussion about backups"]],"u":"https://bitcointalk.org/index.php?topic=873.msg10728#msg10728"},{"f":"satoshi","d":1282783445,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=873.msg11227#msg11227","s":1,"n":420,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/420/"}]},{"id":"p200","k":"p","s":"bitcointalk","t":"integrating digital payments into p2p protocols","u":"https://bitcointalk.org/index.php?topic=890","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/200/","m":[{"f":"zooko","d":1282400007,"b":[["t","Folks:\n\nI just posted this note over on the Trade forum:\n\nhttp://bitcointalk.org/index.php?topic=30.msg10592#msg10592\n\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.\n\nRegards,\n\nZooko\n\ncommunity organizer, Tahoe-LAFS project"]],"u":"https://bitcointalk.org/index.php?topic=890.msg10593#msg10593"},{"f":"satoshi","d":1282521452,"b":[["t","Hey Zooko!\n\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."]],"u":"https://bitcointalk.org/index.php?topic=890.msg10723#msg10723","s":1,"n":410,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/410/"}]},{"id":"p201","k":"p","s":"bitcointalk","t":"Development of alert system","u":"https://bitcointalk.org/index.php?topic=898","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/201/","m":[{"f":"satoshi","d":1282521306,"b":[["t","I've been working on writing the alert system.  Alerts are broadcast through the network and apply to a range of version numbers.  Alert messages are signed with a private key that only I have.\n\nNodes can do two things in response to an alert:\n- Put a warning message on the status bar.\n- Make the money handling methods of the json-rpc interface return an error.\n\nIn cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade.  Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded.\n\nThe json-rpc methods that return errors during an alert are:\nsendtoaddress\ngetbalance\ngetreceivedbyaddress\ngetreceivedbylabel\nlistreceivedbyaddress\nlistreceivedbylabel"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10722#msg10722","s":1,"n":409,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/409/"},{"f":"lfm","d":1282537014,"b":[["t","Did you consider turning off block generation? You must have, why did you decide not to include it?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10738#msg10738"},{"f":"mizerydearia","d":1282539890,"b":[["t","On a side note, lfm,\nit seems a bit\nrepetitive, your post\nbeing the first reply\nyet you quote\nentirety of first post.\nOf course you were\nreplying to that\npost!  Perhaps you\nwanted your\npost to look\nmore full? ^_^I do not think it is good idea to forcefully turn off block generation.  I think it is better to maintain generating blocks until the owner/user specifically disables it themselves.  In most cases it may be perceived helpful to disable generating blocks automatically, but there may be some cases where it is not so helpful.\n\nI believe there is a precedence of backlash from other communities in which implementations of remote control were produced and hindered or interfered with communities expectations.  I am not certain that implementing a remote disable for block generation would be perceived similarly, but it is something to keep into consideration."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10740#msg10740"},{"f":"BioMike","d":1282540543,"b":[["t","@mizerydearia, I think the quote button is easier to find then the reply one.\n\nSo, 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?\n\nOr is that not possible? How far would <some goverment> get?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10742#msg10742"},{"f":"mizerydearia","d":1282540682,"b":[["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?\n\nOr is that not possible? How far would <some goverment> get?","Quote from: BioMike on August 23, 2010, 05:15:43 AM"],["t","Ooooooh, that's a good point too!\n\nI would suggest that as a beginning implementation for an alert system is it most basic, simple and to the point and is guaranteed to work without flaws, errors, exploits, etc.  Once this seems to be accepted by most of community and seems well established and secure, perhaps then it may be safe to expand upon it.  However, a single point of mass DOS seems too overwhelming to implement into the official client if there is any opportunity whatsoever to exploit it or take control of it through any means necessary."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10743#msg10743"},{"f":"FreeMoney","d":1282540993,"b":[["t","No! If you do that they'll torture you until you give them the key Satoshi!\n\nBut seriously, if the key has turn off power I'm not running that client.\n\nI really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.\n\nI imagine this thinking comes from seeing all the people who haven't switched to 3.10 yet?\n\nHaving enough different implementations that none is a majority would mean a bug like the overflow would only lead to problems with the improperly coded client and not with the whole chain. Unless people writing new clients mostly copied your code, then any problems would remain. But if they were written from scratch to do what they should then any problems would not overlap.\n\nDo I remember you saying you thought it would be a nightmare to have multiple implementations? I can't remember why you said that though."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10745#msg10745"},{"f":"lfm","d":1282541294,"b":[["q","I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.","Quote from: FreeMoney on August 23, 2010, 05:23:13 AM"],["t","It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10748#msg10748"},{"f":"BioMike","d":1282541409,"b":[["t","Hmmm. yes... that makes sense."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10749#msg10749"},{"f":"jgarzik","d":1282550112,"b":[["t","A remote warning message seems reasonable.\n\nBut a remote kill switch for automated websites?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10778#msg10778"},{"f":"hugolp","d":1282550927,"b":[["q","No! If you do that they'll torture you until you give them the key Satoshi!\n\nBut seriously, if the key has turn off power I'm not running that client.\n\nI really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.\n\nI imagine this thinking comes from seeing all the people who haven't switched to 3.10 yet?\n\nHaving enough different implementations that none is a majority would mean a bug like the overflow would only lead to problems with the improperly coded client and not with the whole chain. Unless people writing new clients mostly copied your code, then any problems would remain. But if they were written from scratch to do what they should then any problems would not overlap.\n\nDo I remember you saying you thought it would be a nightmare to have multiple implementations? I can't remember why you said that though.","Quote from: FreeMoney on August 23, 2010, 05:23:13 AM"],["t","+1"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10781#msg10781"},{"f":"mizerydearia","d":1282553404,"b":[["q","> Quote from: FreeMoney on August 23, 2010, 05:23:13 AM\n> I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.\n\nIt's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.","Quote from: lfm on August 23, 2010, 05:28:14 AM"],["t","It would require a lot of effort for everyone to change keys or to upgrade to a new version.  This should be recognized by those that are still using old versions even as far back as 0.3.0 and maybe even earlier."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10783#msg10783"},{"f":"caveden","d":1282553927,"b":[["t","Wouldn't an automatic update be better?\nFor linux distros at least, it should not be that hard to do it I suppose."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10787#msg10787"},{"f":"mizerydearia","d":1282554051,"b":[["t","Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure.  This is not the case across different distributions of linux.\n\nHowever, automatic update is not recommended.  An alert indicator to notify the user to take action is best.  Perhaps the bitcoind version can be configured to send an email alert to a specified email address in the config file as an extra step for alerting/notification."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10788#msg10788"},{"f":"caveden","d":1282554502,"b":[["q","Automatic update for linux is far more difficult than for windows considering in windows installation of software across different versions of windows is fairly similar and has practically same hierarchy of file structure.  This is not the case across different distributions of linux.","Quote from: mizerydearia on August 23, 2010, 09:00:51 AM"],["t","Oh, come on, no need to cover all possible distros. Just debian and rpm repositories should be fine.  Wink"],["q","However, automatic update is not recommended.  An alert indicator to notify the user to take action is best. ","Quote from: mizerydearia on August 23, 2010, 09:00:51 AM"],["t","That's what I meant by \"automatic update\"... normally they always ask user confirmation.\nThey just spare you the work of going to the webiste of each software you have installed to check for new downloads."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10791#msg10791"},{"f":"Macho","d":1282556982,"b":[["t","I was going to suggest the exact same thing... you beat me to it Smiley\n\nHowever it has to be done carefully, people do not like any unsanctioned changes to happen without their knowledge or any kind of remote control. If this would be implemented I would say that it should not execute any action unless specifically requested/confirmed by the user.\n\nOn a GUI client this would be accomplished by presenting a dialog window describing the requested actions and waiting for the user to confirm them (or check an \"automatically apply changes suggested in alerts\" checkbox, which would be unchecked by default).\n\nAlso a deamon should not do anything unless a specific switch for that purpose is applied like --enable-alerts. It can show a warning if this switch is not applied and suggest to enable it to the user but it shouldn't apply it by default automatically.\n\nIn short, any changes except simple alerts should be disabled by default. "]],"u":"https://bitcointalk.org/index.php?topic=898.msg10793#msg10793"},{"f":"FreeMoney","d":1282557236,"b":[["q","> Quote from: FreeMoney on August 23, 2010, 05:23:13 AM\n> I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.\n\nIt's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.","Quote from: lfm on August 23, 2010, 05:28:14 AM"],["t","Well, yeah, that's what I'd need to do, but since I'd have to buy/beg it from someone who can implement I'd prefer to have the main client just be what I want. Also I'd stay more comfortable with bitcoin on the whole if other people don't have a centrally controlled client. I know I could convince them to use a non-special-key version, but really that's what I'm doing right now.\n\nMessages only is not a big deal, but I think it does start down a \"special user\" path that I'd prefer not to follow."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10794#msg10794"},{"f":"nelisky","d":1282560352,"b":[["t","Being open source does not mean every user is a coder (I am, but still) so I guess the point that \"you can just roll out your own client\" is a little off.\n\nBut why is satoshi integrating this on the server in the first place? I say that the libbitcoin / bitcoinUI separation is starting to be really important. Put the messaging system on IRC on the UI, make the UI smart enough to stop, block, maim, impair the server running beneath it if certain messages signed with certain keys appear. But DON'T make the server respond to anything outside local GUI control, just because that is too dangerous and in the end does more harm than good.\n\nThis way, average users will have the upgrade notices and the generators stopped and whatnot when needed, but those of us running services over bitcoin will not loose shop because of that. Also, if the key gets compromised, the network still runs without worries, and a simple GUI change will unblock everyone.\n\nFor server admins, why not a mailing list for update announces? That would certainly be enough for most."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10801#msg10801"},{"f":"Anonymous","d":1282567095,"b":[["t","I second the mailing list idea.Having a way to shut down the system if you control the key would be a bad idea.\nA mailing list makes it non coercive rather than seeming like there is a kill switch that could wipe your bitcoins out."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10810#msg10810"},{"f":"HostFat","d":1282575762,"b":[["t","I like the idea about a warning message, but I'm against anything like a remote control.\nThe only way to make it possible is adding an option where user can chose to enable/disable this remote control."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10830#msg10830"},{"f":"nimnul","d":1282578367,"b":[["t","1) package for CentOS :-) so updates are easy\n2) don't implement messages\n3) notify us using RSS/email/Jabber"]],"u":"https://bitcointalk.org/index.php?topic=898.msg10836#msg10836"},{"f":"Macho","d":1282581562,"b":[["q","3) notify us using RSS/email/Jabber","Quote from: nimnul on August 23, 2010, 03:46:07 PM"],["t","That is too centralized/censorable/hackable, the idea with a message signed with specific private key only satochi has is ideal as it can be introduced at any node and spread trough decentralized means."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10844#msg10844"},{"f":"lfm","d":1282622297,"b":[["q","> Quote from: lfm on August 23, 2010, 05:28:14 AM\n> > Quote from: FreeMoney on August 23, 2010, 05:23:13 AM\n> > I really don't even like the idea of one person having ability to send messages. Even if I/we trust that person now, we might not later, or it might be a different person, or they might get tortured/bribed/blackmailed.\n>\n> It's open source! If you don't trust Satoshi or think he is going to be coerced, replace his key with your own so only you have the power to shutdown your nodes.\n\nIt would require a lot of effort for everyone to change keys or to upgrade to a new version.  This should be recognized by those that are still using old versions even as far back as 0.3.0 and maybe even earlier.","Quote from: mizerydearia on August 23, 2010, 08:50:04 AM"],["t","It doesn't require a lot of effort if its a simple option,either in a config file or a command line switch. It might not even be a default, could be opt-in. Some people would welcome it as insurance that they will not be causing problems in an emergency."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10961#msg10961"},{"f":"theymos","d":1282625969,"b":[["t","There should be a --disable-alerts switch."]],"u":"https://bitcointalk.org/index.php?topic=898.msg10979#msg10979"},{"f":"satoshi","d":1282693872,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11074#msg11074","s":1,"n":412,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/412/"},{"f":"satoshi","d":1282694796,"b":[["t","This is in SVN rev 142 as version 0.3.11."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11078#msg11078","s":1,"n":413,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/413/"},{"f":"mizerydearia","d":1282695110,"b":[["q","If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.","Quote from: satoshi on August 24, 2010, 11:51:12 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11079#msg11079"},{"f":"MoonShadow","d":1282695878,"b":[["q","  If you decide it's a false alarm and want to take your chances, you can use the \"-disablesafemode\" switch.","Quote from: satoshi on August 24, 2010, 11:51:12 PM"],["t","What else does -disablesafemode do?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11083#msg11083"},{"f":"nelisky","d":1282699712,"b":[["q","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.\n\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.","Quote from: satoshi on August 24, 2010, 11:51:12 PM"],["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11092#msg11092"},{"f":"Macho","d":1282705383,"b":[["q","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.","Quote from: satoshi on August 24, 2010, 11:51:12 PM"],["t","Satochi the creator of the decentralized pseudo-anonymous trading system not reliant on trust and using strong cryptography is calling us paranoid LOL\n\nNot wanting any remote tampering of the software running on my PC is not paranoid but a matter of common sense I believe. Of course it is a good idea but it should be enabled ONLY when specifically requested by the user. It should be opt-in as opposed to opt-out. There is a huge difference between the two (ask Facebook). If it's going to be enabled by default it is going to be perceived by many as an exploitable/malicious feature counting on the fact that most people will not realize/notice it is even there. And I wouldn't say these concerns wouldn't be justified ... It doesn't matter that you have best interest of the community at your heart which I'm sure you have, the system was designed not to rely on any kind of central trust and that principle should not be broken."],["q","I 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.","Quote"],["t","Why not use -enablesafety to enable this feature instead of expecting the user to disable it? If I want my software to respond to remote alerts I should specifically enable it, that way it is ensured that I'm aware of what I'm doing and I'm doing it of my own will. When it is enabled by default a lot of people may not even realize this \"feature\" is enabled and perceive remote disabling as a breach of trust ... I know I would if I wasn't aware of that possibility and the software would suddenly stopped working and I would discover it was disabled by remote by someone I gave no conscious permission to do so.\n\nI hope you'll consider this suggestion ... thanks"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11101#msg11101"},{"f":"mizerydearia","d":1282727671,"b":[["q","","Quote from: Macho on August 25, 2010, 03:03:03 AM"],["t","I agree, however, if you compile from source, a single change from\n\nrpc.cpp"],["c","!mapArgs.count(\"-disablesafemode\")"],["t","to"],["c","mapArgs.count(\"-safemode\")"],["t","will then"],["c","// Observe lockdown\nthrow runtime_error(strWarning);"],["t","You can examine the code at http://bitcoin.svn.sourceforge.net/viewvc/bitcoin/trunk/rpc.cpp?revision=142&view=markup to see what is happening.\n\nIt seems a bit strange to only show an error when -enablesafety is used.  Perhaps it is unsafe or insecure for this to happen?\n\nhttp://www.bitcoin.org/wiki/doku.php?id=api\n\nFrom my understanding of the code it appears that when using one of these http://www.bitcoin.org/wiki/doku.php?id=api methods other than getinfo, help, stop, getgenerate, setgenerate and most importantly when there is a warning, that:\n\nif -disablesafemode was passed to the running process, then the warning will not be displayed\nif -disablesafemode was not passed to the running process, then the warning will be displayed\n\nhttp://www.cplusplus.com/reference/std/stdexcept/runtime_error/"],["q","necrodearia> http://www.cplusplus.com/reference/std/stdexcept/runtime_error/ - Does this cause the running process to stop or does it just produce output to the terminal/shell?\n<Adrinael> necrodearia, \"this\"?\n<necrodearia> runtime_error\n<Adrinael> necrodearia, if you create a runtime_error object, nothing happens. If you throw a runtime_error object, it all depends on if someone catches it, and where.\n<Adrinael> { try {  throw runtime_error(\"Error, halp!\");  }  catch (runtime_error& e) { cout << \"caught a runtime error: \" << e.what(); }   cout << \" but still continuing...\"; }\n<clang> terminated by runtime_error: Error, halp!\n<Adrinael> Hmm awesome\n<Adrinael> geordi { try {  throw runtime_error(\"Error, halp!\");  }  catch (runtime_error& e) { cout << \"caught a runtime error: \" << e.what(); }   cout << \" but still continuing...\"; }\n<geordi> caught a runtime error: Error, halp! but still continuing...\n<Sausage> How in the hell did it get that wrong?\n<Adrinael> Asked Eelis on #geordi, now move along","Quote"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11127#msg11127"},{"f":"Macho","d":1282739154,"b":[["q","I agree, however, if you compile from source, a single change from","Quote from: mizerydearia on August 25, 2010, 09:14:31 AM"],["t","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.\n\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.\n\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 Wink\n\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.\n\nThat's at least my perspective ... and the fix is extremely easy Wink"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11137#msg11137"},{"f":"satoshi","d":1282749457,"b":[["t","It can't do arbitrary actions remotely.  Maybe some of you are responding to other posters who suggested the alert system should do more?\n\nIf there is an alert, the following json-rpc methods return an error:\nsendtoaddress\ngetbalance\ngetreceivedbyaddress\ngetreceivedbylabel\nlistreceivedbyaddress\nlistreceivedbylabel\n\nThe remaining 14 methods function as normal.\n\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.\n\nWorst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11150#msg11150","s":1,"n":414,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/414/"},{"f":"satoshi","d":1282754420,"b":[["t","I changed the switch name to -disablesafemode."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11151#msg11151","s":1,"n":415,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/415/"},{"f":"nelisky","d":1282754515,"b":[["t","What is the error the RPC calls return? And more importantly, how can I simulate this? Can you add a flag to start the server in degraded mode?"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11152#msg11152"},{"f":"jimbobway","d":1282754722,"b":[["q","@mizerydearia, I think the quote button is easier to find then the reply one.\n\nSo, 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?\n\nOr is that not possible? How far would <some goverment> get?","Quote from: BioMike on August 23, 2010, 05:15:43 AM"],["t","A few rhetorical questions for satoshi:\n\nCan you resist waterboarding?\nCan you endure electric shock?\nAll forms of torture?\nLastly, are you Jack Bauer by any chance?   Seriously."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11153#msg11153"},{"f":"satoshi","d":1282755375,"b":[["q","> Quote from: BioMike on August 23, 2010, 05:15:43 AM\n> @mizerydearia, I think the quote button is easier to find then the reply one.\n>\n> So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand\n> that he hands over his key (or get it from his computer) and shut down the complete network?\n>\n> Or is that not possible? How far would <some goverment> get?\n\nA few rhetorical questions for satoshi:\n\nCan you resist waterboarding?\nCan you endure electric shock?\nAll forms of torture?\nLastly, are you Jack Bauer by any chance?   Seriously.","Quote from: jimbobway on August 25, 2010, 04:45:22 PM"],["t","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."],["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?","Quote from: BioMike on August 23, 2010, 05:15:43 AM"],["t","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\"."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11155#msg11155","s":1,"n":416,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/416/"},{"f":"satoshi","d":1282759170,"b":[["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?","Quote from: nelisky on August 25, 2010, 01:28:32 AM"],["t","getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.\n\nThe rpc methods return a json-rpc error with the error description \"Safe mode: \" followed by additional text specified by the alert.\n\nI added the switch \"-testsafemode\" for you.  SVN rev 145.\n\nThis stuff is very new and may still be subject to change."],["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.","Quote from: mizerydearia on August 25, 2010, 12:11:50 AM"],["t","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\n-4way should eventually be replaced by an auto-detect."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11158#msg11158","s":1,"n":417,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/417/"},{"f":"BioMike","d":1282760625,"b":[["q","> Quote from: BioMike on August 23, 2010, 05:15:43 AM\n> So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand\n> that he hands over his key (or get it from his computer) and shut down the complete network?\nThis is what makes me think the people objecting don't know what they're talking about.  It can't \"shut down the complete network\".","Quote from: satoshi on August 25, 2010, 04:56:15 PM"],["t","I've never objected this change/idea, just asking if this was possible and to what extent.\nWhat's wrong with getting informed? Wink"]],"u":"https://bitcointalk.org/index.php?topic=898.msg11162#msg11162"},{"f":"nelisky","d":1282762953,"b":[["q","> Quote from: nelisky on August 25, 2010, 01:28:32 AM\n> 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?\ngetinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.\n\nThe rpc methods return a json-rpc error with the error description \"Safe mode: \" followed by additional text specified by the alert.\n\nI added the switch \"-testsafemode\" for you.  SVN rev 145.\n\nThis stuff is very new and may still be subject to change.","Quote from: satoshi on August 25, 2010, 05:59:30 PM"],["t","Perfect, works great for me. Thank you."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11166#msg11166"},{"f":"FreeMoney","d":1282776481,"b":[["t","Okay, I'm not worried anymore."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11204#msg11204"},{"f":"satoshi","d":1282781292,"b":[["q","> Quote from: satoshi on August 25, 2010, 04:56:15 PM\n> > Quote from: BioMike on August 23, 2010, 05:15:43 AM\n> > So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand\n> > that he hands over his key (or get it from his computer) and shut down the complete network?\n> >\n> > Or is that not possible? How far would <some goverment> get?\n> 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\".\nI've never objected this change/idea, just asking if this was possible and to what extent.\nWhat's wrong with getting informed? Wink","Quote from: BioMike on August 25, 2010, 06:23:45 PM"],["t","My apologies, your post was indeed a question not a statement."]],"u":"https://bitcointalk.org/index.php?topic=898.msg11219#msg11219","s":1,"n":418,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/418/"}]},{"id":"p202","k":"p","s":"bitcointalk","t":"RFC: remove DB_PRIVATE flag","u":"https://bitcointalk.org/index.php?topic=920","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/202/","m":[{"f":"jgarzik","d":1282698193,"b":[["t","Wallet backups and other DB examination are easily possible in a safe, atomic, transactional fashion...   if and only if DB_PRIVATE flag is removed."],["c","--- a/db.cpp\n+++ b/db.cpp\n@@ -77,7 +77,6 @@ CDB::CDB(const char* pszFile, const char* pszMode) : pdb(NULL)\n                              DB_INIT_MPOOL |\n                              DB_INIT_TXN   |\n                              DB_THREAD     |\n-                             DB_PRIVATE    |\n                              DB_RECOVER,\n                              S_IRUSR | S_IWUSR);"],["t","What, if any, problems arise from doing this?  Obviously, this does not cover the non-db4 databases such as the block data file."]],"u":"https://bitcointalk.org/index.php?topic=920.msg11087#msg11087"},{"f":"satoshi","d":1282782808,"b":[["t","Can you provide more details about what removing DB_PRIVATE does?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=920.msg11224#msg11224","s":1,"n":419,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/419/"},{"f":"jgarzik","d":1282783164,"b":[["t","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 <http://pybsddb.sourceforge.net/api_c/env_open.html>.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=920.msg11225#msg11225"},{"f":"satoshi","d":1284314439,"b":[["t","Trying it without the DB_PRIVATE flag in rev 153.  We need to keep an eye on what's different.\n\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.\n\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.\n\nTests on Windows private LAN download of 78500 blocks:\nwith DB_PRIVATE     20 minutes 51 seconds\nwithout DB_PRIVATE   20 minutes 51 seconds\n\nI wasn't expecting them to come out exactly the same."]],"u":"https://bitcointalk.org/index.php?topic=920.msg12484#msg12484","s":1,"n":450,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/450/"}]},{"id":"p203","k":"p","s":"bitcointalk","t":"auto backing up of wallet.dat","u":"https://bitcointalk.org/index.php?topic=921","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/203/","m":[{"f":"nelisky","d":1282708333,"b":[["t","So, as many others, I need to backup wallet.dat. And since this one is on a server, I need it to happen unattended. And because this server is being used by the lottery, I must not shutdown bitcoind.\n\nSo far I just copy the file over, and do it often so I can outlive one corrupted file. But this is not ideal, as I should backup after every transaction (sent, right? no new addresses are created on receiving a transfer ) or after everytime I create a new address.\n\nFor that I thought about instead of copying the file I could use db_dump to dump it's contents, using the -r flag just in case. Would that work?\n\nThe ideal solution would be an rpc call that would either:\n- flush and lock updates until a new rpc call (any call, didn't need to be an unlock command) would come over\n- flush and cp wallet.dat to a side file\n- flush and dump through jsonrpc. If each key would come separate in an array, we could then call this with 'lastseen=X' to just get new keys\n\nCould this work? Which would work best?"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11107#msg11107"},{"f":"mizerydearia","d":1282734676,"b":[["t","http://bitcointalk.org/index.php?topic=873.msg10728#msg10728 is somewhat related"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11131#msg11131"},{"f":"satoshi","d":1282784260,"b":[["t","I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.\n\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.\n\nI was starting to post the same idea you said nelisky.\n\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.\n\nWhat's the simplest portable way to copy a file?  Is there something in Boost?\n\nWhat should it be named?  maybe:\nbackupwallet <destination>"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11228#msg11228","s":1,"n":421,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/421/"},{"f":"nelisky","d":1282785717,"b":[["q","I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic.\n\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.\n\nI was starting to post the same idea you said nelisky.","Quote from: satoshi on August 26, 2010, 12:57:40 AM"],["t","Yes, I saw your other post and I really like the poll of addresses, but we still need a way to easily back up when those get all used, don't we? I know the address space is huge, but there might be applications that deliver thousands of addresses per day."],["q","How 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.\n\nWhat's the simplest portable way to copy a file?  Is there something in Boost?\n\nWhat should it be named?  maybe:\nbackupwallet <destination>","Quote from: satoshi on August 26, 2010, 12:57:40 AM"],["t","Great on all accounts, name and implementation approach.\n\nAs for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps. In C++ you can just use standard file streams, can't you? Something like http://www.dreamincode.net/code/snippet2306.htm (out of a quick google, didn't try but looks correct).\n\nTo put the cherry on top, why not add a trigger that makes the copy whenever there's a change to the wallet? Well, this would depend on file locking to work properly and that sucks on windows iirc. Been a while since I had to code there Smiley"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11232#msg11232"},{"f":"jgarzik","d":1282786946,"b":[["q","What's the simplest portable way to copy a file?  Is there something in Boost?","Quote from: satoshi on August 26, 2010, 12:57:40 AM"],["t","mmap(2) + memcpy(3) ?  Boost::Iostreams already has a mapped_file Source."],["q","What should it be named?  maybe:\nbackupwallet <destination>","Quote from: satoshi on August 26, 2010, 12:57:40 AM"],["t","Sounds quite useful!"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11235#msg11235"},{"f":"satoshi","d":1282871622,"b":[["t","If you read it into memory and write it out, it could fail in tight memory situations.\n\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."],["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.","Quote from: nelisky on August 26, 2010, 01:21:57 AM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=921.msg11345#msg11345","s":1,"n":423,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/423/"},{"f":"nelisky","d":1282872069,"b":[["q","If you read it into memory and write it out, it could fail in tight memory situations.\n\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.\n\n> Quote from: nelisky on August 26, 2010, 01:21:57 AM\n> 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.\nWe require Boost for JSON and a dozen things replacing dependencies on wxWidgets.  Boost is good, portable stuff, we should not shy away from it.","Quote from: satoshi on August 27, 2010, 01:13:42 AM"],["t","Ok, so what's wrong with the simple standard fstream usage from that snippet I mentioned? I think simple is best Smiley\n\nBut 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."]],"u":"https://bitcointalk.org/index.php?topic=921.msg11346#msg11346"},{"f":"jgarzik","d":1282875259,"b":[["q","If you read it into memory and write it out, it could fail in tight memory situations.","Quote from: satoshi on August 27, 2010, 01:13:42 AM"],["t","I think you misunderstand what mmap does?  mmap / CreateFileMapping does not read a file into heap memory:  http://en.wikipedia.org/wiki/Mmap"]],"u":"https://bitcointalk.org/index.php?topic=921.msg11348#msg11348"},{"f":"satoshi","d":1282877647,"b":[["t","I doubt there's an mmap(2) on Windows.  I'd rather call an existing file copy function than make and test my own."],["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.","Quote from: nelisky on August 27, 2010, 01:21:09 AM"],["t","Thanks.  I thought it would be in there somewhere.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=921.msg11350#msg11350","s":1,"n":424,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/424/"},{"f":"jgarzik","d":1282880545,"b":[["q","I doubt there's an mmap(2) on Windows.","Quote from: satoshi on August 27, 2010, 02:54:07 AM"],["t","The Windows version of mmap was mentioned in the message to which you replied:  CreateFileMapping\n\nIn my earlier message, I mentioned how to use this from boost:  Boost::Iostreams already has a mapped_file Source."]],"u":"https://bitcointalk.org/index.php?topic=921.msg11352#msg11352"},{"f":"satoshi","d":1282924077,"b":[["t","Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.\n\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.\n\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.\n\nBottom line is I'd rather call an existing file copy function than make and test my own."]],"u":"https://bitcointalk.org/index.php?topic=921.msg11399#msg11399","s":1,"n":425,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/425/"},{"f":"satoshi","d":1283809510,"b":[["t","rpc backupwallet <destination> is in SVN rev 147."]],"u":"https://bitcointalk.org/index.php?topic=921.msg12134#msg12134","s":1,"n":437,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/437/"}]},{"id":"p204","k":"p","s":"bitcointalk","t":"New web service: obtain dump of bitcoin block NNNN","u":"https://bitcointalk.org/index.php?topic=928","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/204/","m":[{"f":"jgarzik","d":1282782091,"b":[["t","As part of Bitcoin Watch <http://www.bitcoinwatch.com/>, a new feature provides a developer-friendly dump of a bitcoin block at the specified height.\n\nGET parameters:\n\"h\" - height of block to download\n\"json\" - set to non-zero value, to enable application/json output rather than HTML output\n\nExamples:\n\nDump block 72000: http://blk.bitcoinwatch.com/b?h=72000\n\nDump block 72000, with JSON: http://blk.bitcoinwatch.com/b?h=72000&json=1"]],"u":"https://bitcointalk.org/index.php?topic=928.msg11220#msg11220"},{"f":"jgarzik","d":1282893731,"b":[["t","This sub-page of Bitcoin Watch shows the last 7 days worth of blocks, each block linking to expanded data:\n\nhttp://blk.bitcoinwatch.com/"]],"u":"https://bitcointalk.org/index.php?topic=928.msg11365#msg11365"},{"f":"nelisky","d":1282907074,"b":[["t","Superb! Thanks a lot."]],"u":"https://bitcointalk.org/index.php?topic=928.msg11380#msg11380"},{"f":"satoshi","d":1282925596,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=928.msg11400#msg11400","s":1,"n":426,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/426/"}]},{"id":"p205","k":"p","s":"bitcointalk","t":"Gentoo Linux Ebuild","u":"https://bitcointalk.org/index.php?topic=930","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/205/","m":[{"f":"mizerydearia","d":1282803029,"b":[["t","bitcoin ebuilds for gentoo linux <http://github.com/mizerydearia/bitcoin_gentoo_ebuild>\n\n2011.03.02: bitcoin-git-9999 ebuild updated outdated\n\nCome to #bitcoin-gentoo on Freenode for latest"]],"u":"https://bitcointalk.org/index.php?topic=930.msg11252#msg11252"},{"f":"satoshi","d":1282870183,"b":[["t","Try -datadir=\n\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.\n\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."],["q","Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.","Quote"],["t","Did they say why they were baffled?"],["q","This is because on my system the path is /usr/include/wx-2.9/wx/wx.h","Quote"],["t","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.\n\nHas wxWidgets 2.9 finally started to become available as a debian package?\n\nMaybe we should do this:\n\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\"\n\nAgain, those paths help make sure it's only 2.9 and will fail with 2.8.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=930.msg11342#msg11342","s":1,"n":422,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/422/"}]},{"id":"p206","k":"p","s":"bitcointalk","t":"Version 0.3.11 with upgrade alerts","u":"https://bitcointalk.org/index.php?topic=941","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/206/","m":[{"f":"satoshi","d":1282946052,"b":[["t","Version 0.3.11 is now available.\n\nChanges:\n- Some blk*.dat checking on load\n- Built the -4way code with -march=amdfam10, which makes it a little faster\n- Warning if your clock is too far off\n- Warnings/errors/alerts can also be seen in the getinfo command\n- Alert system\n\nThe alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.\n\nIn response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:\n sendtoaddress\n getbalance\n getreceivedbyaddress\n getreceivedbylabel\n listreceivedbyaddress\n listreceivedbylabel\n\nIf you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.\n\nThis is an important safety improvement.  For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.\n\nNodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/"]],"u":"https://bitcointalk.org/index.php?topic=941.msg11439#msg11439","s":1,"n":429,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/429/"},{"f":"jgarzik","d":1282947126,"b":[["t","Good stuff.  For those who haven't been following other threads, I think it's important to note that the alerts are only accepted if signed by a specific key (held by satoshi).  Alerts cannot be generated by average nodes."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11441#msg11441"},{"f":"BioMike","d":1282948835,"b":[["q","- Built with -march=amdfam10, which makes -4way slightly faster","Quote from: satoshi on August 27, 2010, 09:54:12 PM"],["t","Doesn't -march break abi with older systems?"]],"u":"https://bitcointalk.org/index.php?topic=941.msg11448#msg11448"},{"f":"jgarzik","d":1282952126,"b":[["q","> Quote from: satoshi on August 27, 2010, 09:54:12 PM\n> - Built with -march=amdfam10, which makes -4way slightly faster\n\nDoesn't -march break abi with older systems?","Quote from: BioMike on August 27, 2010, 10:40:35 PM"],["t","It's quite possible.  -mtune=XXXX may be preferred, because -march=XXXX means the compiler expects the binary will only be run on amdfam10."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11463#msg11463"},{"f":"tcatm","d":1282955615,"b":[["q","... -march=XXXX means the compiler expects the binary will only be run on amdfam10.","Quote from: jgarzik on August 27, 2010, 11:35:26 PM"],["t","That's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11469#msg11469"},{"f":"pavelo","d":1282980967,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11481#msg11481"},{"f":"BioMike","d":1282983845,"b":[["q","> Quote from: jgarzik on August 27, 2010, 11:35:26 PM\n> ... -march=XXXX means the compiler expects the binary will only be run on amdfam10.\n\nThat's exactly what we want. But I agree, it's a dirty hack to use -march=amdfam10. In this case it'll produce the most compact and efficient SSE2 code from the source. A cleaner alternative would be inline assembler.","Quote from: tcatm on August 28, 2010, 12:33:35 AM"],["t","So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?"]],"u":"https://bitcointalk.org/index.php?topic=941.msg11484#msg11484"},{"f":"tcatm","d":1282989980,"b":[["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.","Quote from: pavelo on August 28, 2010, 07:36:07 AM"],["t","We only compile one source file with the 4way code (sha256.cpp) using -march=amdfamk10, not the whole client."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11491#msg11491"},{"f":"tcatm","d":1282990338,"b":[["q","So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?","Quote from: BioMike on August 28, 2010, 08:24:05 AM"],["t","Phenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as \"only works on AMDs K10\" but rather as \"tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future\"."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11492#msg11492"},{"f":"BioMike","d":1282992497,"b":[["q","> Quote from: BioMike on August 28, 2010, 08:24:05 AM\n> So, what CPU's support this? Is this only the newest AMD ones? And how many systems are we excluding because of this?\n\nPhenoms, i5 and i7 from what I know. Those are the only CPUs that have a 128 bit SSE2 instruction decoder and benefit at all, every older CPU will be slower. Don't think about it as \"only works on AMDs K10\" but rather as \"tweak the compiler to produce the exact assembly code we want and still be flexible to support other vector engines in the future\".","Quote from: tcatm on August 28, 2010, 10:12:18 AM"],["t","Ah. Ok. Thank you for the info."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11494#msg11494"},{"f":"torservers","d":1283000437,"b":[["t","The \"About\" dialog still shows 0.3.10.1 beta."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11499#msg11499"},{"f":"satoshi","d":1283007244,"b":[["q","The \"About\" dialog still shows 0.3.10.1 beta.","Quote from: torservers on August 28, 2010, 01:00:37 PM"],["t","What OS?  I ran the Windows and 64-bit Linux version and checked the about dialog.\n\nThe Mac version is still 0.3.10.1."],["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.","Quote from: pavelo on August 28, 2010, 07:36:07 AM"],["t","I updated the first post to be more specific.  Only the -4way code is compiled this way."]],"u":"https://bitcointalk.org/index.php?topic=941.msg11505#msg11505","s":1,"n":431,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/431/"}]},{"id":"p207","k":"p","s":"bitcointalk","t":"Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?","u":"https://bitcointalk.org/index.php?topic=955","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/207/","m":[{"f":"jimbobway","d":1283212233,"b":[["t","http://www.bitcoinblogger.com/2010/08/is-it-better-to-buy-or-generate.html"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11719#msg11719"},{"f":"pyrrhos","d":1283261338,"b":[["t","Nice calculation. certainly it is not worth building a machine for bitcoin creation. However if you already have this computing power sitting idly then you should calculate only the costs of the extra electricity that you need to consume to generate a block. Has anybody done this?\nIf you want to build a bitcoin generation machine you are probably better off buying a FPGA board and designing a dedicated hash calculating hardware monster.\n\nInteresting note: If one puts 4100000 hash/sec in the calculator then you get 10 minutes average.\n10 minutes is the actual target average block production rate.\nThis means that currently the the total computing power working on solving hashes is 4.1 Mhash/s\nor about 900 quad cores. or 3-4 thousand laptops. Pretty impressive!\n\nThis means that there are some people who think it is interesting to produce bitcoin.\nWho knows why, I stopped several difficulties ago."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11775#msg11775"},{"f":"chaord","d":1283272519,"b":[["t","Interesting calculations.  Currently I'm down to one computer myself (laptop), so it's not really worth generating for me.  However, I'm wondering whether this is going to be a problem for the network's continued growth and stability? I know there are many threads discussing how there is in fact incentive to continue to generate, even when all 21M are found.  My concern is that those 21M coins are going to end up being majority owned by a minority of individuals.  Will bitcoin end up with the same pareto properties as other economic and social systems, where 1% of the people end up owning just over 50% of the resource?  Is there any way for us to get an accurate gauge on this?"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11783#msg11783"},{"f":"jimbobway","d":1283274814,"b":[["t","I can't wait for someone to write an application that allows group mining of bitcoins.  I just can't wait one month to see 50 bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11786#msg11786"},{"f":"MoonShadow","d":1283278240,"b":[["q","  Is there any way for us to get an accurate gauge on this?","Quote from: chaord on August 31, 2010, 04:35:19 PM"],["t","No, but if you're still alive in 120 years to see it, count yourself lucky.\n\nI'd be willing to bet that whoever holds the majority of bitcoins in 120 years...\n\n1) they earned them and\n\n2) they are not even born yet."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11789#msg11789"},{"f":"MoonShadow","d":1283278278,"b":[["q","I can't wait for someone to write an application that allows group mining of bitcoins.  I just can't wait one month to see 50 bitcoins.","Quote from: jimbobway on August 31, 2010, 05:13:34 PM"],["t","I think that you missed the point of the blog article."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11790#msg11790"},{"f":"jimbobway","d":1283280288,"b":[["q","> Quote from: jimbobway on August 31, 2010, 05:13:34 PM\n> I can't wait for someone to write an application that allows group mining of bitcoins.  I just can't wait one month to see 50 bitcoins.\n\nI think that you missed the point of the blog article.","Quote from: creighto on August 31, 2010, 06:11:18 PM"],["t","Heh.  I did write the article.  But what do I know?  Wink"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11796#msg11796"},{"f":"BitLex","d":1283285963,"b":[["q","Is It Better To Buy Or Generate Bitcoins?","Quote"],["t","I'd say: it depends.  Grin\n\nif you need coins to do stuff right now, there's no guaranteed way to generate them anyway, can't be \"better\" that way.\nif you dont need coins and just want to support the network, there's no need to buy any (or generate, to try would be enough).\n\ncan't even say which is cheaper, or less expensive, that again depends on where you live and what you have to invest (in power and/or hardware).\n\nfor me:\ni just went down from ~8000khs to ~1500khs at the latest difficulty-step, so i'm actually not expecting to gain lots of coins in the near future, but still generate to help find new blocks.\nrunning a machine (that sucks up >20W) only to generate coins is already useless to me (or needs to be bought/build/invested in first) and (watching current difficulty and market-prices) will prolly result in a loss.\ni'm wondering anyway, why the market didn't change at all the last 2 diff.steps, watched and waited a bit, but this is it for me, i'm done generating coins.   Grin\nsad thing is, that i have to wait about a month to get coins from MtGox too, but i'll at least get some more than 50btc at once, we'll need some other payment-options there quick.\n\nnice article!"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11801#msg11801"},{"f":"MoonShadow","d":1283286229,"b":[["q","> Quote from: creighto on August 31, 2010, 06:11:18 PM\n> > Quote from: jimbobway on August 31, 2010, 05:13:34 PM\n> > I can't wait for someone to write an application that allows group mining of bitcoins.  I just can't wait one month to see 50 bitcoins.\n>\n> I think that you missed the point of the blog article.\n\nHeh.  I did write the article.  But what do I know?  Wink","Quote from: jimbobway on August 31, 2010, 06:44:48 PM"],["t","Bi-polar?"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11802#msg11802"},{"f":"Ground Loop","d":1283303497,"b":[["t","The article is all about the cost of the hardware, neglecting the more significant cost: electricity.\n\nOnce you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.\nThe 24-core beast built in the article probably draws some serious current.  Hard to guess how much, but I'd guess about 500W?  Anyone know?\n\nThis will add 360kW/h a month to your electric bill, which will easily drive you into the next pricing tier, or maybe two tiers higher.  Now your marginal power can be $0.18 kW/hr.\nYikes.\nThat bitcoin miner would be about $2/day to run, or $788 a year, which means you've never matched the hardware cost of the system in two or three years.\n\nIf you have to actively cool the room with the computer, at least during daytime, double it again."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11808#msg11808"},{"f":"FreeMoney","d":1283307459,"b":[["q","i'm wondering anyway, why the market didn't change at all the last 2 diff.steps, watched and waited a bit, but this is it for me, i'm done generating coins.   Grin\nsad thing is, that i have to wait about a month to get coins from MtGox too, but i'll at least get some more than 50btc at once, we'll need some other payment-options there quick.\n\nnice article!","Quote from: BitLex on August 31, 2010, 08:19:23 PM"],["t","I don't know if this is the case here, but markets do anticipate things, I can't say that the difficulty increases were really surprising in any way. Profitable speculators also tend to even prices out over time. If you actually figure out how to \"buy low, sell high\" you are providing the service of evening out prices over time, or in the case of arbitrage, evening prices out indifferent locations."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11811#msg11811"},{"f":"MoonShadow","d":1283309292,"b":[["q","The article is all about the cost of the hardware, neglecting the more significant cost: electricity.\n\nOnce you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.","Quote from: Ground Loop on September 01, 2010, 01:11:37 AM"],["t","This is a calculation that depends highly on who you are and where you live.  I live in an area that recently had a 10%+ residental electric rate hike, to about 8 cents per KWH.  This is only slightly more expensive per btu than using natural gas with a 90% efficient gas heater versus a 100% efficent electric heater.  So the price difference for me to run any computer full tilt during the heating season, which is most certainly longer than Southern California, is about half a penny per kilowatt or less.  I don't even know anyone who bothers to shut down their computers from September to May to save money.  There's also someting to be said for the soothing white noise of a (good condition) cpu fan as the beast in the corner crunching numbers keeps your bedroom a couple degrees warmer so that you can turn the house thermostat down to 69 degrees at night.  I can't prove it, but I would bet that I actually save energy doing this, because otherwise my wife would insist on turning up the heat."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11812#msg11812"},{"f":"jimbobway","d":1283310677,"b":[["q","The article is all about the cost of the hardware, neglecting the more significant cost: electricity.\n\nOnce you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.\nThe 24-core beast built in the article probably draws some serious current.  Hard to guess how much, but I'd guess about 500W?  Anyone know?","Quote from: Ground Loop on September 01, 2010, 01:11:37 AM"],["t","The 24-core beast will draw a minimum of 380W (using the power supply calculator: http://educations.newegg.com/tool/psucalc/index.html)"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11816#msg11816"},{"f":"BitLex","d":1283318425,"b":[["q","I can't say that the difficulty increases were really surprising in any way.","Quote from: FreeMoney on September 01, 2010, 02:17:39 AM"],["t","difficulty increases of course weren't surprising, we can expect some more sooner or later.  Cheesy\nwhat surprised me was the non-responding market.\nif sellers have to invest more time/energy into mining, why do they still sell that cheap?\ni'm ok with it though, i wanna buy anyway.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=955.msg11819#msg11819"},{"f":"FreeMoney","d":1283339704,"b":[["q","> Quote from: Ground Loop on September 01, 2010, 01:11:37 AM\n> The article is all about the cost of the hardware, neglecting the more significant cost: electricity.\n>\n> Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.\n\nThis is a calculation that depends highly on who you are and where you live.  I live in an area that recently had a 10%+ residental electric rate hike, to about 8 cents per KWH.  This is only slightly more expensive per btu than using natural gas with a 90% efficient gas heater versus a 100% efficent electric heater.  So the price difference for me to run any computer full tilt during the heating season, which is most certainly longer than Southern California, is about half a penny per kilowatt or less.  I don't even know anyone who bothers to shut down their computers from September to May to save money.  There's also someting to be said for the soothing white noise of a (good condition) cpu fan as the beast in the corner crunching numbers keeps your bedroom a couple degrees warmer so that you can turn the house thermostat down to 69 degrees at night.  I can't prove it, but I would bet that I actually save energy doing this, because otherwise my wife would insist on turning up the heat.","Quote from: creighto on September 01, 2010, 02:48:12 AM"],["t","That's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?\n\nHeh, so bitcoins will be a cold climate manufactured good, lol."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11849#msg11849"},{"f":"lfm","d":1283359535,"b":[["q","That's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?","Quote from: FreeMoney on September 01, 2010, 11:15:04 AM"],["t","The power to the screen gets converted to heat too, even the light produced would get converted to heat."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11861#msg11861"},{"f":"MoonShadow","d":1283363677,"b":[["q","[\nThat's interesting. If you have no screen on then all of the energy spent is converted to heat right? So if you are heating the place anyway it is costless?","Quote from: FreeMoney on September 01, 2010, 11:15:04 AM"],["t","To a point, yes.  The trick is knowing where that point of dimishishing returns begins, and how it varies."],["q","Heh, so bitcoins will be a cold climate manufactured good, lol.","Quote"],["t","It already is.  I know from private conversations that a statisticly significant number of long-time forum members are Canadians.  At least one of whom has been selling off last winter's heat bill.  If there are more people who generate bitcoins in the northern hemisphere (which is almost certainly the case) one would expect to see a seasonal component to the difficulty.  At least once the difficultly reaches a mature balance in the future.  This is an effect that several of those distributed.net type people have noticed before.  Their overall computational power trends slightly up during the winter months in the northern hemisphere."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11866#msg11866"},{"f":"Gespenster","d":1283364257,"b":[["q","> Quote from: Ground Loop on September 01, 2010, 01:11:37 AM\n> The article is all about the cost of the hardware, neglecting the more significant cost: electricity.\n>\n> Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.\n> The 24-core beast built in the article probably draws some serious current.  Hard to guess how much, but I'd guess about 500W?  Anyone know?\n\nThe 24-core beast will draw a minimum of 380W (using the power supply calculator: http://educations.newegg.com/tool/psucalc/index.html)","Quote from: jimbobway on September 01, 2010, 03:11:17 AM"],["t","What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.\n\nA single Phenom II X4 consumes at full load approximately 125W (see TDP: http://en.wikipedia.org/wiki/AMD_Phenom), 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).\n\nAs you're expected to generate one block each day, you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ..."]],"u":"https://bitcointalk.org/index.php?topic=955.msg11867#msg11867"},{"f":"lfm","d":1283880551,"b":[["q","What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.\n\nA single Phenom II X4 consumes at full load approximately 125W (see TDP: http://en.wikipedia.org/wiki/AMD_Phenom), 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).\n\nAs you're expected to generate one block each day, you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ...","Quote from: Gespenster on September 01, 2010, 06:04:17 PM"],["t","Most of those power calculators will show you only the peak power needed which is generally at startup time, not at full load running. This is good for selecting the power supply you need but not so good for estimating the power costs over the long run. Unless this 6 socket beast is seriously different from smaller systems in that way."]],"u":"https://bitcointalk.org/index.php?topic=955.msg12170#msg12170"},{"f":"TTBit","d":1283886773,"b":[["t","I set up a Kill-a-Watt to my computer and calculated with 2200 khash/s, I was using 140 watts (monitors off). According to the calculator, I should produce a block every 14 days, 2 hours, 3 minutes, or every 338.05 hours. It would cost me 47.327 Kwh to produce a block, at 12 cents per Kwh, thats $5.68 per block, a net loser.\n\nWhat is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.\n\nDifficulty level 1000 by year end."]],"u":"https://bitcointalk.org/index.php?topic=955.msg12180#msg12180"},{"f":"FreeMoney","d":1283889149,"b":[["q","I set up a Kill-a-Watt to my computer and calculated with 2200 khash/s, I was using 140 watts (monitors off). According to the calculator, I should produce a block every 14 days, 2 hours, 3 minutes, or every 338.05 hours. It would cost me 47.327 Kwh to produce a block, at 12 cents per Kwh, thats $5.68 per block, a net loser.\n\nWhat is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.\n\nDifficulty level 1000 by year end.","Quote from: TTBit on September 07, 2010, 07:12:53 PM"],["t","2000 at least imo, but my guess is 8500."]],"u":"https://bitcointalk.org/index.php?topic=955.msg12187#msg12187"},{"f":"BitLex","d":1283890254,"b":[["q","What is interesting is the reports of the people producing 25,000 khash/sec with their video cards in the CUDA thread. If they are using less than 1000 watts (and should be), it would be profitable again to produce, electricity wise.\n\nDifficulty level 1000 by year end.","Quote from: TTBit on September 07, 2010, 07:12:53 PM"],["t","i just did a short test on the lately released cuda-client, here's the results\n\nAMD X3 @2.8ghz\n->stock client\n~3800khs ~150Watt\n\nGTX260\n->puddinpop's cuda client\n~33000khs ~200Watt\n\ncpu-work isn't profitable for me anymore, i already shut down most generators at the latest diff.step,\ngfx-crunching would indeed be profitable again,\ni don't really wanna trust a client that fondles with my balance on it's own though, so i don't use it.\nhopefully we'll see an open source client some day.\n\nbut your joking about that 1000, arent ya?\nend of the year?\nmaybe end of the week.  Grin "]],"u":"https://bitcointalk.org/index.php?topic=955.msg12189#msg12189"},{"f":"TTBit","d":1283944370,"b":[["t","using seconds from 12/18/2009 3:56:01 as base 0 (the last time difficulty was 1.0000), A y=mx+b linear regression of the log of difficulty levels:\n\nm=2.87698e-07\nb=-0.611057\n\nuse b=-363.4351 for the seconds you programmers use.\n\nexample: block 46368 was generated at 1269212064. exp(1269212064*2.87698e-07 - 363.4351) = exp(1.71409) = predicted level of 5.551602 vs actual level of 4.565162.\n\n <http://www.freeimagehosting.net/>\n\nThe correlation factor was 0.957 between the date and log of difficulty level.\n\nThis predicts future difficulty levels of:\n\n9/30/2010 : 677.7963\n10/31/2010 : 1,464.7148\n11/30/2010 : 3,087.5334\n12/31/2010 : 6,672.1461\n1/31/2011 : 14,418.4781\n2/28/2011 : 28,919.2776\n3/31/2011 : 62,494.4307\n4/30/2011 : 131,734.6149\n5/31/2011 : 284,677.9188\n6/30/2011 : 600,084.4486\n12/31/2011 : 58,149,375.6523\n\nIf the trend continues, it will be quite difficult to generate coins in the near future  Tongue"]],"u":"https://bitcointalk.org/index.php?topic=955.msg12216#msg12216"},{"f":"Immanuel","d":1283947782,"b":[["t","I don't like the total cost of the computer. You could do without the keyboard, mouse, monitor. In addition, get the cheapest RAM stick you can find, a cheap 8GB SSD (energy saving) then install Debian 5. Access it through SSH and turn on bitcoin. You could easily do it to $300-$500 less and cut power costs by getting a high-efficiency PSU."]],"u":"https://bitcointalk.org/index.php?topic=955.msg12222#msg12222"},{"f":"Anonymous","d":1283953354,"b":[["t","Someone should set up a newegg affiliate program and recommend the best bitcoin generation gear. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=955.msg12227#msg12227"},{"f":"Immanuel","d":1283953912,"b":[["q","Someone should set up a newegg affiliate program and recommend the best bitcoin generation gear. Smiley","Quote from: Anonymous on September 08, 2010, 01:42:34 PM"],["t","Once the GPU client gets perfected, I'm going to get a GTX 465, throw in a cheap dual-core CPU, 512MB RAM, and a case/cpu combo; then I am going place it in a closet and let it print Bitcoins for a year or two. Tongue It's about a $500 investment but with patience and careful energy management it might profit."]],"u":"https://bitcointalk.org/index.php?topic=955.msg12229#msg12229"},{"f":"satoshi","d":1283977659,"b":[["q","AMD X3 @2.8ghz\n->stock client\n~3800khs ~150Watt","Quote from: BitLex on September 07, 2010, 08:10:54 PM"],["t","Did you try -4way?"],["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.","Quote"],["t","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)\n\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"]],"u":"https://bitcointalk.org/index.php?topic=955.msg12248#msg12248","s":1,"n":443,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/443/"}]},{"id":"p208","k":"p","s":"bitcointalk","t":"Warning : Check your system clock (help me)","u":"https://bitcointalk.org/index.php?topic=960","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/208/","m":[{"f":"icaro","d":1283259344,"b":[["t","Warning :Check your system data and time , you may not be able to generate or receive the most recent blocks !\n\nWhat does it mean ?    Huh   I'm just with 2 connections and 500 blocks."]],"u":"https://bitcointalk.org/index.php?topic=960.msg11773#msg11773"},{"f":"MoonShadow","d":1283261273,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=960.msg11774#msg11774","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"satoshi","d":1283729780,"b":[["t","Any suggestions for better text to put for this error message so the next person will be less likely to be confused?\n\nIt's trying to tell them their clock is wrong and they need to correct it.\n\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)\n\nI've thought about NTP, but this is more secure."]],"u":"https://bitcointalk.org/index.php?topic=960.msg12063#msg12063","s":1,"n":434,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/434/","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"BioMike","d":1283750369,"b":[["q","I've thought about NTP, but this is more secure.","Quote from: satoshi on September 05, 2010, 11:36:20 PM"],["t","IMHO there is no reason for a modern system to not run a NTP client/daemon."]],"u":"https://bitcointalk.org/index.php?topic=960.msg12081#msg12081","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"Insti","d":1283777288,"b":[["t","I dont think the bitcoin client should start bloating itsself with additional NTP client functionality."]],"u":"https://bitcointalk.org/index.php?topic=960.msg12099#msg12099","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"Insti","d":1283777497,"b":[["q","Any suggestions for better text to put for this error message so the next person will be less likely to be confused?","Quote from: satoshi on September 05, 2010, 11:36:20 PM"],["t","\"Please check that your computers date and time are correct. If your clock is wrong Bitcoin will not work properly.\""]],"u":"https://bitcointalk.org/index.php?topic=960.msg12101#msg12101","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"Cdecker","d":1283777647,"b":[["t","I'd go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they'd do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.\n\nThe code is about 5 lines and some simple math (sums) when calculating the timestamps."]],"u":"https://bitcointalk.org/index.php?topic=960.msg12102#msg12102","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"BioMike","d":1283793918,"b":[["q","I dont think the bitcoin client should start bloating itsself with additional NTP client functionality.","Quote from: Insti on September 06, 2010, 12:48:08 PM"],["t","Hell no, NTP does a good job. Don't have other services changing the clock (also counts for bitcoin). Right tool for the right job!"]],"u":"https://bitcointalk.org/index.php?topic=960.msg12118#msg12118","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"satoshi","d":1283809266,"b":[["q","> Quote from: satoshi on September 05, 2010, 11:36:20 PM\n> Any suggestions for better text to put for this error message so the next person will be less likely to be confused?\n\"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly.\"","Quote from: Insti on September 06, 2010, 12:51:37 PM"],["t","Thanks."]],"u":"https://bitcointalk.org/index.php?topic=960.msg12132#msg12132","s":1,"n":436,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/436/","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"ribuck","d":1283858060,"b":[["q","Thanks.","Quote from: satoshi on September 06, 2010, 09:41:06 PM"],["t","Thank you Satoshi for sneaking that possessive apostrophe into \"computer's date\"!"]],"u":"https://bitcointalk.org/index.php?topic=960.msg12159#msg12159","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"agaumoney","d":1284050097,"b":[["q","I'd go for a small server that returns a unix timestamp, the client fetches it, computes the clock drift (difference in time) and all the protocol related times are based on that drift. The clocks would still drift a little (they'd do it anyway on the system clock) and we would not get perfect synchronization (impossible in distributed systems), but it would solve our current problems.\n\nThe code is about 5 lines and some simple math (sums) when calculating the timestamps.","Quote from: Cdecker on September 06, 2010, 12:54:07 PM"],["t","Why a server when so many are already out there?\n\nI'd agree that we don't want bitcoin client bloat, and definitely NO WAY the bitcoin client should be setting the system time.\n\nBut maybe it is worth it in the error case for the bitcoin client to put a message in the log and attempt to use a network time instead of system time.\n\nAs for the servers out there, the bitcoin client already has http, right?  Well, most http servers now provide the date in their headers.  For example, in python:"],["c","import os, re, urllib\ninfo = urllib.urlopen('http://www.yahoo.com/').info()\nregx = r'Date:\\s+[A-Z][a-z]{2}, (\\d{1,2}) ([A-Z][a-z]{2}) (\\d{1,4}) (\\d\\d:\\d\\d:\\d\\d)'\nd, M, Y, T = re.search(regx,str(info)).groups()\nm = 1+\"JanFebMarAprMayJunJulAugSepOctNovDec\".index(M)/3\nprint '%04d.%02d.%02d-%s' % (int(Y), m, int(d), T)"],["t","(that output format happens to work with \"date -us\" if you did want to set some system time)\n\nof course it would be better to check a couple of sites rather than relying on just yahoo to keep their http server time set properly.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=960.msg12323#msg12323","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"Cdecker","d":1284927248,"b":[["t","I think we all agree that setting the system time is a no go, but why can't we just use an offset internally and just circumvent the whole issue? We already have ways to synchronize (approximately) the clients, so why not make use of that?"]],"u":"https://bitcointalk.org/index.php?topic=960.msg13212#msg13212","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"LZ","d":1284953995,"b":[["t","Agreed. There is no need to set the system time.\nWe only need to use correct time in the program."]],"u":"https://bitcointalk.org/index.php?topic=960.msg13239#msg13239","sj":"Re: Warning : Check your system   ( Help me )"},{"f":"satoshi","d":1285259305,"b":[["t","I don't understand, are you under the impression that the program sets the system clock?  It doesn't."],["q","We already have ways to synchronize (approximately) the clients, so why not make use of that?","Quote from: Cdecker on September 19, 2010, 08:14:08 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=960.msg13833#msg13833","s":1,"n":459,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/459/","sj":"Re: Warning : Check your system   ( Help me )"}]},{"id":"p209","k":"p","s":"bitcointalk","t":"CryptoPP Assertion Error","u":"https://bitcointalk.org/index.php?topic=967","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/209/","m":[{"f":"chaseadam","d":1283362687,"b":[["t","When running with revision 146 (trunk) I get the following when the miner attempts to start:\n\nbitcoind: cryptopp/secblock.h:187: void CryptoPP::NullAllocator<T>::deallocate(void*, typename CryptoPP::AllocatorBase<T>::size_type) [with T = unsigned char]: Assertion `false' failed.\n\n+ cd '/tmp/rmake/builds/bitcoin/bitcoin--trunk/'; CFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector\" CXXFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector \" CPPFLAGS=\"\" CLASSPATH=\"\"  LDFLAGS=\"-g -O1 \" CC=gcc CXX=g++  make    \ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/util.o util.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/script.o script.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/db.o db.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/net.o net.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/irc.o irc.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/main.o main.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/rpc.o rpc.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/init.o init.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -O3 -o cryptopp/obj/sha.o cryptopp/sha.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -O3 -o cryptopp/obj/cpu.o cryptopp/cpu.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/ui.o ui.cpp\nui.h: In constructor 'CGetTextFromUserDialog::CGetTextFromUserDialog(wxWindow*, const std::string&, const std::string&, const std::string&, const std::string&, const std::string&)':\nui.h:308: warning: converting to 'int' from 'double'\nui.h:309: warning: converting to 'int' from 'double'\nui.cpp: In constructor 'CMainFrame::CMainFrame(wxWindow*)':\nui.cpp:264: warning: passing 'double' for argument 1 to 'void wxWindowBase::SetSize(int, int)'\nui.cpp:264: warning: passing 'double' for argument 2 to 'void wxWindowBase::SetSize(int, int)'\nui.cpp:287: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:288: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:289: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:290: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:291: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:292: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:293: warning: passing 'double' for argument 4 to 'long int wxGenericListCtrl::InsertColumn(long int, const wxString&, int, int)'\nui.cpp:299: warning: converting to 'int' from 'double'\nui.cpp:300: warning: converting to 'int' from 'double'\nui.cpp: In member function 'virtual void CMainFrame::OnIconize(wxIconizeEvent&)':\nui.cpp:379: warning: 'Iconized' is deprecated (declared at /usr/include/wx-2.9/wx/event.h:1950)\nui.cpp:387: warning: 'Iconized' is deprecated (declared at /usr/include/wx-2.9/wx/event.h:1950)\nui.cpp: In constructor 'CSendingDialog::CSendingDialog(wxWindow*, const CAddress&, int64, const CWalletTx&)':\nui.cpp:2005: warning: passing 'double' for argument 1 to 'void wxWindowBase::SetSize(int, int)'\nui.cpp:2005: warning: passing 'double' for argument 2 to 'void wxWindowBase::SetSize(int, int)'\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -DGUI -o obj/uibase.o uibase.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -msse2 -O3 -march=amdfam10 -o obj/sha256.o sha256.cpp\ng++ -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o bitcoin obj/util.o obj/script.o obj/db.o obj/net.o obj/irc.o obj/main.o obj/rpc.o obj/init.o cryptopp/obj/sha.o cryptopp/obj/cpu.o obj/ui.o obj/uibase.o obj/sha256.o -Wl,-Bstatic -l wx_gtk2ud-2.9 -Wl,-Bdynamic -l gtk-x11-2.0 -l SM -Wl,-Bstatic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l crypto -Wl,-Bdynamic -l gthread-2.0\n+ strip bitcoin\n+ copying /tmp/rmake/builds/bitcoin/bitcoin--trunk/bitcoin to /tmp/rmake/builds/bitcoin/_ROOT_/usr/bin/bitcoin\n+ cd '/tmp/rmake/builds/bitcoin/bitcoin--trunk/'; CFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector\" CXXFLAGS=\"-O2 -g -D_FORTIFY_SOURCE=2 -fstack-protector \" CPPFLAGS=\"\" CLASSPATH=\"\"  LDFLAGS=\"-g -O1 \" CC=gcc CXX=g++  make    bitcoind\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/util.o util.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/script.o script.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/db.o db.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/net.o net.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/irc.o irc.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/main.o main.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/rpc.o rpc.cpp\ng++ -c -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o obj/nogui/init.o init.cpp\ng++ -O2 -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -D__WXGTK__ -DNOPCH -DFOURWAYSSE2 -I\"/usr/include/wx-2.9\" -I\"/usr/lib64/wx/include/gtk2-unicode-debug-static-2.9\" -o bitcoind 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 cryptopp/obj/sha.o cryptopp/obj/cpu.o obj/sha256.o -Wl,-Bstatic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l crypto -Wl,-Bdynamic -l gthread-2.0"]],"u":"https://bitcointalk.org/index.php?topic=967.msg11864#msg11864"},{"f":"denger","d":1283694208,"b":[["t","I get a similar error with version 3.11 compile for CentOS 5.5:\n\nbitcoind: cryptopp/secblock.h:187: void CryptoPP::NullAllocator<T>::deallocate(void*, typename CryptoPP::AllocatorBase<T>::size_type) [with T = unsigned char]: Assertion `false' failed.\n\nI have tried wiping .bitcoin directory thinking some old stuff is incompatible, but get the same when starting fresh.\nAnyone can help?"]],"u":"https://bitcointalk.org/index.php?topic=967.msg12051#msg12051"},{"f":"denger","d":1283694655,"b":[["t","Forgot to mention that I only see this error when trying to run bitcoind with sox proxy:\n\n~/bitcoind -proxy=127.0.0.1:10000 -gen -server\n\nMy proxy is the ssh channel:\n\nssh -n -D localhost:10000 someone@somewhere.com <mailto:someone@somewhere.com> \"bash -c \\\"while true; do sleep 100; done\\\"\" &"]],"u":"https://bitcointalk.org/index.php?topic=967.msg12052#msg12052"},{"f":"satoshi","d":1283729132,"b":[["t","You can probably just comment out the line\ncryptopp/secblock.h:187\n  //assert(false);\n\nLet me know if it works, and watch if it memory leaks.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=967.msg12062#msg12062","s":1,"n":433,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/433/"}]},{"id":"p210","k":"p","s":"bitcointalk","t":"HTTP status codes from the JSON-RPC api","u":"https://bitcointalk.org/index.php?topic=969","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/210/","m":[{"f":"Gavin Andresen","d":1283372895,"b":[["t","I just submitted a patch to Satoshi to make bitcoin follow the JSON RPC over HTTP spec, <http://groups.google.com/group/json-rpc/web/json-rpc-over-http> and to use the standardized error codes from the JSON-RPC 1.1/2.0 specs.\n\nIf you talk directly to bitcoin via JSON-RPC calls, you might need to change your code to recognize the new HTTP status codes and the new format for the 'error' member of the JSON response.  For example:\n\nBEFORE, send {\"id\":\"123\", \"method\": \"nosuchmethod\", \"params\": [] } , get response:"],["c","HTTP/1.1 500 Internal Server Error\n...\n\n{\"result\":null,\"error\":\"Method not found.\",\"id\":\"123\"}"],["t","AFTER:"],["c","HTTP/1.1 404\n...\n\n{\"result\":null,\"error\":{\"code\":-32601,\"message\":\"Method not found\"},\"id\":\"123\"}"],["t","I also removed the broken 'Batch' support, to simplify the code.  I had JSON-RPC-2.0 batch support working properly, but backed those changes out because JSON-RPC 2.0 is way too cutting-edge for bitcoin to support right now (none of the JSON-RPC glue libraries support it yet, and the spec is still changing a bit)."]],"u":"https://bitcointalk.org/index.php?topic=969.msg11884#msg11884"},{"f":"Gavin Andresen","d":1283800684,"b":[["t","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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=969.msg12125#msg12125"},{"f":"satoshi","d":1283808081,"b":[["t","This is in SVN rev 147.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=969.msg12130#msg12130","s":1,"n":435,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/435/"}]},{"id":"p211","k":"p","s":"bitcointalk","t":"Switch to GPL","u":"https://bitcointalk.org/index.php?topic=989","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/211/","m":[{"f":"omegadraconis","d":1283741689,"b":[["t","A thought has occurred to me that bitcoins client is released under mit which allows for closed source clients that would give someone an advantage over everyone by modifying the client and not releasing the code. If we changed to GPL this would force anyone who created a modified client to release the source code under the terms of the GPL.\n\nA few thoughts for discussion here:\n\nDo you think switching to GPL would be a good idea?\n\nIf someone released a closed source client how could we enforce the GPL?\n\nWould changing to a GPL stifle development in anyway?\n\nWould this make it less likely for new clients to be developed?"]],"u":"https://bitcointalk.org/index.php?topic=989.msg12070#msg12070"},{"f":"mizerydearia","d":1283742432,"b":[["t","I am not sure how it would affect current/existing clients, but I believe switching to gpl would possibly stifle ArtForz's estimated ~25% dominance of block generations and total Bitcoin balance.\nTotal Bitcoins as of now: 3914550\nIf ArtForz had 25% of total Bitcoins, then: 978637.5\nIf each Bitcoin is worth $0.06, then total value: $58,718.25\n\nThese figures are not reliable, but are an example.\n\nHere's a better reference:\n\n7.28.2010: <ArtForz> for my opencl sha256 code the 5770 is only 5% faster than the 4870 per core-mhz\nblock 70800 1280322359"],["c","# date -d \"@1280322359\"\nWed Jul 28 08:05:59 CDT 2010"],["t","So estimated start time of ArtForz's opencl client was at block 70,800.  Current block count is 78,292.  7,492 blocks.\n\n7,492 * 50btc = 374,600btc.\n\n374,600btc * 25% = 93,650btc\n\n93,650btc * $0.06 = $5,619.\n\nSo, it is fairly safe to conclude that ArtForz has approximately ~$5,600ish value (and will most likely increase in value over time)\n\nIf they were to sell all bitcoins right now on open exchange markets, they could get a guaranteed amount of ~$2,348."],["c","$0.0616 each for BTC757.156 ($46.6408096) at mtg.\n$0.0615 each for BTC500 ($30.75) at mtg.\n$0.0609 each for BTC610.6 ($37.18554) at mtg.\n$0.0601367 each for BTC936 ($56.2879512) at mtg.\n$0.0601366 each for BTC2049 ($123.2198934) at mtg.\n$0.0601 each for BTC100 ($6.01) at mtg.\n$0.06 each for BTC525 ($31.5) at mtg.\n$0.0597 each for BTC25.963 ($1.5499911) at mtg.\n$0.0596622 each for BTC879 ($52.4430738) at mtg.\n$0.0592 each for BTC96.3 ($5.70096) at mtg.\n$0.059 each for BTC20 ($1.18) at mtg.\n$0.059 each for BTC1000 ($59) at bcm.\n$0.0585 each for BTC200 ($11.7) at mtg.\n$0.0581 each for BTC600 ($34.86) at mtg.\n$0.058 each for BTC1.207 ($0.070006) at mtg.\n$0.0574999 each for BTC515.4 ($29.63544846) at mtg.\n$0.0574215 each for BTC2404 ($138.041286) at mtg.\n$0.057 each for BTC200 ($11.4) at bcm.\n$0.056 each for BTC1000 ($56) at bcm.\n$0.055 each for BTC100 ($5.5) at bcm.\n$0.05148 each for BTC2404 ($123.75792) at mtg.\n$0.051 each for BTC500 ($25.5) at mtg.\n$0.0505 each for BTC1000 ($50.5) at bcm.\n$0.0501 each for BTC400 ($20.04) at bcm.\n$0.05 each for BTC100 ($5) at bcm.\n$0.05 each for BTC100 ($5) at bcm.\n$0.05 each for BTC100 ($5) at mtg.\n$0.05 each for BTC1000 ($50) at bcm.\n$0.05 each for BTC1000 ($50) at bcm.\n$0.05 each for BTC1000 ($50) at bcm.\n$0.04825 each for BTC2404 ($115.993) at mtg.\n$0.0472 each for BTC1000 ($47.2) at bcm.\n$0.045 each for BTC100 ($4.5) at bcm.\n$0.045 each for BTC200 ($9) at bcm.\n$0.044 each for BTC200 ($8.8) at bcm.\n$0.04 each for BTC500 ($20) at bcm.\n$0.04 each for BTC600 ($24) at mtg.\n$0.04 each for BTC1600 ($64) at bcm.\n$0.04 each for BTC2000 ($80) at bcm.\n$0.039 each for BTC500 ($19.5) at mtg.\n$0.038 each for BTC500 ($19) at mtg.\n$0.0375 each for BTC200 ($7.5) at bcm.\n$0.037 each for BTC500 ($18.5) at mtg.\n$0.035 each for BTC200 ($7) at bcm.\n$0.035 each for BTC500 ($17.5) at mtg.\n$0.035 each for BTC3000 ($105) at bcm.\n$0.034 each for BTC259.118 ($8.810012) at mtg.\n$0.033 each for BTC500 ($16.5) at mtg.\n$0.033 each for BTC1000 ($33) at bcm.\n$0.032 each for BTC500.001 ($16.000032) at mtg.\n$0.0301 each for BTC300 ($9.03) at bcm.\n$0.03 each for BTC21 ($0.63) at mtg.\n$0.03 each for BTC100 ($3) at bcm.\n$0.03 each for BTC100 ($3) at bcm.\n$0.03 each for BTC500 ($15) at bcm.\n$0.03 each for BTC1000 ($30) at bcm.\n$0.022 each for BTC1000 ($22) at bcm.\n$0.0202 each for BTC1000 ($20.2) at bcm.\n$0.02 each for BTC100 ($2) at bcm.\n$0.02 each for BTC500 ($10) at bcm.\n$0.02 each for BTC1000 ($20) at bcm.\n$0.02 each for BTC1000 ($20) at bcm.\n$0.02 each for BTC1000 ($20) at bcm.\n$0.02 each for BTC1000 ($20) at bcm.\n$0.015 each for BTC1000 ($15) at bcm.\n$0.0121 each for BTC5000 ($60.5) at bcm.\n$0.011 each for BTC5000 ($55) at bcm.\n$0.01 each for BTC1000 ($10) at bcm.\n$0.01 each for BTC1000 ($10) at bcm.\n$0.01 each for BTC1000 ($10) at bcm.\n$0.01 each for BTC1000 ($10) at bcm.\n$0.01 each for BTC2000 ($20) at bcm.\n$0.01 each for BTC5000 ($50) at bcm.\n$0.0096 each for BTC1000 ($9.6) at bcm.\n$0.007 each for BTC100 ($0.7) at bcm.\n$0.006 each for BTC10000 ($60) at bcm.\n$0.005 each for BTC1000 ($5) at bcm.\n$0.005 each for BTC1000 ($5) at bcm.\n$0.005 each for BTC5000 ($25) at bcm.\n$0.005 each for BTC8542.255 ($42.711275) at bcm.\nTotal amount for BTC93650 is $2348.64719856"]],"u":"https://bitcointalk.org/index.php?topic=989.msg12072#msg12072"},{"f":"mizerydearia","d":1283743856,"b":[["t","Perhaps it can be considered that based on the license as it is now that establishments as exemplified above could allow for individuals to dominate large percentages of total Bitcoins and nothing can stop them.  Could this could be a deterrent for the acceptance of Bitcoin and hinder its ability to succeed?  e.g. I haven't the programming/development skills to produce similar works and therefore establish equal or similar amount of block generations and therefore have a disadvantage  to others with proprietary implementations.\n\nWhile it may be considered to allow for proprietary implementations to establish wider acceptance, it also may be a hinderance to establishing wider acceptance for allowing proprietary implementations."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12074#msg12074"},{"f":"theymos","d":1283744690,"b":[["t","The GPL doesn't force you to release your source if you don't publish the software publicly. Even the AGPL wouldn't force you to release the source in this case, since you're not really allowing people to interface with your software.\n\nMIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12076#msg12076"},{"f":"omegadraconis","d":1283747140,"b":[["q","The GPL doesn't force you to release your source if you don't publish the software publicly. Even the AGPL wouldn't force you to release the source in this case, since you're not really allowing people to interface with your software.\n\nMIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.","Quote from: theymos on September 06, 2010, 03:44:50 AM"],["t","I did realize this is true on both accounts. I'm not by any mean saying switching to GPL is a super great idea I was just wondering what everyone thought about it. As has been pointed out it would do nothing to stop someone from making a private client which is fine. If someone spends the time to optimize a client and use it to there own gain then that fine so long as they don't control the whole generation of coins. I would compare that make your own client to capitalism, where as if we were to force everyone to release everything so the field was completely level would be loosely like communism."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12078#msg12078"},{"f":"BioMike","d":1283750120,"b":[["q","I would compare that make your own client to capitalism, where as if we were to force everyone to release everything so the field was completely level would be loosely like communism.","Quote from: omegadraconis on September 06, 2010, 04:25:40 AM"],["t","There we have the whole \"FOSS is commie\" discussion again.  Wink\n\nI think the use of which FOSS license isn't so much of a deal. I mean, there are a lot of licenses that fall under the OSI definition. And MIT is not so bad. I normally put my software under the GPL, because I like the fact that it is copyleft. But if another dev thinks an other license is better, who am I to judge (I didn't write any code for it). This is the same discussion as GPL vs. BSD (MIT being almost like the BSD license)."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12080#msg12080"},{"f":"omegadraconis","d":1283754436,"b":[["q","There we have the whole \"FOSS is commie\" discussion again.  Wink","Quote from: BioMike on September 06, 2010, 05:15:20 AM"],["t","AH but, I wasn't talking about FLOSS at all . Cheesy\n\nI meant that by leveling the generation rate across all clients everyone has the same chance to generate a block (well that is if everyone's computer was the exact same) hence commie. Where as if someone make a client to make more khashs then everyone else it's more like capitalism."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12084#msg12084"},{"f":"Cdecker","d":1283777419,"b":[["t","I still think we are talking about two different components:\n\n• The clients\n\n• The protocol\n\nThe protocol is open (not well documented but it's out there), while the clients do not have to abide to any special restriction AFAIK. Even if we were to enforce a license on the clients by adding a special clause to the protocol agreement, there would be users that modify an open source client, but then they don't sell it so that they can still keep it closed source.\nIn one of my projects we are using the RPL, which isn't open source in that sense, it specifies that any modifications to the project have to be shared with the original community, but still that doesn't avoid a client being kept closed source from the start.\nOnce the network has grown enough it'll get really hard for a single entity to ever tip over the balance like ArtForz because there are more people with the resources and they will compete for the top spot, and thus balance things out.\n\nHow about a bounty for both the best performing source enhancement and for the best performing community driven rig? Something like the Netflix 1'000'000$ bounty for code improvements?"]],"u":"https://bitcointalk.org/index.php?topic=989.msg12100#msg12100"},{"f":"singpolyma","d":1283816577,"b":[["t","I'm against any switch to copyleft.  If the primary bitcoin implementation is copyleft, then at some point someone will want/need a copycentre implementation and duplicate a lot of work.  Liberal licensing is the best way to minimize duplicate work."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12139#msg12139"},{"f":"BioMike","d":1283836716,"b":[["q","Liberal licensing is the best way to minimize duplicate work.","Quote from: singpolyma on September 06, 2010, 11:42:57 PM"],["t","Heh... no clear view of the current software world? Wink\nIf you see how many different \"duplicate\" software packages there are, duplicate work is done a lot (for various reasons, even licenses).\nI think even on this forum people are working on a second client (the python client). Having multiple clients does not have to be a bad thing."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12149#msg12149"},{"f":"neptop","d":1283883278,"b":[["t","Nobody, who is sane licenses stuff that is supposed to be a major implementation of a protocol using a restrictive license as GPL. If you do this now you'd most likely cause a fork anyway, because they want to stay with this license.\n\nWhen it comes to preventing people from using faster clients there isn't anything you can do. The best thing would be implement it into the main client, so you can be sure nobody dominates because of this. If someone is interested in a stable currency it is better to give it to everyone, because there can be someone who simply has more money to buy FPGAs, GPUs or whatever.\n\nWhat would really hinder someone to simply ignore the license. With GPL and AGPL software you don't even violate the license, but even a custom license would not stop it.\n\nThe MIT (and some others, like BSD) are nice if you want to create standards. That's why most libraries use them and the hardcore-GNU-folks have created a LGPL, but I can't really think of anything that was first implemented using the LGPL and then became a widely used standard. Maybe there is something, maybe much more than I'd expect. I am not a big friend of the GPL, but it's not like I'd hate it. After all it's still Open Source and that's what I care most.\n\nBut I think nobody really thinks about relicensing it anyway.\n\nWhat do you think about creating bounties for performance improvements. Like someone should add support for ATI stream? We could make a thread similar to the EFF donation thread. I know there is a thread about it, but it is most likely not the only possible performance improvement and of course not the only (C)PU."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12173#msg12173"},{"f":"BioMike","d":1283884622,"b":[["t","Protocols are IMHO not licensable anyway.\n\nIf you do clean room reverse engineering, you could make a compatible interface to a protocol and would not have to agree with any license."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12176#msg12176"},{"f":"Cdecker","d":1283892282,"b":[["q","Protocols are IMHO not licensable anyway.\n\nIf you do clean room reverse engineering, you could make a compatible interface to a protocol and would not have to agree with any license.","Quote from: BioMike on September 07, 2010, 06:37:02 PM"],["t","While I agree that reverse engineering is always a possibility, protocols can be licensed under different Intellectual Property regulations, that may or may not include licenses (see patents...)"]],"u":"https://bitcointalk.org/index.php?topic=989.msg12192#msg12192"},{"f":"lfm","d":1284087406,"b":[["q","So, it is fairly safe to conclude that ArtForz has approximately ~$5,600ish value (and will most likely increase in value over time)","Quote from: mizerydearia on September 06, 2010, 03:07:12 AM"],["t","Unless he already sold them."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12351#msg12351"},{"f":"hugolp","d":1284099780,"b":[["q","MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.","Quote from: theymos on September 06, 2010, 03:44:50 AM"],["t","I dont have any problem with MIT license, but there are a lot of companies that are using and developing GPL software. Saying that companies dont like GPL is not true."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12357#msg12357"},{"f":"fellowtraveler","d":1284152824,"b":[["q","> Quote from: theymos on September 06, 2010, 03:44:50 AM\n> MIT-style licensing is the only way to ensure widespread adoption. Companies won't touch GPLed software.\n\nI dont have any problem with MIT license, but there are a lot of companies that are using and developing GPL software. Saying that companies dont like GPL is not true.","Quote from: hugolp on September 10, 2010, 06:23:00 AM"],["t","The GPL is the same as any other commercial license.  Any company can license a GPL'd software just the same as they would license any other software: by contacting the developer and arranging for a commercial license.\n\nThe GPL just adds the EXTRA benefit that you can also use it for free, as long as your code is ALSO open source.\n\nSo any company that has a problem with GPL, must have a problem with ALL commercial licenses as well, and thus they are stuck using ONLY software under the MIT or Apache license. Presumably such a company doesn't run Mac or Windows in-house."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12376#msg12376"},{"f":"bytemaster","d":1284162683,"b":[["t","Of course those anarcho-capitalits among us who do not recognize \"copyright\" as natural because it is an attempt to limit what someone else can do with their knowledge and information is not \"scarce\" as each new copy does not diminish the original owners property.  So you cannot copyright code any more than music or anything else.  Once you share an idea with someone else it is in their head and there is no taking it back nor telling them what they can do.  Copyright does not exist without the state and is ARBITRARY in its duration. \n\nConclusion, copyright and licenses only matter to statists.  It is a \"monopoly\" that is maintained by force vs free competition.   \n\nIf you want a \"competitive advantage\" never release the code.   If you release the code, you have no right to use force to prevent others from using, distributing, or creating derivative works from it."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12390#msg12390"},{"f":"Macho","d":1284171014,"b":[["t","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.\n\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.\n\nI did not realize current bitcoin client was released under MIT license,\n\nThis should be changed to GPL IMMEDIATELY!\n\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.\n\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 Wink"]],"u":"https://bitcointalk.org/index.php?topic=989.msg12400#msg12400"},{"f":"BioMike","d":1284215047,"b":[["t","Ehh.... Macho, bitcoin IS open source. MIT license IS a open source license.\nNo closed source, proprietary software or DRM here."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12414#msg12414"},{"f":"satoshi","d":1284319493,"b":[["t","If the only library is closed source, then there's a project to make an open source one.\n\nIf the only library is GPL, then there's a project to make a non-GPL one.\n\nIf the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=989.msg12494#msg12494","s":1,"n":451,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/451/"}]},{"id":"p212","k":"p","s":"bitcointalk","t":"bitcoind as daemon in OSX","u":"https://bitcointalk.org/index.php?topic=992","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/212/","m":[{"f":"nelisky","d":1283809446,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=992.msg12133#msg12133"},{"f":"satoshi","d":1283809965,"b":[["t","Can you build?\n\nTry changing line 78 of init.cpp from:\n#ifdef __WXGTK__\n\nto:\n#ifndef __WXMSW__\n\nIf that works, I'll change the source.  It should work."]],"u":"https://bitcointalk.org/index.php?topic=992.msg12135#msg12135","s":1,"n":438,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/438/"}]},{"id":"p213","k":"p","s":"bitcointalk","t":"Always pay transaction fee?","u":"https://bitcointalk.org/index.php?topic=994","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/213/","m":[{"f":"jgarzik","d":1283829454,"b":[["t","To accurately reflect that processing a transaction has certain resource costs across the network, I propose that tx fee be required for every transaction after X datetime (where X is a few months in the future)."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12145#msg12145"},{"f":"MoonShadow","d":1283832639,"b":[["t","I propose that that number of months be 1440."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12147#msg12147"},{"f":"caveden","d":1283843941,"b":[["t","That will probably happen spontaneously if someone make a client (or add the option to the current one) that allows the user to charge transaction fees for the blocks it generates."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12152#msg12152"},{"f":"FreeMoney","d":1283846689,"b":[["t","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.\n\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.\n\nJgarzik, do you have a guess as to the resource costs of a normal transaction?"]],"u":"https://bitcointalk.org/index.php?topic=994.msg12155#msg12155"},{"f":"satoshi","d":1283877141,"b":[["t","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.\n\nThe threshold should probably be lower than it currently is.\n\nI don't think the threshold should ever be 0.  We should always allow at least some free transactions."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12168#msg12168","s":1,"n":439,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/439/","qt":["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. The threshold should probably be lower than it currently is. I don't think the threshold should ever be 0.  We should always allow at least some free transactions."],"qc":["fees","nodes"]},{"f":"lfm","d":1283880982,"b":[["t","If you WANT to start paying the transaction fees now you can with the -paytxfee=0.01\n (beta?) command line switch. If more people use this switch then it might help discourage others from requiring compulsory fees."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12171#msg12171"},{"f":"MoonShadow","d":1283887229,"b":[["q","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.\n\nThe threshold should probably be lower than it currently is.\n\nI don't think the threshold should ever be 0.  We should always allow at least some free transactions.","Quote from: satoshi on September 07, 2010, 04:32:21 PM"],["t","What is the current threshold, and how does a client know to pay for this in advance?"]],"u":"https://bitcointalk.org/index.php?topic=994.msg12182#msg12182"},{"f":"theymos","d":1283902173,"b":[["q","What is the current threshold, and how does a client know to pay for this in advance?","Quote from: creighto on September 07, 2010, 07:20:29 PM"],["t","http://www.bitcoin.org/wiki/doku.php?id=transaction_fee"]],"u":"https://bitcointalk.org/index.php?topic=994.msg12199#msg12199"},{"f":"satoshi","d":1283967014,"b":[["t","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.\n\nIt's not a big deal if we reach the threshold.  Free transactions would just take longer to get into a block.\n\nI did a rough tally of 4000 blocks from around 74000-78000.  This is excluding the block reward transactions:\n\nThere were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.\n\nAverage transaction bytes per block was 428 bytes, or 214 bytes per transaction.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=994.msg12237#msg12237","s":1,"n":441,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/441/","qt":["The 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.","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."],"qc":["fees","scalability"]},{"f":"satoshi","d":1285258115,"b":[["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.","Quote from: satoshi on September 08, 2010, 05:30:14 PM"],["t","I implemented this change in SVN rev 157.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=994.msg13829#msg13829","s":1,"n":457,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/457/"}]},{"id":"p214","k":"p","s":"bitcointalk","t":"Version 0.3.12","u":"https://bitcointalk.org/index.php?topic=999","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/214/","m":[{"f":"satoshi","d":1283887075,"b":[["t","Version 0.3.12 is now available.\n\nFeatures:\n- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)\n- json-rpc command line returns exit codes.\n- json-rpc \"backupwallet\" command.\n- Recovers and continues if an exception is caused by a message you received.  Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.\n\nIf you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {\"code\":<number>,\"message\":<string>}, which is the standard.  See this thread:\nhttp://bitcointalk.org/index.php?topic=969.0\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/"]],"u":"https://bitcointalk.org/index.php?topic=999.msg12181#msg12181","s":1,"n":440,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/440/"},{"f":"theymos","d":1283905504,"b":[["t","What does the prohibition of \"nonstandard\" transactions do?"],["c","main.cpp:506\n// Rather not work on nonstandard transactions\nif (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)\n  return error(\"AcceptToMemoryPool() : nonstandard transaction\"); "],["t","What is included in \"GetSigOpCount\", and what does \"GetSerializeSize\" measure?\n\nThis is \"lightly\" enforced by the network:"],["c","main.cpp:1425\n// Check that it's not full of nonstandard transactions\nif (nHeight > 79400 && GetSigOpCount() > MAX_BLOCK_SIGOPS)\n  return error(\"AcceptBlock() : too many nonstandard transactions\"); "]],"u":"https://bitcointalk.org/index.php?topic=999.msg12202#msg12202"},{"f":"satoshi","d":1283969164,"b":[["t","Bitcoin clients currently only create and recognize transactions that match two possible templates. \n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=999.msg12240#msg12240","s":1,"n":442,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/442/"}]},{"id":"p215","k":"p","s":"bitcointalk","t":"Auto-detect for 128-bit 4-way SSE2","u":"https://bitcointalk.org/index.php?topic=1007","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/215/","m":[{"f":"satoshi","d":1283994245,"b":[["t","SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2.  We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.\n\nIt uses the CPUID instruction to get the CPU brand, family, model number and stepping.  That's the easy part.  Knowing what to do with the model number is the hard part.  I was not able to find any table of family, model and stepping numbers for CPUs.  I had to go by various random reports I saw.\n\nHere's what I ended up with:"],["c","  // We need Intel Nehalem or AMD K10 or better for 128bit SSE2\n  // Nehalem = i3/i5/i7 and some Xeon\n  // K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II\n  //  Intel Core i5  family 6, model 26 or 30\n  //  Intel Core i7  family 6, model 26 or 30\n  //  Intel Core i3  family 6, model 37\n  //  AMD Phenom    family 16, model 10\n  bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >=  60026) ||\n                   (fAMD   && nFamily * 10000 + nModel >= 160010));"],["t","I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.\n\nIf it's wrong, you can still override it with -4way or -4way=0.\n\nIt prints what it finds in debug.log.  Search on CPUID.\n\nThis is only enabled if built with GCC."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12262#msg12262","s":1,"n":444,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/444/"},{"f":"tcatm","d":1284044547,"b":[["t","You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12316#msg12316"},{"f":"nelisky","d":1284046748,"b":[["q","You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.","Quote from: tcatm on September 09, 2010, 03:02:27 PM"],["t","Yeah, while implementing the cuda hasher I thought about this. There should be an interface to the hashing handler (or even a full miner per implementation) and we should have a simple way of giving it a known block, ask it to hash 1000 nonces and compare the result, while benchmarking at the same time. Shouldn't be too hard to implement and would help when developing new algorithms.\n\nThe interface schema would also help if we were to plug in an fpga based engine or something of the kind, having specific entry points into the code without having to tweak on the default mining schema."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12321#msg12321"},{"f":"jgarzik","d":1284048440,"b":[["q","You should benchmark all implementations (using cpu time, not realtime) and choose the fastest and while benchmarking check whether the algorithm actually works.","Quote from: tcatm on September 09, 2010, 03:02:27 PM"],["t","+1 agreed.  It's not difficult or time-consuming for each user to do this at startup."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12322#msg12322"},{"f":"teknohog","d":1284060725,"b":[["t","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\n#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)\n\nto make it compile again, at least on ARM."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12336#msg12336"},{"f":"lfm","d":1284086851,"b":[["t","I wonder if we could get the VIA C7 code included with an autodetect in the standard clients? Or is this just too rare a beast to trouble the main code over? The C7 does work with the standard clients with regular pentium or sse2 code albeit slower."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12349#msg12349"},{"f":"nimnul","d":1284122051,"b":[["t","> There should be an interface to the hashing handler (or even a full miner per implementation)\n\n+1. In case someone wants FPGA/whatever specific accelerator he has."]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12361#msg12361"},{"f":"satoshi","d":1284142266,"b":[["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\n#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)\n\nto make it compile again, at least on ARM.","Quote from: teknohog on September 09, 2010, 07:32:05 PM"],["t","Added in SVN rev 152"]],"u":"https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372","s":1,"n":448,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/448/"}]},{"id":"p216","k":"p","s":"bitcointalk","t":"Won't let me send coins because it requires a transaction fee?","u":"https://bitcointalk.org/index.php?topic=1013","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/216/","m":[{"f":"Anonymous","d":1284040614,"b":[["t","adg"]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12309#msg12309","sj":"adg"},{"f":"theymos","d":1284041111,"b":[["t","If you send your entire balance, then you won't have enough left to pay any fee. You could send 49.99.\n\nI don't know why that's happening. There shouldn't be a fee for any non-combined transaction."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12310#msg12310"},{"f":"theymos","d":1284057793,"b":[["t","0.3.12 contains some changes to transaction fees. Are you using that?"]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12329#msg12329"},{"f":"TTBit","d":1284063024,"b":[["t","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.\n\nFresh blocks take something like 100 blocks to confirm. I assume you waited."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12339#msg12339"},{"f":"satoshi","d":1284078204,"b":[["t","What version is the one where this happened?  Release build, or built it yourself?  Which operating system? \n\nWere you sending by IP or by Bitcoin Address?\n\nWhen you sent 49.99, did it prompt you to pay a 0.01 fee?\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341","s":1,"n":445,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/445/"},{"f":"satoshi","d":1284079597,"b":[["t","I think I know what happened.  Doubleclick on the generated transaction.  It probably has a sub-0.01 transaction fee in it.\n\nSomeone has been paying a 0.00000010 transaction fee.  I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it.  Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.\n\nIt would normally be harmless except in this corner case.  I should add a special case to CreateTransaction to handle this."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12342#msg12342","s":1,"n":446,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/446/"},{"f":"nelisky","d":1284127356,"b":[["t","I'm really puzzled with all this. I also generated a block and transferred it out on the spot. Looking at the transaction:\n\n     \"address\" : \"1LCSXSx8sjcZKHFXbyasBsuEdJtBVRaco7\",\n        \"label\" : \"\",\n        \"txid\" : \"1249190d1a13b03b51c27ded2e8441d446a8ae6ef90f90db31a8267da0845685\",\n        \"txtime\" : 1283997623,\n        \"category\" : \"debit\",\n        \"amount\" : 50.01000000,\n        \"confirmations\" : 228\n    },\n\nit seems I paid the fee too. Why would that be? A block that had too many tx, the value coming from multiple small value purses (but the client should see one purse that satisfies the whole transaction, right?) or what else?"]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12363#msg12363"},{"f":"theymos","d":1284129072,"b":[["q","So I lost a penny in it. My question then, that transaction fee, then goes to the next block? Or the one before the one I generated?","Quote from: davidonpda on September 10, 2010, 01:45:58 PM"],["t","You didn't pay a transaction fee. You have .01000010 in your balance; you just can't spend it. The network would accept it if you sent the entire 0.01000010 to another address (you can't break it apart), but the Bitcoin interface doesn't support such high precision."],["q","Since fees apply to transactions less than 0.01, adding a transaction fee should be at least 0.01 right?","Quote"],["t","That's not network-enforced. Transaction fees are not \"outs\", so they're not subject to the \"dust spam\" restriction."],["q","it seems I paid the fee too. Why would that be? A block that had too many tx, the value coming from multiple small value purses (but the client should see one purse that satisfies the whole transaction, right?) or what else?","Quote from: nelisky on September 10, 2010, 02:02:36 PM"],["t","You received a fee of 0.01. You didn't pay one."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12364#msg12364"},{"f":"satoshi","d":1284138753,"b":[["t","The fix is in SVN rev 151.\n\nYou will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade."]],"u":"https://bitcointalk.org/index.php?topic=1013.msg12368#msg12368","s":1,"n":447,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/447/"}]},{"id":"p217","k":"p","s":"bitcointalk","t":"Memory leak","u":"https://bitcointalk.org/index.php?topic=1023","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/217/","m":[{"f":"eurekafag","d":1284357104,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1023.msg12522#msg12522"},{"f":"satoshi","d":1284916923,"b":[["t","Bouncing between 0 and 2 connections could be if it's connecting to itself.  Are you using the \"-connect\" switch?\n\nDid you compile it or is this a release build, and what version?\n\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?\n\nThe wait function on linux is:\n\ninline void Sleep(int64 n)\n{\n    boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n));\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."]],"u":"https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201","s":1,"n":452,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/452/"},{"f":"eurekafag","d":1284971920,"b":[["t","Hmm, now the bug is gone though I remember how it was. That's the compiled release binary, 0.3.12 as I already mentioned. I didn't use -connect. Flickering was fast from 0 to 2 (less than half second) and then there was a pause in about a second with 0 connections. So the flicker itself was almost every second (not faster). Looks like it got connrefused instantly or such. I watched logs, sorry didn't saved them but there was nothing interesting just connect and disconnect without a reason.\n\nI measured the RES memory with htop. It updates once per second that's why I can't see the real leak speed. Now the client tries to connect after startup and flickers 0-2, too, but just 5-10 times and then establishes one connection. Then it flickers between 1 and 3 and no leaks happen. Then connection number grows up to 40 or even more, everything is stable. To reproduce this try to switch off the network connection right after the client gets IPs from IRC so it will try to connect and fail."]],"u":"https://bitcointalk.org/index.php?topic=1023.msg13434#msg13434"},{"f":"eurekafag","d":1286089662,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1023.msg15075#msg15075"},{"f":"satoshi","d":1286143620,"b":[["t","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.\n\nIRC seems to be working.  It ought to have other nodes to try.\n\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.\n\nYou can try moving addr.dat aside.  Maybe there's something wrong in it.\n\nAre you using -addnode?"]],"u":"https://bitcointalk.org/index.php?topic=1023.msg15150#msg15150","s":1,"n":481,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/481/"}]},{"id":"p218","k":"p","s":"bitcointalk","t":"Message Encryption as a built-in feature?","u":"https://bitcointalk.org/index.php?topic=1032","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/218/","m":[{"f":"BrightAnarchist","d":1284443051,"b":[["t","Bitcoin clients should have a built in simple message encryption/decryption system, perhaps based off of your actual Bitcoin addresses themselves.\n\nThis would make doing trades on sites like biddingpond much easier, since you don't need to both agree on a separate app like PGP before communicating over email.\n\nMost of the time I bet people don't even bother to use encryption, but I think it's a good idea to use it when doing trades in Bitcoins.\n\nThoughts?"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12686#msg12686"},{"f":"em3rgentOrdr","d":1284443765,"b":[["t","I like that idea!  Simply integrate an opensource library library like pgp into bitcoin. \n\nBTW, are the messages attached when sending bitcoins to ip addresses currently clear text or encrypted?"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12689#msg12689"},{"f":"theymos","d":1284468124,"b":[["q","BTW, are the messages attached when sending bitcoins to ip addresses currently clear text or encrypted?","Quote from: em3rgentOrdr on September 14, 2010, 05:56:05 AM"],["t","They're not encrypted, and there's no authentication, so you shouldn't send to an IP over the Internet."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12750#msg12750"},{"f":"BioMike","d":1284483269,"b":[["t","You could attach an already encrypted text to it, right?"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12777#msg12777"},{"f":"theymos","d":1284487003,"b":[["q","You could attach an already encrypted text to it, right?","Quote from: BioMike on September 14, 2010, 04:54:29 PM"],["t","You could, but any MITM could modify it / steal your coins..."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12782#msg12782"},{"f":"jgarzik","d":1284490701,"b":[["t","There should be a UTF8 text field \"memo\" attached to each transaction.\n\n• encrypt by default, with payee's public key\n\n• limit to 256 chars or so\n\n• optionally disable encryption (similar to Pecunix feature which makes a single transaction publicly visible)"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12787#msg12787"},{"f":"theymos","d":1284491079,"b":[["t","You could use your Bitcoin keys for authentication, but ECDSA doesn't support encryption."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12789#msg12789"},{"f":"Gavin Andresen","d":1284492934,"b":[["q","encrypt by default, with payee's public key","Quote from: jgarzik on September 14, 2010, 06:58:21 PM"],["t","... but a payer typically has only the bitcoin address, and not the payee's full public key.  There'd have to be some way to get the full public key for a bitcoin address.\n\nI like the idea of being able to send encrypted messages to \"whoever has bitcoin address BLAH\", but I'm not sure that functionality should be piggybacked on the \"send BLAH X.YZ bitcoins\".\n\nIf they were implemented under the covers as separate functions, then a \"Send a message along with payment\" could easily be implemented as:\n  1. Send BLAH X.YZ bitcoins, and note the transaction ID.\n  2. Send BLAH an encrypted message:   \"txid:{transaction_id}:Please send the sixteen My Little Pony DVDs to...\""]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12792#msg12792"},{"f":"teppy","d":1284559795,"b":[["t","I've been wanting something like this since day 1.\n\nA Tale in the Desert V accepts Bitcoins now. Each month, the procedure is:\n\n1. Player clicks an in-game menu item \"Pay for my subscription using Bitcoins.\" A unique address is created.\n2. The game says \"Send 150BTC to this address: xxxxxxx\" (There's a \"Copy to Clipboard\" button on the dialog.)\n3. The player sends the BTC\n4. The player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)\n\nThe procedure only takes 15-30 seconds total - probably quicker than typing in a credit card number. However, with the ability to attach a message, the procedure becomes:\n\n1. Player sends 150BTC to the standard ATITD Bitcoin address with his character name in the message field.\n2. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)\n\nWe already have a couple players using Bitcoins to pay for subscriptions. One has generated his BTC, and the other has purchased some on one of the markets."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12873#msg12873"},{"f":"Insti","d":1284566142,"b":[["q","However, with the ability to attach a message, the procedure becomes:\n\n1. Player sends 150BTC to the standard ATITD Bitcoin address with his character name in the message field.\n2. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)\n\nWe already have a couple players using Bitcoins to pay for subscriptions. One has generated his BTC, and the other has purchased some on one of the markets.","Quote from: teppy on September 15, 2010, 02:09:55 PM"],["t","If you don't cheat and leave out steps the procedure is:\n\n1. Player finds the standard ATITD Bitcoin address somehow. (and still needs to copy/paste it.)\n2. The player enters his username.\n3. The player sends the BTC\n4. Player clicks \"I have sent the Bitcoins.\" (System then verifies and activates account.)\n\nI don't see how this is an improvement.\n\n(Step 4 in both cases would seem to be redundant if your system is watching bitcoin transactions.)\n\nEdit:\nI'm not sure what is so great about having a single Bitcoin address to receive payments from everybody, since you still need a reference ID of some kind. When individual Bitcoin addresses are trivial to generate. (But you are actually running a service that accepts Bitcoins, so you probably know more than I do.)"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12883#msg12883"},{"f":"teppy","d":1284574126,"b":[["t","It's an improvement because payments can be made without running the game software, or made on behalf of other players (which is common in our game at least), or made for several secondary accounts quickly (also which is common in our game.)\n\nThough it doesn't apply to ATITD, it would also strengthen anonymity for those who need it: A website could be set up on a static datastore like Freenet, rather than requiring a live network like Tor."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12902#msg12902"},{"f":"Anonymous","d":1284600398,"b":[["t","    A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.\n\n Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12935#msg12935"},{"f":"em3rgentOrdr","d":1284601063,"b":[["q","    A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.\n\n Cheesy","Quote from: Anonymous on September 16, 2010, 01:26:38 AM"],["t","Great point...I've heard something called hashcash does this for email.  But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12937#msg12937"},{"f":"LZ","d":1284601847,"b":[["t","Hey, I just thought about it yesterday! Shocked"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12938#msg12938"},{"f":"Anonymous","d":1284602203,"b":[["q","> Quote from: Anonymous on September 16, 2010, 01:26:38 AM\n>     A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.\n>\n>  Cheesy\n\nGreat point...I've heard something called hashcash does this for email.  But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached.","Quote from: em3rgentOrdr on September 16, 2010, 01:37:43 AM"],["t","  People think nothing of sending text messages or mms that costs .50c each.  Shocked"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12941#msg12941"},{"f":"Anonymous","d":1284602258,"b":[["q","Hey, I just thought about it yesterday! Shocked","Quote from: lzsaver on September 16, 2010, 01:50:47 AM"],["t","pwned!\n\n Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12942#msg12942"},{"f":"Anonymous","d":1284602930,"b":[["t","Something like this combined with the pay it forward project http://bitcointalk.org/index.php?topic=922.msg12917#msg12917 would really increase the hardness of the network to attacks? Half your fee would go to the person you sent the message to and the other half would go to 3 randomn people -or split equally to increase anonymity Cheesy\n\nAs an extra security measure you could also send 3 dummy messages or however many you decided so the real message was hidden.The fee you sent would then be divided by however many security splits you decided on.  This could mean you might get randomn bitcoin payments all day just for having a bitcoin message address. Think of twitter crossed with hashcash and email. To the outside world there would be no difference from a message to a payment you made.\n\n19tq9NYFsSCMRUkc12v363tHgAeUokoVam just made a peanut butter sandwich!\n\n Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12944#msg12944"},{"f":"em3rgentOrdr","d":1284628449,"b":[["q","Something like this combined with the pay it forward project http://bitcointalk.org/index.php?topic=922.msg12917#msg12917 would really increase the hardness of the network to attacks? Half your fee would go to the person you sent the message to and the other half would go to 3 randomn people -or split equally to increase anonymity Cheesy\n\nAs an extra security measure you could also send 3 dummy messages or however many you decided so the real message was hidden.The fee you sent would then be divided by however many security splits you decided on.  This could mean you might get randomn bitcoin payments all day just for having a bitcoin message address. Think of twitter crossed with hashcash and email. To the outside world there would be no difference from a message to a payment you made.","Quote from: Anonymous on September 16, 2010, 02:08:50 AM"],["t","Very clever!!!  I like that idea...  Plus, with bitcoin, you can customize your level of security: pay more bitcoins and you can send more false messages and have more security splits..."],["q","> Quote from: em3rgentOrdr on September 16, 2010, 01:37:43 AM\n> > Quote from: Anonymous on September 16, 2010, 01:26:38 AM\n> >     A secure messaging system could have other benefits. The problem of spam is increased because it costs nothing to send email. A short message service that you needed to pay a few bitcoins for to send a message might revolutionise sms or email for those who are tired of sorting viagra and nigerian scam emails all day long.\n> >\n> >  Cheesy\n>\n> Great point...I've heard something called hashcash does this for email.  But with bitcoin, one can additionally prioritize messages: .g. the message with 10 BTC attached to it is probably more important than the message with .01 BTC attached.\n\n  People think nothing of sending text messages or mms that costs .50c each.  Shocked","Quote from: Anonymous on September 16, 2010, 01:56:43 AM"],["t","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!!!   Angry\n\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..."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg12976#msg12976"},{"f":"satoshi","d":1284936420,"b":[["t","Theymos already said this...  ECDSA does not support encrypting messages.  Only digital signatures."]],"u":"https://bitcointalk.org/index.php?topic=1032.msg13221#msg13221","s":1,"n":456,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/456/"}]},{"id":"p219","k":"p","s":"bitcointalk","t":"Issues building bitcoin on Windows 7","u":"https://bitcointalk.org/index.php?topic=1034","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/219/","m":[{"f":"LobsterMan","d":1284466465,"b":[["t","I've been playing around with visual studio (2010) trying to build bitcoin from the source that is included in the win32 zip archive. I created a new makefile project and imported the makefile, acquired the boost, wxwidgets, and the openssl sources, and a few other files which were reported missing when I would try to build. I got as far as the build log reporting that it needed iostream.h, so I went and found a copy of that from libstdc++. Now, after trying to build with iostream.h located in my includes directory, I am getting loads of errors that look like this:"],["c","1>------ Build started: Project: bitcoin_test, Configuration: Debug Win32 ------\n1>Build started 9/14/2010 08:07:14.\n1>InitializeBuildStatus:\n1>  Touching \"Debug\\bitcoin_test.unsuccessfulbuild\".\n1>ClCompile:\n1>  util.cpp\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15): error C2143: syntax error : missing ';' before '<'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C2146: syntax error : missing ';' before identifier 'cs_mapAddressBook'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17): error C2143: syntax error : missing ';' before '<'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C2146: syntax error : missing ';' before identifier 'dbenv'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C2143: syntax error : missing ';' before '*'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(34): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C2146: syntax error : missing ';' before identifier 'strFile'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(35): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C2143: syntax error : missing ';' before '<'\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int\n1>c:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(36): error C2238: unexpected token(s) preceding ';'"],["t","This has happened with 2 different versions of iostream.h (tried changing <iostream.h> to <iostream> in db.h also), and if I remove iostream.h from my includes directory it simply reports that file is missing and doesn't give hundreds of lines of errors like the above. I haven't modified any files at all, I am just trying to get the project to build in a windows environment right now...\n\nI am sort of stuck here and haven't been able to figure out what the problem is. Admittedly I don't entirely know what I'm doing (I don't have a whole lot of experience with C++ in windows), but I was wondering if anyone has any ideas what my problem might be."]],"u":"https://bitcointalk.org/index.php?topic=1034.msg12743#msg12743"},{"f":"Gespenster","d":1284490687,"b":[["t","You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source."]],"u":"https://bitcointalk.org/index.php?topic=1034.msg12786#msg12786"},{"f":"nelisky","d":1284492528,"b":[["q","You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source.","Quote from: Gespenster on September 14, 2010, 06:58:07 PM"],["t","There's a makefile.mingw, and although I haven't tried yet, I'll probably take a stab at windows building for my cuda miner. Can I not use this?"]],"u":"https://bitcointalk.org/index.php?topic=1034.msg12791#msg12791"},{"f":"LobsterMan","d":1284691704,"b":[["t","Ok...so trying to build from the commandline with nmake is still giving me the same problems:"],["c","c:\\Users\\[myusername]\\Desktop\\bitcoin-0.3.12\\src>nmake /f makefile.vc\n\nMicrosoft (R) Program Maintenance Utility Version 10.00.30319.01\nCopyright (C) Microsoft Corporation.  All rights reserved.\n\n        cl /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:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(15) : error C2143: syntax error : missing ';' before '<'\nc:\\users\\[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:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(16) : error C2146: syntax error : missing ';' before identifier 'cs_mapAddressBook'\nc:\\users\\[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:\\users\\[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:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(17) : error C2143: syntax error : missing ';' before '<'\nc:\\users\\[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:\\users\\[myusername]\\desktop\\bitcoin-0.3.12\\src\\db.h(23) : error C2146: syntax error : missing ';' before identifier 'dbenv'\nc:\\users\\[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"],["t","Any additional advice would be appreciated...  Undecided\n\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\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=1034.msg13037#msg13037"},{"f":"satoshi","d":1284922006,"b":[["t","The lines it's tripping on:"],["c","ERROR extern map<string, string> mapAddressBook;\nERROR extern CCriticalSection cs_mapAddressBook;\nERROR extern vector<unsigned char> vchDefaultKey;\nOK extern bool fClient;\nOK extern int nBestHeight;\n\nOK extern unsigned int nWalletDBUpdated;\nERROR extern DbEnv dbenv;"],["t","So it's acting like nothing is defined, not even map and vector.\n\nYet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.\n\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?\n\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/\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206","s":1,"n":453,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/453/"}]},{"id":"p220","k":"p","s":"bitcointalk","t":"The case for removing IP transactions","u":"https://bitcointalk.org/index.php?topic=1048","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/220/","m":[{"f":"aceat64","d":1284605863,"b":[["t","Sending transactions to IP addresses should be removed or at least disabled by default.\n\nAs has been stated by many members of the community, it is in no way secure. I also believe that it may actually allow an attacker to determine the identify of an operator of a bitcoin node. Example, I send 0.01 BTC to various IPs on the network and record the IP and bitcoin address (a bitcoin address is autogenerated). If I run or have access to the information at one of the Bitcoin exchanges (or run a store/service that accepts bitcoins) I can then tie that IP address to the user of that site/service. In the case of an exchange I could tie that IP to a person's PayPal or bank account!\n\nAnother possible attack is to connect to a target node and initiate an IP transaction. The target will generate a new address, at which point you disconnect and start again. This might be useful as a denial of service attack."]],"u":"https://bitcointalk.org/index.php?topic=1048.msg12949#msg12949"},{"f":"LZ","d":1284607910,"b":[["t","So may be IP transactions should be enabled only for IP addresses ranges reserved for private networks?\nWhat about forced transaction fees for other IP ranges? (Payee will accept only transactions with fees.)"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg12951#msg12951"},{"f":"nanotube","d":1284608422,"b":[["t","It's not the sending that should be disabled by default, but the receiving, I think.\n\nIf the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.\n\nRight?"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg12954#msg12954"},{"f":"em3rgentOrdr","d":1284608619,"b":[["q","It's not the sending that should be disabled by default, but the receiving, I think.\n\nIf the receiving end refuses to accept IP transactions, unless explicitly enabled, all the problems go away.\n\nRight?","Quote from: nanotube on September 16, 2010, 03:40:22 AM"],["t","Right.  Good point!  Don't throw the baby out with the bathwater!"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg12957#msg12957"},{"f":"aceat64","d":1284662854,"b":[["t","Sorry, I guess I wasn't very clear in the original post. I would like for receiving of transactions by IP to be disabled by default."]],"u":"https://bitcointalk.org/index.php?topic=1048.msg13012#msg13012"},{"f":"LZ","d":1284669839,"b":[["t","Seems that it would increase the security without decreasing the ease of use. So I like it. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg13016#msg13016"},{"f":"aceat64","d":1284672229,"b":[["t","I've created a patch that disables receiving of IP transactions by default. They can be enabled with the \"-allowiptransactions\" option or \"allowiptransactions=true\" in the bitcoin.conf file.\n\nHere's the patch:\nhttp://github.com/aceat64/bitcoin-patchwork/blob/svn/patches/disable_ip_transactions.patch\n\nI've already incorporated the patch into my custom client: http://github.com/aceat64/bitcoin-patchwork"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg13022#msg13022"},{"f":"bitcoinex","d":1284857689,"b":[["t","But do not remove the IP-transactions at all, please!\nhttp://bitcointalk.org/index.php?topic=1042.msg13160"]],"u":"https://bitcointalk.org/index.php?topic=1048.msg13161#msg13161"},{"f":"satoshi","d":1284932970,"b":[["t","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.\n\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.\n\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.\n\nI uploaded this change to SVN rev 156.  The switch to enable is \"-allowreceivebyip\".\n\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\".\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1048.msg13219#msg13219","s":1,"n":455,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/455/"}]},{"id":"p221","k":"p","s":"bitcointalk","t":"Bug?  /usr/bin/bitcoind \"\"","u":"https://bitcointalk.org/index.php?topic=1063","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/221/","m":[{"f":"mizerydearia","d":1284848362,"b":[["t","When I execute"],["c","/usr/bin/bitcoind"],["t","bitcoin daemon starts as expected.\n\nWhen I execute"],["c","/usr/bin/bitcoind \"\""],["t","error: couldn't connect to server\n\nHow come?  Is this a bug?\n\nSatoshi: May we have a bug tracking system please? (size reduced since it was noticed by satoshi and is no longer necessary to stand out, which was meant as a bit humorous anyhow.)\n\nWorkaround for my gentoo linux init script <http://bitcointalk.org/index.php?topic=930.0>:"],["c","BITCOIN_OPTS=\"-min\""],["t","which will then execute as `bitcoind \"-min\"`"]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13140#msg13140"},{"f":"LZ","d":1284850856,"b":[["t","So we have to choose something <https://web.archive.org/web/2010/http://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems>. May be Mantis <https://web.archive.org/web/2010/http://en.wikipedia.org/wiki/Mantis_Bug_Tracker>?"]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13144#msg13144"},{"f":"mizerydearia","d":1284853372,"b":[["t","I sent sourceforge-based message to Satoshi suggesting enabling MantisBT or Trac.  Perhaps he will notice it."]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13151#msg13151"},{"f":"nelisky","d":1284909414,"b":[["q","When I execute\n\n/usr/bin/bitcoind\nbitcoin daemon starts as expected.\n\nWhen I execute\n\n/usr/bin/bitcoind \"\"\nerror: couldn't connect to server\n\nHow come?  Is this a bug?\n\nSatoshi: May we have a bug tracking system please?\n\nWorkaround for my gentoo linux init script <http://bitcointalk.org/index.php?topic=930.0>:\n\nBITCOIN_OPTS=\"-min\"\nwhich will then execute as `bitcoind \"-min\"`","Quote from: mizerydearia on September 18, 2010, 10:19:22 PM"],["t","How is this a bug? I may be reading it completely wrong but:"],["c","/usr/bin/bitcoind"],["t","starts the daemon whereas"],["c","/usr/bin/bitcoind \"\""],["t","calls the rpc method \"\" in the running daemon which is not there, so you get the can't connect. If it were there you'd get:"],["c","error: {\"code\":-32601,\"message\":\"Method not found\"}"]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13197#msg13197"},{"f":"Gavin Andresen","d":1284909597,"b":[["t","I agree with nelisky-- not a bug.  Here's what the unix cat command has to say about \"\":"],["c","> cat \"\"\ncat: : No such file or directory"]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13198#msg13198"},{"f":"satoshi","d":1284926291,"b":[["t","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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1063.msg13211#msg13211","s":1,"n":454,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/454/","qt":["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. We'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. I 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."],"qc":["bitcoin-design"]}]},{"id":"p222","k":"p","s":"bitcointalk","t":"The Niche List","u":"https://bitcointalk.org/index.php?topic=1268","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/222/","m":[{"f":"kiba","d":1285257616,"b":[["t","This is Operation Economic Growth. Our mission is to grow the bitcoin economy by making everyone specialize in a narrow range of good and services.\n\nSimply put, announce what you want to consume and I'll add it to the list. Somebody then will announce that he will try to enter that niche. There can be competition within niches too, but there are other niches to fill.\n\nWe'll hold those people \"accountable\" for their niches by plodding, encouraging, starting a thread and then getting disappointed when the service didn't come online etc.\n\nWanted Niches:\n\n1. craigslist like classified ads for locale.\n\n2. \"Mechanical Turk\"-like site that list simple jobs for people to do. Suggested by noagendamarket in the Stable Exchange Rate? topic of the Economic forum.\n\n3. Beer supply store. Malt, yeasts, hops, etc.\n\n4. Plant store for selling various herbs and stuff.\n\n6. Hacker Academy. Free educational video. Flat tutiion fee classes. Pay as you go for personal tutors.\n\n7. Dating site that accept bitcoins.\n\n8. Easy encryption and backup service.\n\nNiche filled or being worked on:\n\n1. Advertising clearing house like http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house) noagenda offered a large bounty on it and being worked on Biomike.\n\n2. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process. Suggested by Kiba. Taken by Hippich. Eventually sprawned 3 competitors.\n\n3. Freelancer site. Taken by whichspace.\n\n4. Pizza order system. You can order on the web, from the commandline, from your smartphone, sms, etc. Taken by mizerydearia."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828"},{"f":"mskwik","d":1285269256,"b":[["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. Suggested by Kiba.","Quote from: kiba on September 23, 2010, 04:00:16 PM"],["t","That could be an interesting project.  I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing.  Anyone interested in partnering up?"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13855#msg13855"},{"f":"kiba","d":1285272638,"b":[["q","> Quote from: kiba on September 23, 2010, 04:00:16 PM\n> 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. Suggested by Kiba.\n\nThat could be an interesting project.  I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing.  Anyone interested in partnering up?","Quote from: mskwik on September 23, 2010, 07:14:16 PM"],["t","There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.\n\nActually, I  didn't suggested it originally, but somebody else did in the thread about p0rn."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13869#msg13869"},{"f":"mskwik","d":1285282250,"b":[["q","There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.","Quote from: kiba on September 23, 2010, 08:10:38 PM"],["t","That is very true, it is something that I could start development on by myself but the actual development won't really take all that long even just working on it in spare time.  The longer term job on the technical side will be keeping the central server running well and scaling up as needed.  On the other side in the beginning the marketing would be getting stuff to download (as you said) and yes an affiliate program of some sort could help there.  In the longer term there the issue is going to be providing help/support which is the big part I'm not really ready to take on.  I'm already on-call basically 24/7 for my main site, doing sysadmin stuff for another project (that would likely share the same infrastructure at least to start with) won't be a big deal but I'm well aware of how important good customer service is and don't want to jump into something that I'm not prepared to do a good job at.\n\nMain reasons for finding a partner upfront would be 1) that they have some input in the design process (if you want to market to a content distributor that they can theme this download page to match their site then I want to know about that as soon as possible) and 2) so that they are familiar with how it is supposed to work from the beginning and can give feedback if it's not as userfriendly as they want or such.  Neither of these is a necessity, I can code it and get a small site going regardless but I am a programmer by trade and know my limitations and something like this will need more than some fancy code to be more than just a small site.\n\nI've been considering some ideas already and am thinking I will put something together regardless, I guess this is more of an invitation for someone else who would be interested in running this sort of thing but may not have the technical skills to do it themselves to join me."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13885#msg13885"},{"f":"mskwik","d":1285283329,"b":[["t","And on a separate note I think another niche that could use filling would be an advertising clearinghouse.  I've seen a couple sites that say they will accept BTC payments for ad space but a central place to do it would be nice to have.  I've been using http://www.projectwonderful.com/ on other sites and like the way they work, something like that would seem that it could work well with bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13887#msg13887"},{"f":"kiba","d":1285286227,"b":[["q","> Quote from: kiba on September 23, 2010, 08:10:38 PM\n> There will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.\n\nThat is very true, it is something that I could start development on by myself but the actual development won't really take all that long even just working on it in spare time.  The longer term job on the technical side will be keeping the central server running well and scaling up as needed.  On the other side in the beginning the marketing would be getting stuff to download (as you said) and yes an affiliate program of some sort could help there.  In the longer term there the issue is going to be providing help/support which is the big part I'm not really ready to take on.  I'm already on-call basically 24/7 for my main site, doing sysadmin stuff for another project (that would likely share the same infrastructure at least to start with) won't be a big deal but I'm well aware of how important good customer service is and don't want to jump into something that I'm not prepared to do a good job at.\n\nMain reasons for finding a partner upfront would be 1) that they have some input in the design process (if you want to market to a content distributor that they can theme this download page to match their site then I want to know about that as soon as possible) and 2) so that they are familiar with how it is supposed to work from the beginning and can give feedback if it's not as userfriendly as they want or such.  Neither of these is a necessity, I can code it and get a small site going regardless but I am a programmer by trade and know my limitations and something like this will need more than some fancy code to be more than just a small site.\n\nI've been considering some ideas already and am thinking I will put something together regardless, I guess this is more of an invitation for someone else who would be interested in running this sort of thing but may not have the technical skills to do it themselves to join me.","Quote from: mskwik on September 23, 2010, 10:50:50 PM"],["t","I would think a markeeter these days need programming skills and statistics to analyze mass amount of data, doing A/B testing, etc. Although most of the work will be done within a week, I think you'll find that streamlining the download process, doing testing of different version of the site, will be a big part of your job. Let face it, there are many frustration in finding and downloading contents."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13893#msg13893"},{"f":"FreeMoney","d":1285303341,"b":[["t","Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.\n\nI don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13910#msg13910"},{"f":"kiba","d":1285303491,"b":[["q","Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.\n\nI don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?","Quote from: FreeMoney on September 24, 2010, 04:42:21 AM"],["t","Not sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13911#msg13911"},{"f":"FreeMoney","d":1285304562,"b":[["q","> Quote from: FreeMoney on September 24, 2010, 04:42:21 AM\n> Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.\n>\n> I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?\n\nNot sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend.","Quote from: kiba on September 24, 2010, 04:44:51 AM"],["t","There are 'sweatshops' in India(?), China(?) that have people solving captchas and selling them in bulk to hackers(?). I'm just remembering a bit of an article I read a while back.\n\nI was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13912#msg13912"},{"f":"kiba","d":1285304869,"b":[["q","I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.","Quote from: FreeMoney on September 24, 2010, 05:02:42 AM"],["t","What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n\nNobody have volunteer yet for any of those niches, which I think in theory can be done in a few weeks time.(my niche is writing the software for bitpredict)"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13914#msg13914"},{"f":"Babylon","d":1285305138,"b":[["q","> Quote from: kiba on September 24, 2010, 04:44:51 AM\n> > Quote from: FreeMoney on September 24, 2010, 04:42:21 AM\n> > Does anyone know about the captcha solving business? Seems you could play .02BTC or something and resell them bulk slightly higher. I've heard $2-3/1000. If people would do them at .02 you would be turning 20BTC into $2.\n> >\n> > I don't know the details though. Who buys them? Do they want particular ones solved on demand or is a solved batch good for something?\n>\n> Not sure what you are talking about. I thought of bitcoin as a captcha itself. The theory goes that bitcoin are valuable stuff that spammers are reluctant to spend.\n\nThere are 'sweatshops' in India(?), China(?) that have people solving captchas and selling them in bulk to hackers(?). I'm just remembering a bit of an article I read a while back.\n\nI was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.","Quote from: FreeMoney on September 24, 2010, 05:02:42 AM"],["t","spammers, not hackers."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13916#msg13916"},{"f":"FreeMoney","d":1285305323,"b":[["q","> Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\nWhat possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?","Quote from: kiba on September 24, 2010, 05:07:49 AM"],["t","I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n\nI don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n\nJust a niche I thought of, prolly a bad one."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13917#msg13917"},{"f":"kiba","d":1285305457,"b":[["q","> Quote from: kiba on September 24, 2010, 05:07:49 AM\n> > Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> > I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\n> What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n\nI dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n\nI don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n\nJust a niche I thought of, prolly a bad one.","Quote from: FreeMoney on September 24, 2010, 05:15:23 AM"],["t","Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13918#msg13918"},{"f":"Babylon","d":1285306765,"b":[["q","> Quote from: FreeMoney on September 24, 2010, 05:15:23 AM\n> > Quote from: kiba on September 24, 2010, 05:07:49 AM\n> > > Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> > > I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\n> > What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n>\n> I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n>\n> I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n>\n> Just a niche I thought of, prolly a bad one.\n\nJust pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.","Quote from: kiba on September 24, 2010, 05:17:37 AM"],["t","That works as an e-mail tax.  Doesn't work so well in the case of captchas, which are usually for registration on a site.  .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13919#msg13919"},{"f":"kiba","d":1285308379,"b":[["q","> Quote from: kiba on September 24, 2010, 05:17:37 AM\n> > Quote from: FreeMoney on September 24, 2010, 05:15:23 AM\n> > > Quote from: kiba on September 24, 2010, 05:07:49 AM\n> > > > Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> > > > I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\n> > > What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n> >\n> > I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n> >\n> > I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n> >\n> > Just a niche I thought of, prolly a bad one.\n>\n> Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.\n\nThat works as an e-mail tax.  Doesn't work so well in the case of captchas, which are usually for registration on a site.  .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.","Quote from: Babylon on September 24, 2010, 05:39:25 AM"],["t",".5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.\n\nWell, of course, you can adjust the price of posting a little bit. "]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13921#msg13921"},{"f":"Babylon","d":1285308910,"b":[["q","> Quote from: Babylon on September 24, 2010, 05:39:25 AM\n> > Quote from: kiba on September 24, 2010, 05:17:37 AM\n> > > Quote from: FreeMoney on September 24, 2010, 05:15:23 AM\n> > > > Quote from: kiba on September 24, 2010, 05:07:49 AM\n> > > > > Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> > > > > I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\n> > > > What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n> > >\n> > > I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n> > >\n> > > I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n> > >\n> > > Just a niche I thought of, prolly a bad one.\n> >\n> > Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.\n>\n> That works as an e-mail tax.  Doesn't work so well in the case of captchas, which are usually for registration on a site.  .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.\n\n.5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.\n\nWell, of course, you can adjust the price of posting a little bit.","Quote from: kiba on September 24, 2010, 06:06:19 AM"],["t","A spammer doesn't need to register millions of times though, just once per site.  Then he just sends millions of messages."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13922#msg13922"},{"f":"kiba","d":1285309246,"b":[["q","> Quote from: kiba on September 24, 2010, 06:06:19 AM\n> > Quote from: Babylon on September 24, 2010, 05:39:25 AM\n> > > Quote from: kiba on September 24, 2010, 05:17:37 AM\n> > > > Quote from: FreeMoney on September 24, 2010, 05:15:23 AM\n> > > > > Quote from: kiba on September 24, 2010, 05:07:49 AM\n> > > > > > Quote from: FreeMoney on September 24, 2010, 05:02:42 AM\n> > > > > > I was thinking that it might make sense to decentralize the sweatshop to reduce overhead and make the micropayments to workers with bitcoin.\n> > > > > What possible legit captcha breaking activities would there be? What uses would it be to other bitcoin users, and what possible benefit would there be for the community?\n> > > >\n> > > > I dunno man, making 4000 gmail accounts to forward that email that makes Bill Gates give 1000 rainbows to dieing children?\n> > > >\n> > > > I don't know legit uses, but I hate solving them, especially that IRC one and I'd pay .5BTC if I could click and make it solved.\n> > > >\n> > > > Just a niche I thought of, prolly a bad one.\n> > >\n> > > Just pay .5BTC that prove you are human. If you can make spammers pay for everything they spam, you have done well.\n> >\n> > That works as an e-mail tax.  Doesn't work so well in the case of captchas, which are usually for registration on a site.  .5 is not enough to discourage a spammer form registering and too much to attach as a charge for every post.\n>\n> .5 * 1000 is 500 bitcoin. .5 * 10000 or so is 5,000 bitcoin. .5 * 100000 is 50,000 bitcoin. Imagine if the spammer want to register million of time across sites. The cost will run up very quick.\n>\n> Well, of course, you can adjust the price of posting a little bit.\n\nA spammer doesn't need to register millions of times though, just once per site.  Then he just sends millions of messages.","Quote from: Babylon on September 24, 2010, 06:15:10 AM"],["t","I think spammers' scale tend to be bigger than that. Anyway, it is distracting from the purpose of the thread, although it is important to discuss the viability unless someone decided to try it anyway."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13923#msg13923"},{"f":"kiba","d":1285377181,"b":[["t","So nobody is taking up some niches?  Cry"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg13997#msg13997"},{"f":"Anonymous","d":1285386132,"b":[["q","So nobody is taking up some niches?  Cry","Quote from: kiba on September 25, 2010, 01:13:01 AM"],["t","They probably  are they just dont want to post about it.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14000#msg14000"},{"f":"QuantumMechanic","d":1285388084,"b":[["t","I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting.  I would help, but I'm just learning how to program."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14002#msg14002"},{"f":"kiba","d":1285390606,"b":[["q","I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting.  I would help, but I'm just learning how to program.","Quote from: dejayl on September 25, 2010, 04:14:44 AM"],["t","Is this just a payment option added to an existing service or is it actually a new service?"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14004#msg14004"},{"f":"Anonymous","d":1285502729,"b":[["q","2. Advertising clearing house like http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)","Quote"],["t","We are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker. "]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14112#msg14112"},{"f":"kiba","d":1285505684,"b":[["q","> Quote\n> 2. Advertising clearing house like http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)\n\nWe are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker.","Quote from: Anonymous on September 26, 2010, 12:05:29 PM"],["t","Moved #2 to niches being worked upon."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14114#msg14114"},{"f":"thrashaholic","d":1285546802,"b":[["q","> Quote from: mskwik on September 23, 2010, 07:14:16 PM\n> > Quote from: kiba on September 23, 2010, 04:00:16 PM\n> > 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. Suggested by Kiba.\n>\n> That could be an interesting project.  I'd be willing to work on the technical side but not sure I really have time to do proper support/marketing.  Anyone interested in partnering up?\nThere will be nothing to market if there aren't anything to market. I suspect it required maybe only a week of development if you're competent. Other than that, it's about gaining critical mass of stuff to download before explosion, I suspect. Marketing can be something like gathering desirable and not illegal stuff to download, curating it, etc and than giving the link to people who want it. That can be done in your spare downtime until you find marketer worth his salt of set up an affiliate program that incentivized people to market for you.\n\nActually, I  didn't suggested it originally, but somebody else did in the thread about p0rn.","Quote from: kiba on September 23, 2010, 08:10:38 PM"],["t","( Those who are fans of IP enforcement should just skip this part. Just sayin'. )\n\nThat was me, and I was specifically talking about targeting the less than legal area of file sharing.\n\nPut simply, you're just not going to find legal content that will be effective in that market. Anything like OSS is mirrored for free and people aren't going to pay to download. Content owners aren't game - it'd be just another CDN to them, why would they pay in bitcoin, and why would their users pay per download/MB/GB when they're already paying for the content? That niche is solely about pirated content - like it or not.\n\nMarketing would take hardly any effort, as I'm sure (with a good enough user pay flow) we could offer higher conversion rates and payouts for affiliates than the other shady CC required websites. It would take time to work out a business plan, but the actual development would take no time at all. (I could do it in a couple of days with a full-time effort) The files themselves could be shoved onto S3 or something. Just have to have someone handy with numbers to make sure it's profitable - otherwise nobody's going to waste their time.\n\nSomething like x amount of BTC per GB or MB (instead of a monthly membership), with an affiliate system would take over that market. Lots of people are willing to pay for better access to niche pirated content, but are reluctant to offer up CC and personal info directly for obvious reasons.\n\nI also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.\n\nAgorist developers apply within.  Grin"],["q","> Quote from: Anonymous on September 26, 2010, 12:05:29 PM\n> > Quote\n> > 2. Advertising clearing house like http://projectwonderful.com. Suggested by mskwik.(I used projectwonderful to make tiny bit of money. I wonder if I can get more money from a bitcoin advertising clearing house)\n>\n> We are working on a bitcoin business directory so an advertising clearance house would be a natural fit with this. There is one developer working on the directory at the moment so another drupal developer or two to help us out would get it done a lot quicker.\n\nMoved #2 to niches being worked upon.","Quote from: kiba on September 26, 2010, 12:54:44 PM"],["t","Ugh, Drupal. ::wilhelmscream:: I'd be willing to develop an advertising clearance house - I actually have a lot of industry experience there."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14176#msg14176"},{"f":"theymos","d":1285550085,"b":[["q","I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.","Quote from: thrashaholic on September 27, 2010, 12:20:02 AM"],["t","Bitcoin can't prove that someone is human, but requiring a very small payment for each \"dangerous\" action is perfect for preventing abuse."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14183#msg14183"},{"f":"QuantumMechanic","d":1285552132,"b":[["q","> Quote from: dejayl on September 25, 2010, 04:14:44 AM\n> I'd like to see Bitcoin payments implemented into Tahoe-LAFS (distributed online storage), like Zooko was on here suggesting.  I would help, but I'm just learning how to program.\n\nIs this just a payment option added to an existing service or is it actually a new service?","Quote from: kiba on September 25, 2010, 04:56:46 AM"],["t","The service exists, although the necessary accounting scheme has not been developed yet."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14186#msg14186"},{"f":"thrashaholic","d":1285650975,"b":[["q","> Quote from: thrashaholic on September 27, 2010, 12:20:02 AM\n> I also don't see how bitcoin could be used as a captcha, those are used to make sure there's a human on the other end and not a spam bot...you could easily automate the payments. For this niche, it's paying for high bandwidth, concurrent downloads of pirated content; it just won't work otherwise IMO.\n\nBitcoin can't prove that someone is human, but requiring a very small payment for each \"dangerous\" action is perfect for preventing abuse.","Quote from: theymos on September 27, 2010, 01:14:45 AM"],["t","For spammers that make thousands upon thousands of dollars a year? The payments would have to be higher than the potential profits of the spam and it would likely push it out of reach of the average consumer. I'm not going to pay $0.50 to post a blog comment, ever. A big spammer could do that a thousand times and still not cut into their bottom line. I think the fact that spammers use Mechanical Turk to break captchas already is the proof in the pudding."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14363#msg14363"},{"f":"kiba","d":1285965588,"b":[["t","Any more services and goods you want to see fulfilled? Is anybody working on any of the wanted niches?"]],"u":"https://bitcointalk.org/index.php?topic=1268.msg14902#msg14902"},{"f":"satoshi","d":1286406631,"b":[["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.","Quote from: kiba on September 23, 2010, 04:00:16 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741","s":1,"n":489,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/489/"}]},{"id":"p223","k":"p","s":"bitcointalk","t":"Internal version number","u":"https://bitcointalk.org/index.php?topic=1269","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/223/","m":[{"f":"satoshi","d":1285258748,"b":[["t","In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5.  The last number represents changes on the SVN between releases and ought to be properly represented in the version number.  Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around."]],"u":"https://bitcointalk.org/index.php?topic=1269.msg13831#msg13831","s":1,"n":458,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/458/"},{"f":"nelisky","d":1285260484,"b":[["q","In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5.  The last number represents changes on the SVN between releases and ought to be properly represented in the version number.  Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.","Quote from: satoshi on September 23, 2010, 04:19:08 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1269.msg13835#msg13835"},{"f":"satoshi","d":1285267580,"b":[["t","I don't think it should cause any problems for version comparisons.  31300 > 312."]],"u":"https://bitcointalk.org/index.php?topic=1269.msg13849#msg13849","s":1,"n":462,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/462/"}]},{"id":"p224","k":"p","s":"bitcointalk","t":"How divisible are bitcoins - the technical side","u":"https://bitcointalk.org/index.php?topic=1271","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/224/","m":[{"f":"nelisky","d":1285263335,"b":[["t","Hey,\n\nSo there is another thread asking about bc and decimal places. It is stated that the client(s) only show 2 decimal places, but there are 8 in total. Now, working on stuff, I find that it would be nice if I could transfer at least 4 decimals precision, but the full 8 would be great.\n\nLooking at the code it seems simple enough to remove the rounding from bitcoind, but what about the receiving side? If it's a non UI client, then it will show everything, but would I be making things overly confusing for GUI clients?\n\nIs there any shortcoming in me patching my client to handle full precision?"]],"u":"https://bitcointalk.org/index.php?topic=1271.msg13839#msg13839"},{"f":"FreeMoney","d":1285264887,"b":[["t","Won't transaction fees make that pointless?\n\nIf you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all. "]],"u":"https://bitcointalk.org/index.php?topic=1271.msg13845#msg13845"},{"f":"nelisky","d":1285265435,"b":[["q","Won't transaction fees make that pointless?\n\nIf you are trying to give accurate payouts from the sportsbook I don't think anyone will mind having it rounded off at .01 for now. That is only $0.0006 after all.","Quote from: FreeMoney on September 23, 2010, 06:01:27 PM"],["t","Will transaction fees be applied to transfers above 0.01, but with more precision? I wasn't aware of it being that way.\n\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.\n\nAnd no, it's not *only* for the sportsbook. I have plans... Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1271.msg13847#msg13847"},{"f":"satoshi","d":1285267196,"b":[["t","I would not encourage using the extra decimal places.  They're only intended for future use.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1271.msg13848#msg13848","s":1,"n":461,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/461/"}]},{"id":"p225","k":"p","s":"bitcointalk","t":"How To Make a Distributed BitCoin Escrow Service","u":"https://bitcointalk.org/index.php?topic=1283","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/225/","m":[{"f":"harding","d":1285463778,"b":[["t","Summary: Giving BitCoin a decentralized escrow would give it an advantage over all other exchange mediums, which might increase its adoption rate.  Details follow.\n\nFor a decentralized currency, centralized escrows seem to be the norm for BitCoin today.  An example:\n\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.\n\nNo offense to Mt. Gox (a site I like), but can we do without its escrow service?\n\nAn almost distributed alternative:\n\n• Charlie, a trusted third-party, generates a BitCoin private key.\n\n• Charlie then uses the Unix command split to split the private key in half--giving one half to Alice and one half to Bob.\n\n• Bob deposits $5 USD worth of BitCoins into the split BitCoin account;\n\n• Alice verifies the transaction using the public block;\n\n• Alice sends $5 USD to Bob by PayPal;\n\n• Bob verifies the PayPal transaction;\n\n• Bob sends Alice his half of the split private key so Alice can access the BitCoins he deposited earlier.\n\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.)\n\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.\n\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.\n\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.\n\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\n-Dave\n\n[1] See: http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing"]],"u":"https://bitcointalk.org/index.php?topic=1283.msg14070#msg14070"},{"f":"satoshi","d":1285522466,"b":[["t","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\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1283.msg14136#msg14136","s":1,"n":463,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/463/"}]},{"id":"p226","k":"p","s":"bitcointalk","t":"Remote RPC access","u":"https://bitcointalk.org/index.php?topic=1291","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/226/","m":[{"f":"Marko","d":1285606225,"b":[["t","Hello,\n\nI'm have a client that calls getinfo over the rpc interface. Everything works fine when host=localhost.\nHowever, when trying to get bitcoin at another host i cannot.\nI read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?\n\nIf not, i'm probably going to have to write a 'proxy' app that i would deploy to each machine running bitcoin. Would prefer not to do this Sad\n\nThanks,\nMarko"]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14263#msg14263"},{"f":"doublec","d":1285635082,"b":[["q","I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?","Quote from: Marko on September 27, 2010, 04:50:25 PM"],["t","This is still the case and I don't believe there is a setting to override it. It's hardcoded in the source. Instead of writing a 'proxy' app you can use SSH to tunnel. For example, if your bitcoin instance is running on 'example.com' and that machine is running an ssh server, you can tunnel to it from another machine with:\n\nssh -N example.com -L  9481:localhost:9481\n\nNow you can use the RPC interface on your local machine to port 9481 and it will be tunnelled over an encrypted SSH session to the machine running the bitcoin RPC server.\n\nYou want to encrypt the connection because the JSON-RPC password is sent in clear text (it's actually base 64 encoded but basically it's the equivalent of clear text)."]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14352#msg14352"},{"f":"nelisky","d":1285635329,"b":[["q","> Quote from: Marko on September 27, 2010, 04:50:25 PM\n> I read the wiki and it says the interface only accepts requests from 127.0.0.1. Is this still the case? Is there a setting to override this?\n\nThis is still the case and I don't believe there is a setting to override it. It's hardcoded in the source. Instead of writing a 'proxy' app you can use SSH to tunnel. For example, if your bitcoin instance is running on 'example.com' and that machine is running an ssh server, you can tunnel to it from another machine with:\n\nssh -N example.com -L  9481:localhost:9481\n\nNow you can use the RPC interface on your local machine to port 9481 and it will be tunnelled over an encrypted SSH session to the machine running the bitcoin RPC server.\n\nYou want to encrypt the connection because the JSON-RPC password is sent in clear text (it's actually base 64 encoded but basically it's the equivalent of clear text).","Quote from: doublec on September 28, 2010, 12:51:22 AM"],["t","Can you compile your own bitcoin? The latest svn has an option to allow binding to other interfaces, not just localhost. If not the next version (0.3.13) is supposed to have that."]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14353#msg14353"},{"f":"theymos","d":1285635534,"b":[["t","There's an \"-rpcallowip=\" switch in SVN, which allows you to access RPC from the specified IP addresses. This is not safe from MITM attacks, however."]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14355#msg14355"},{"f":"Marko","d":1285682331,"b":[["t","Hey all...Thanks for all the feedback\n\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...\n\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?\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14395#msg14395"},{"f":"satoshi","d":1285871261,"b":[["t","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.\n\n0.3.13 RC1 is available for Windows:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe"]],"u":"https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736","s":1,"n":470,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/470/"}]},{"id":"p227","k":"p","s":"bitcointalk","t":"I broke my wallet, sends never confirm now.","u":"https://bitcointalk.org/index.php?topic=1306","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/227/","m":[{"f":"kermit","d":1285758357,"b":[["t","Nothing I send gets confirmed now. \n\nHere's how I did it:\n\nI was sending out payments under .01 in size and not paying a transaction fee, which of course were never confirmed.\n\nHere's a guess as to why it broke my wallet:\n\nBecause the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out.\n\nI've only lost 100btc, so I'm not real worried, but if you know how to fix it without too much trouble, that'd be nice."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14506#msg14506"},{"f":"Tritonio","d":1285763277,"b":[["t","You could edit your client to make it include into blocks any transactions without looking at the fee. And then wait a month or so until you make a block which will include your transactions... Or wait until someone else with a custom client includes your transactions in his block."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14515#msg14515"},{"f":"theymos","d":1285763912,"b":[["q","Because the change leftover was also then never confirmed, yet my client treats it as if it was so includes those amounts in the amounts it sends out.","Quote from: kermit"],["t","This seems likely. Try sending a ton of 0.01 transactions -- most of these transactions will work if this is the case."],["q","Or wait until someone else with a custom client includes your transactions in his block.","Quote from: Tritonio on September 29, 2010, 12:27:57 PM"],["t","For this you'll want to use the -maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor.\n\nYou could also \"double-spend\" your pre-experiment coins by acting as though the unconfirmed transactions never happened. A wallet backup would roll things back, for example."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14517#msg14517"},{"f":"Tritonio","d":1285764024,"b":[["q","For this you'll want to use the -maxconnections switch with a high number of connections, because propagation of your invalid transaction will be very poor.","Quote from: theymos on September 29, 2010, 12:38:32 PM"],["t","Huh? Clients don't propagate what they consider invalid? I thought that they just didn't include it in their blocks..."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14518#msg14518"},{"f":"theymos","d":1285764412,"b":[["q","Huh? Clients don't propagate what they consider invalid? I thought that they just didn't include it in their blocks...","Quote from: Tritonio on September 29, 2010, 12:40:24 PM"],["t","Hmm; I'm not sure about this case. They're not working on your new transaction because the previous transaction wasn't in a previous block and isn't in their memory pool. I don't know if they'd relay it."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14519#msg14519"},{"f":"nanotube","d":1285767752,"b":[["t","Hey, so i've been the recipient of a few of these microtransactions\nso now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state\n\nso the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?\n\nnote also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?"]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14524#msg14524"},{"f":"Tritonio","d":1285768275,"b":[["q","Hey, so i've been the recipient of a few of these microtransactions\nso now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state","Quote from: nanotube on September 29, 2010, 01:42:32 PM"],["t","They will get confirmed when someone that doesn't require fees include them in his/her block."],["q","so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?","Quote from: nanotube on September 29, 2010, 01:42:32 PM"],["t","There is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins."],["q","note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?","Quote from: nanotube on September 29, 2010, 01:42:32 PM"],["t","You can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14525#msg14525"},{"f":"kermit","d":1285770885,"b":[["t","it seems this could take down the whole network depending on the logic behind combining lots.. as in if the micropayment without fee is combined with a normal transaction and has change, both the send and the change would never confirm either.  so now you have 2 lots that will never confirm.  repeat.\n\nand it does seem the client lets you spend unconfirmed coin."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14529#msg14529"},{"f":"nanotube","d":1285774070,"b":[["q","> Quote from: nanotube on September 29, 2010, 01:42:32 PM\n> Hey, so i've been the recipient of a few of these microtransactions\n> so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state\nThey will get confirmed when someone that doesn't require fees include them in his/her block.","Quote from: Tritonio on September 29, 2010, 01:51:15 PM"],["t","yes and.... at this point /all/ clients require fees for transactions <0.01, do you have any reason to expect that this will change at any point in the future? i don't. so \"never will get confirmed\" seems a reasonable approximation to reality."],["q","> Quote from: nanotube on September 29, 2010, 01:42:32 PM\n> so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?\nThere is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins.","Quote"],["t","yes but the problem is that the client doesn't let the user choose which coins to spend, it does it all \"automagically\" behind the scenes. so how would a user know if he's sending confirmed coins or unconfirmed coins?"],["q","> Quote from: nanotube on September 29, 2010, 01:42:32 PM\n> note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?\nYou can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions.","Quote"],["t","yes, but that's a separate issue. i'm really trying to figure out what, if anything, to be doing about the handful of never-to-be-confirmed transactions i have in my wallet, whether the client will prioritize sending other coins first or not, and if not... that means it's possible that i'll never be able to make a send transaction that will be confirmed, because the unconfirmed bits of coin will be included. which would in turn mean that my whole wallet is foobar."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14544#msg14544"},{"f":"theymos","d":1285775764,"b":[["t","I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool."],["q","I don't know if there is any protection in the protocol from this kind of attacks","Quote from: Tritonio"],["t","There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14552#msg14552"},{"f":"wscott","d":1285779281,"b":[["t","And in the future node could certainly drop connections from nodes that generate bad transactions."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14567#msg14567"},{"f":"nanotube","d":1285782949,"b":[["q","I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool.\n\n> Quote from: Tritonio\n> I don't know if there is any protection in the protocol from this kind of attacks\n\nThere is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in.","Quote from: theymos on September 29, 2010, 03:56:04 PM"],["t","theymos: well... the problem is that it causes problems for the wallets that happen to have received those transactions. my wallet now includes a bunch of small transactions that will never be confirmed (due to their not having paid the requisite fees).\n\nsince the client does not let the user control which coins to send, any transaction i send out in the future is liable to try to include those coins in the outgoing payment, which, in turn, will never get confirmed, thus borking my whole wallet.\n\nso say a 'rogue' client harvests a bunch of addresses of the net (these forums are a good and ripe place), and starts sending out a bunch of .000001 payments with no fee. now these wallets will all be contaminated with these never-to-be-confirmed payments, and since the client doesn't allow one to choose which coins get sent, they may be included in future outgoing payments, which will also never get confirmed.\n\nso what should i do to 'clear' my wallet? i'd need some custom tool to be able to send /specific coins/, so that i can send them all to another wallet and drop the contaminated one.\n\nand more importantly, for the future - how do we address this problem? "]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14583#msg14583"},{"f":"theymos","d":1285784927,"b":[["t","At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this:"],["c","if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)"],["t","Your client will then no longer consider coins with 0 confirmations when choosing coins."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14592#msg14592"},{"f":"jgarzik","d":1285785476,"b":[["q","At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this:\n\nif (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)\n\nYour client will then no longer consider coins with 0 confirmations when choosing coins.","Quote from: theymos on September 29, 2010, 06:28:47 PM"],["t","IMO, this should make it into the upstream bitcoin client, as either\n\n• a command line switch, requiring confirmation for all sent coins\n\n• a two-pass search:  search first for confirmed coins.  if not enough confirmed coins are available, use unconfirmed coins."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14595#msg14595"},{"f":"theymos","d":1285786041,"b":[["t","The best option might be four passes at 120, 6, 1, and 0, to somewhat prioritize based on depth."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14596#msg14596"},{"f":"Tritonio","d":1285786253,"b":[["q","and more importantly, for the future - how do we address this problem?","Quote from: nanotube on September 29, 2010, 05:55:49 PM"],["t","I really don't care about extremelly fast transactions. It would be enough for me if Bitcoin didn't even show unconfirmed transactions and didn't even try to spend them before they get confirmed. FFS just wait 10minutes for a block to appear confirming them.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14598#msg14598"},{"f":"nanotube","d":1285787603,"b":[["q","At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this:\n\nif (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1)\n\nYour client will then no longer consider coins with 0 confirmations when choosing coins.","Quote from: theymos on September 29, 2010, 06:28:47 PM"],["t","thanks theymos for the patch!\n\ni guess now i have to figure out how to build bitcoind.... Smiley\n\nor maybe i'll just wait around for this to make it into the next official release...\nif satoshi agrees with jgarzik as far as including those options in mainline, maybe i don't have to wait that long..."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14603#msg14603"},{"f":"kermit","d":1285789637,"b":[["t","Some people might want to add the\n\npcoin->GetDepthInMainChain() < 1\n\nin GetBalance() too."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14611#msg14611"},{"f":"jgarzik","d":1285790327,"b":[["q","Some people might want to add the\n\npcoin->GetDepthInMainChain() < 1\n\nin GetBalance() too.","Quote from: kermit on September 29, 2010, 07:47:17 PM"],["t","Well, I would rather split \"balance\" in two:  confirmed and unconfirmed balances."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14615#msg14615"},{"f":"nanotube","d":1285793913,"b":[["t","ok, so i built a modified bitcoind, with the addition of 'pcoin->GetDepthInMainChain() < 1' to both SelectCoins and GetBalance.\n\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.\n\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....)\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14621#msg14621"},{"f":"satoshi","d":1285864733,"b":[["t","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.\n\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.\n\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.\n\nThe JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.\n\nI uploaded the changes to SVN rev 158.  I will post a 0.3.13 RC shortly.\n\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.\n\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.\n\nchange:\n    if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)\n        continue;\nto:\n    if (pcoin->GetDepthInMainChain() < 1)\n        continue;"]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714","s":1,"n":464,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/464/","qt":["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."],"qc":["transactions"]},{"f":"satoshi","d":1285865940,"b":[["t","0.3.13 release candidate, please test:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe"]],"u":"https://bitcointalk.org/index.php?topic=1306.msg14720#msg14720","s":1,"n":465,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/465/"},{"f":"kermit","d":1286029060,"b":[["t","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?"]],"u":"https://bitcointalk.org/index.php?topic=1306.msg15001#msg15001"},{"f":"satoshi","d":1286384063,"b":[["t","That's going to be more of a SelectCoins thing.\n\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.\n\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.\n\nHere's a Windows build:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672","s":1,"n":487,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/487/"}]},{"id":"p228","k":"p","s":"bitcointalk","t":"Prioritized transactions, and tx fees","u":"https://bitcointalk.org/index.php?topic=1314","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/228/","m":[{"f":"jgarzik","d":1285791210,"b":[["t","As noted in this wiki page <http://www.bitcoin.org/wiki/doku.php?id=transaction_fee> and in this satoshi post <http://bitcointalk.org/index.php?topic=795.msg8960#msg8960>, the -paytxfee switch may be employed give your sent transactions \"priority.\"\n\nPrioritized transactions appear to be defined as increasing the likelihood that a transaction will be included in a block, even if that block is very large (byte-wise or tx-wise).\n\nConsidering that 99.9% of blocks are outside the range that will incur tx fees, it can be said that tx fees are largely useless today.  But it makes me curious...\n\nAre there any other areas of the bitcoin client or network that could somehow prioritize transactions based on tx fees?  Examples:\n\n• if you have a list of transactions to send out to the network, send prioritized ones to more connected nodes\n\n• restart mining work immediately if priority tx arrives, but continue working on existing block for a while, if free tx arrives\n\nAnd with my businessman's cap on, I would think it prudent practice for any bitcoin business to use -paytxfee=0.02 by default, just to be safe, guaranteeing priority on the existing network and existing clients, in cases of extreme network load.\n\nOther comments about how to use tx fees welcome...  I strongly believe that a healthy tx fee structure is important to the long term health of the bitcoin P2P network."]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14616#msg14616"},{"f":"theymos","d":1285794676,"b":[["t","As far as I can tell, transactions are not prioritized according to fee size. Paytxfee just ensures that you will meet the fee requirements (and it isn't guaranteed to do that). This does seem to be contrary to what Satoshi and sirius-m have implied, but I can't find any prioritization in the code."]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14624#msg14624"},{"f":"wscott","d":1285839621,"b":[["t","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\n-Wayne"]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14683#msg14683"},{"f":"satoshi","d":1285870316,"b":[["t","It ramps up the fee requirement as the block fills up:\n\n<50KB  free\n50KB   0.01\n250KB  0.02\n333KB  0.03\n375KB  0.04\netc.\n\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.\n\nJust including the minimum 0.01 goes a long way."]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732","s":1,"n":468,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/468/"},{"f":"theymos","d":1285870596,"b":[["t","That's cost per kilobyte, though, and a kilobyte can only hold ~9 TxIns, so 0.01 is not guaranteed to meet the requirement."]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14733#msg14733"},{"f":"satoshi","d":1285870942,"b":[["t","True, the switch should be something more dynamic that pays per KB.  It's harder to think of how to explain it."]],"u":"https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734","s":1,"n":469,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/469/"}]},{"id":"p229","k":"p","s":"bitcointalk","t":"0.3.13 RC1 for Windows, please test","u":"https://bitcointalk.org/index.php?topic=1322","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/229/","m":[{"f":"satoshi","d":1285866255,"b":[["t","0.3.13 release candidate, to be released soon so please test:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe\n\n- don't count or spend payments until they have 1 confirmation\n     http://bitcointalk.org/index.php?topic=1306.0\n- internal version number from 312 to 31300\n- only accept transactions sent by IP address if -allowreceivebyip is specified\n- dropped DB_PRIVATE Berkeley DB flag\n- fix problem sending the last cent with sub-cent fractional change\n- auto-detect whether to use 128-bit 4-way SSE2 on Linux\nGavin Andresen:\n- option -rpcallowip= to accept json-rpc connections from another machine\n- clean shutdown on SIGTERM on Linux"]],"u":"https://bitcointalk.org/index.php?topic=1322.msg14722#msg14722","s":1,"n":466,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/466/"},{"f":"LZ","d":1285889076,"b":[["t","What about to add Russian localization <https://bitcointalk.org/index.php?topic=151.msg14675#msg14675> to 0.3.13?"]],"u":"https://bitcointalk.org/index.php?topic=1322.msg14782#msg14782"},{"f":"satoshi","d":1285893166,"b":[["t","Too late for 0.3.13, but I'll try to find time to add it to the next version."]],"u":"https://bitcointalk.org/index.php?topic=1322.msg14787#msg14787","s":1,"n":471,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/471/"}]},{"id":"p230","k":"p","s":"bitcointalk","t":"Version 0.3.13, please upgrade","u":"https://bitcointalk.org/index.php?topic=1327","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/230/","m":[{"f":"satoshi","d":1285893275,"b":[["t","Version 0.3.13 is now available.  You should upgrade to prevent potential problems with 0/unconfirmed transactions.  Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.\n\nChanges:\n- Don't count or spend payments until they have 1 confirmation.\n- Internal version number from 312 to 31300.\n- Only accept transactions sent by IP address if -allowreceivebyip is specified.\n- Dropped DB_PRIVATE Berkeley DB flag.\n- Fix problem sending the last cent with sub-cent fractional change.\n- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.\nGavin Andresen:\n- Option -rpcallowip= to accept json-rpc connections from another machine.\n- Clean shutdown on SIGTERM on Linux.\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/\n\n(Thanks Laszlo for the Mac OSX build!)\n\nNote:\nThe SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode.  Please try this instead and let me know if it gets it right:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz\n\nYou can still control the SSE2 use manually with -4way and -4way=0.\n\nVersion 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent.  Here's a Windows build of it:\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg14788#msg14788","s":1,"n":472,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/472/"},{"f":"LZ","d":1286009178,"b":[["t","If I create a wallet and then send some bitcoin to it,\nthen wait for confirmations, then remove that wallet\nand restore it's previous copy - so the client will not\nsee that transaction. However, if I remove all blocks\nand download all blocks again - then the amount will\nappear. It would nice to make a re-count function..."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg14984#msg14984","sj":"Re: Version 0.3.13"},{"f":"LZ","d":1286011726,"b":[["t","Oh! My wallet corrupted. Dropbox <https://www.dropbox.com/referrals/NTEwNjgzMTEwOQ> saved only too\nold copies, because Bitcoin did not close the file.\nI think client must close the wallet when it is not\nneeded for any operations on it. What you think?"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg14988#msg14988","sj":"Re: Version 0.3.13"},{"f":"ShadowOfHarbringer","d":1286024407,"b":[["t","That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.\n\nI still have to add the \"-4way\" switch."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg14997#msg14997","sj":"Re: Version 0.3.13"},{"f":"theymos","d":1286059409,"b":[["t","Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15047#msg15047","sj":"Re: Version 0.3.13"},{"f":"nanotube","d":1286069067,"b":[["q","Version 0.3.13 is now available.\n- Only accept transactions sent by IP address if -allowreceivebyip is specified.\n- Option -rpcallowip= to accept json-rpc connections from another machine.","Quote from: satoshi on October 01, 2010, 12:34:35 AM"],["t","I notice that these options are not showing up in --help output... Shouldn't --help have a comprehensive listing of these options in it? (Especially given that there's no manpage or other help docs distributed in the official-release tarball?)\n\nJust an idle question, whose result I hope makes its way into the next release. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15055#msg15055","sj":"Re: Version 0.3.13"},{"f":"FreeMoney","d":1286079309,"b":[["q","Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.","Quote from: theymos on October 02, 2010, 10:43:29 PM"],["t","If they didn't confirm why would he clear them to go into the account? Is he counting blocks instead of confirmations? That seems odd."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15064#msg15064","sj":"Re: Version 0.3.13"},{"f":"theymos","d":1286080963,"b":[["q","If they didn't confirm why would he clear them to go into the account? Is he counting blocks instead of confirmations? That seems odd.","Quote from: FreeMoney on October 03, 2010, 04:15:09 AM"],["t","He sent a transaction that took coins from a transaction that will never confirm, so this transaction will also never confirm and is therefore lost (along with any change). If the person he sent it to isn't using 0.3.13, they'll also send unconfirmable transactions. It's like a virus. People need to move to 0.3.13 ASAP.\n\nIt has nothing to do with confirmations."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15066#msg15066","sj":"Re: Version 0.3.13"},{"f":"mizerydearia","d":1286083512,"b":[["t","I suggest a manpage should be included in the tarball."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15067#msg15067","sj":"Re: Version 0.3.13"},{"f":"nanotube","d":1286085546,"b":[["q","Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him \"unconfirmable\" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.","Quote from: theymos on October 02, 2010, 10:43:29 PM"],["t","I can agree with that. otherwise the 0/unconf txns can propagate through the network and mess up a lot of people's wallets."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15072#msg15072","sj":"Re: Version 0.3.13"},{"f":"satoshi","d":1286129826,"b":[["q","That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.\n\nI still have to add the \"-4way\" switch.","Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM"],["t","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.\n\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?\n\nDo all AMDs that support 64-bit have the better SSE2 hardware also?"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15102#msg15102","s":1,"n":473,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/473/","sj":"Re: Version 0.3.13"},{"f":"satoshi","d":1286134746,"b":[["t","Could a few people please run this special build?  It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now.  We really just need one block letting them through to clear up the previous transactions.  Post if you generate a block with this.\n\nThese are binaries only.  The linux version is 64-bit only.\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip\nhttp://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz\n\nSHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip\nSHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz\n\nThe linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15110#msg15110","s":1,"n":474,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/474/"},{"f":"tcatm","d":1286135145,"b":[["t","Can you include the source? Or better the diff for those transactions? I could run it on my 983 Mhash/s box."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15111#msg15111"},{"f":"satoshi","d":1286135372,"b":[["q","983 Mhash/s box.","Quote from: tcatm on October 03, 2010, 07:45:45 PM"],["t","Seriously?  What hardware is that?"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112","s":1,"n":475,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/475/"},{"f":"tcatm","d":1286135415,"b":[["t","Three GPUs (ATI HD 5870)."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15113#msg15113"},{"f":"satoshi","d":1286136144,"b":[["c","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 @@\n     bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >=  60026) ||\n                      (fAMD   && nFamily * 10000 + nModel >= 160010));\n \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+\n     static bool fPrinted;\n     if (!fPrinted)\n     {\n@@ -2989,6 +2993,17 @@\n \n                     // Transaction fee based on block size\n                     int64 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\n \n                     map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);\n                     if (!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 @@\n class CAutoFile;\n static const unsigned int MAX_SIZE = 0x02000000;\n \n-static const int VERSION = 31300;\n-static const char* pszSubVer = \"\";\n+static const int VERSION = 31301;\n+static const char* pszSubVer = \" test1\";"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116","s":1,"n":476,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/476/"},{"f":"theymos","d":1286136591,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118"},{"f":"tcatm","d":1286136647,"b":[["t","It's running. Should find a block within 3 hours."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119"},{"f":"satoshi","d":1286139247,"b":[["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.","Quote from: theymos on October 03, 2010, 08:09:51 PM"],["t","Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.\n\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.\n\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."],["q","The person who originally sent the broken transactions deleted his wallet","Quote from: theymos on October 03, 2010, 08:09:51 PM"],["t","Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case?  You should never delete a wallet."],["q","It's running. Should find a block within 3 hours.","Quote from: tcatm on October 03, 2010, 08:10:47 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136","s":1,"n":477,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/477/"},{"f":"theymos","d":1286140019,"b":[["t","Block 83018 (00000000002bba570c3) cleared out a bunch of them. Last I heard nanotube still had one that's unconfirmed, though.\n\nEdit: Nanotube's transaction cleared recently. I don't know why it was delayed, since it wasn't relying on a sub-0.01 transaction."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15138#msg15138"},{"f":"mizerydearia","d":1286141088,"b":[["q","> Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM\n> That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.\n>\n> I still have to add the \"-4way\" switch.\nForgot 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.\n\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?\n\nDo all AMDs that support 64-bit have the better SSE2 hardware also?","Quote from: satoshi on October 03, 2010, 06:17:06 PM"],["c","$ grep -i cpuid debug.log\nCPUID 444d4163 family 16, model 5, stepping 2, fUseSSE2=0"],["t","/proc/cpuinfo <http://pastebin.com/mkis0AsC>"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15141#msg15141","sj":"Re: Version 0.3.13"},{"f":"ShadowOfHarbringer","d":1286141771,"b":[["q","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.\n\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?\n\nDo all AMDs that support 64-bit have the better SSE2 hardware also?","Quote from: satoshi on October 03, 2010, 06:17:06 PM"],["t","Will that be enough ?:"],["c","cat /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"],["t","EDIT:\nAlso, i have just found out how to do the cpuid thingy:"],["c","CPUID 444d4163 family 16, model 2, stepping 3, fUseSSE2=0"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15144#msg15144","sj":"Re: Version 0.3.13"},{"f":"satoshi","d":1286142200,"b":[["t","ShadowOfHarbringer, is yours faster with -4way?\n\nIf it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15147#msg15147","s":1,"n":480,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/480/"},{"f":"ShadowOfHarbringer","d":1286145136,"b":[["q","ShadowOfHarbringer, is yours faster with -4way?","Quote from: satoshi on October 03, 2010, 09:43:20 PM"],["t","Indeed, it is almost 2 x as fast with -4way as it is without.\n\nI get about 8500 khash/sec with -4way, and 4500 khash/sec without."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15155#msg15155"},{"f":"nanotube","d":1286145345,"b":[["q","Any 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.\n\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.","Quote from: satoshi on October 03, 2010, 08:54:07 PM"],["t","I have one transaction that remains perpetually in 0/unconfirmed status in my wallet. Here are the details, as shown in debug mode:"],["c","Status: 0/unconfirmed\nDate: 09/29/2010 12:46\nFrom: unknown\nTo: 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU (yours, label: gribble stored address)\nCredit: 0.03\nNet amount: +0.03\n\ndebug print\nCredit: 0.03\nInputs:\n\nTransaction:\nCTransaction(hash=5c05d9, ver=1, vin.size=1, vout.size=1, nLockTime=0)\n   CTxIn(COutPoint(b412a0, 0), scriptSig=3045022049753afb02f58a7b)\n   CTxOut(nValue=0.03000000, scriptPubKey=OP_DUP OP_HASH160 e2ccd6)"],["t","Would appreciate it if you take a look and see what's wrong with it and why it remains unconfirmed...."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15156#msg15156"},{"f":"nanotube","d":1286145825,"b":[["q","Block 83018 (00000000002bba570c3) cleared out a bunch of them. Last I heard nanotube still had one that's unconfirmed, though.\n\nEdit: Nanotube's transaction cleared recently. I don't know why it was delayed, since it wasn't relying on a sub-0.01 transaction.","Quote from: theymos on October 03, 2010, 09:06:59 PM"],["t","just a clarification, the one that \"cleared recently\" didn't have anything to do with the problem microtransactions. the problem one, that was unconfirmed, is still unconfirmed, see info in my post above. "]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15157#msg15157"},{"f":"lfm","d":1286148889,"b":[["q","Do all AMDs that support 64-bit have the better SSE2 hardware also?","Quote from: satoshi on October 03, 2010, 06:17:06 PM"],["t","Old AMD Sempron 64 does not have the good sse2 speed.  This one should stay with -4way=0\n\nCPUID 444d4163 family 15, model 44, stepping 2, fUseSSE2=0"]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15160#msg15160","sj":"Re: Version 0.3.13"},{"f":"lfm","d":1286149479,"b":[["q","> Quote from: satoshi on October 01, 2010, 12:34:35 AM\n> Version 0.3.13 is now available.\n> - Only accept transactions sent by IP address if -allowreceivebyip is specified.\n> - Option -rpcallowip= to accept json-rpc connections from another machine.\n\nI notice that these options are not showing up in --help output... Shouldn't --help have a comprehensive listing of these options in it? (Especially given that there's no manpage or other help docs distributed in the official-release tarball?)\n\nJust an idle question, whose result I hope makes its way into the next release. Smiley","Quote from: nanotube on October 03, 2010, 01:24:27 AM"],["t","The command line switches are listed in \"bitcoind -?\" instead of \"bitcoind help\". You are still right tho, those options are missing from \"-?\" too."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15166#msg15166","sj":"Re: Version 0.3.13"},{"f":"satoshi","d":1286149579,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1327.msg15167#msg15167","s":1,"n":482,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/482/"}]},{"id":"p231","k":"p","s":"bitcointalk","t":"How to overthrow the GPU Oligarchs","u":"https://bitcointalk.org/index.php?topic=1332","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/231/","m":[{"f":"chickenado","d":1285932706,"b":[["t","The strength of this project was meant to be its distributedness.\n\nBut now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.\n\nThe average user no longer has a fighting chance and has given up generating blocks altogether.\n\nWhat does this remind me of? That's right, bitcoin is becoming like the physical money economy, where a small number of central banks now guarantee the trustworthiness of paper money.\n\nThere are two problems: One, the possibility of market manipulation, and more importantly, if only a handful of people do most of the proof of work, what is the point of a decentralized currency in the first place? It weakens us, because a powerful attacker would only need to bribe a few people to gain more than 50% of khash/s.\n\nTo stop this, I suggest the following:\n\n1) Add more hash functions that must be solved in addition to SHA-2. The more, the better. The function ecosystem should include functions with very different requirements, eg. some that require lots of memory, some that can't be paralellized, some that require lots of disk space,...\nAlso, function parameters that change randomly every time difficulty changes. This would take away some advantage from people who are highly specialized at solving just one hash function.\n\n2) Pooled block generation. For instance, if 100 users join a pool and one block is solved, the 50 coins are distributed among those users. This would encourage amateur users to start generating again."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14838#msg14838"},{"f":"nelisky","d":1285934743,"b":[["t","Pooled generation: +1\n\nAdd more hash functions... how would this balance the generation? People with better hw would still generate more, in all hash functions. Maybe not GPU / massive parallel, but any problem more/better hardware can't help resolve is probably out of general user's boundaries.\n\nGPU and unfairness. Realize that the hardware needed to stand a chance of generating isn't all that cutting edge or expensive. Any mid-level gamer machine has the engine to put out 20 or 30 million hashes/sec, at least. The real issue is software, as this gives the owner of such software a huge advantage for a very small price, thus people will obviously take advantage of this as long as possible.\n\nI feel stupid, really. I could put a little more money/effort into this, say nothing about it, and generate away. Instead here I am with my sense of community duty and such... damn, I'll never get rich this way Smiley\n\nIf you feel strongly as to the need for fairness, why don't you Help the little ol CUDA developer <http://\"http://bitcointalk.org/index.php?topic=1324.msg14755#msg14755>?"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14841#msg14841"},{"f":"hugolp","d":1285935942,"b":[["t","Someone should work on making the GPU code open. That is the best way to stop this."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14842#msg14842"},{"f":"chickenado","d":1285936338,"b":[["q","If you feel strongly as to the need for fairness, why don't you Help the little ol CUDA developer <http://\"http://bitcointalk.org/index.php?topic=1324.msg14755#msg14755>?","Quote from: nelisky on October 01, 2010, 12:05:43 PM"],["t","My concern isn't really fairness, it's stability.\n\nI buy about $20 worth of BTC each month, but I spend most of them straight away. What is keeping me from buying $1000 worth of BTC is my concern with the problems I mentioned. As a way of transferring money Bitcoin is great, as a way of saving money it is still too risky for my tastes. To succeed as a currency it must be good at both."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14844#msg14844"},{"f":"nelisky","d":1285936680,"b":[["q","> Quote from: hugolp on October 01, 2010, 12:25:42 PM\n> Someone should work on making the GPU code open. That is the best way to stop this.\nThat's exactly what nelisky is doing. Feel free to follow his link and help him.","Quote from: ribuck on October 01, 2010, 12:29:45 PM"],["t","Have done, actually. There is working (and generating) code already available here <http://bitcointalk.org/index.php?topic=1009.0>. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).\n\nThe mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.\n\nI'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14845#msg14845"},{"f":"Anonymous","d":1285940232,"b":[["q","> Quote from: ribuck on October 01, 2010, 12:29:45 PM\n> > Quote from: hugolp on October 01, 2010, 12:25:42 PM\n> > Someone should work on making the GPU code open. That is the best way to stop this.\n> That's exactly what nelisky is doing. Feel free to follow his link and help him.\n\nHave done, actually. There is working (and generating) code already available here <http://bitcointalk.org/index.php?topic=1009.0>. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).\n\nThe mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.\n\nI'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too Smiley","Quote from: nelisky on October 01, 2010, 12:38:00 PM"],["t","Thanks for the work you are doing. "]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14846#msg14846"},{"f":"nelisky","d":1285941691,"b":[["q","> Quote from: nelisky on October 01, 2010, 12:38:00 PM\n> > Quote from: ribuck on October 01, 2010, 12:29:45 PM\n> > > Quote from: hugolp on October 01, 2010, 12:25:42 PM\n> > > Someone should work on making the GPU code open. That is the best way to stop this.\n> > That's exactly what nelisky is doing. Feel free to follow his link and help him.\n>\n> Have done, actually. There is working (and generating) code already available here <http://bitcointalk.org/index.php?topic=1009.0>. It is known to work on OSX 10.6 (my dev environment) and linux (myself on ubuntu 10.04 and the Russian folks I'm not sure what OS).\n>\n> The mentioned thread is a request for help in pursuing this, which I will with or without said help so you can safely ignore and still have a go at the outcome. The difference will be the amount of effort I put in this and thus the time to completion.\n>\n> I'd also be happy to have someone else pick up the code too, but I fear all that have done so already are generating on their own, not giving anything back. The complete lack of developer feedback seems to point that way, at least. But, hey, we're only human, and we were taught to take advantage of the situation everytime we can, I understand. I'm just trying to teach my kids otherwise, by showing them being generous can work too Smiley\n\nThanks for the work you are doing.","Quote from: Anonymous on October 01, 2010, 01:37:12 PM"],["t","My pleasure, really. But in all fairness, it is not true I don't get both appreciation and donations. What happens is the folks that do support me do so in a very altruistic way, as in \"that sounds great for the community, keep it up\" kind of way. These helping members do not have, to the best of my knowledge, any particular interest in the work I do, just think it helps everyone out.\n\nThe ones that have the hardware to take advantage of this, if they do exist, keep very, very silent Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14848#msg14848"},{"f":"theymos","d":1285947019,"b":[["q","But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.\n\nThe average user no longer has a fighting chance and has given up generating blocks altogether.","Quote from: chickenado on October 01, 2010, 11:31:46 AM"],["t","It's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated \"backbone\" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network?\n\nI'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are \"taking without giving back\". People dedicated to generating deserve a head-start on new technologies."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14854#msg14854"},{"f":"kiba","d":1285948029,"b":[["t","This is a non-issue. Nothing to see here, keep moving."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14856#msg14856"},{"f":"nelisky","d":1285948885,"b":[["q","> Quote from: chickenado on October 01, 2010, 11:31:46 AM\n> But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.\n>\n> The average user no longer has a fighting chance and has given up generating blocks altogether.\n\nIt's always been the plan for block generation to not be profitable for most people. It's supposed to be done mainly by dedicated \"backbone\" entities. What's stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network's integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network?\n\nI'm not saying that GPU code shouldn't be made, but it's not fair to say that GPU generators are \"taking without giving back\". People dedicated to generating deserve a head-start on new technologies.","Quote from: theymos on October 01, 2010, 03:30:19 PM"],["t","I was under the impression that coin generation was a way to make sure everyone had a fair chance of putting effort against coins, thus avoiding any central committee of deciding the future of bitcoins. Decentralized is the word, I believe...\n\nBut I get it, if you put the time and money into getting better miners, you should be able to keep it to yourself, so the 4way patch should never had been merged into mainline, as its creator would have 2x+ performance over the same machine running common clients.\n\nI have to disagree here. Yes, competition is good and valuable, and people should not get into bitcoins for the mining alone, but if you let a small subset of people hold most of the future generated coins you are putting the whole project in danger of abuse and destruction... but I may be overreacting.\n\nI'll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting... you say I should, right?"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14859#msg14859"},{"f":"theymos","d":1285949551,"b":[["q","I'll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting... you say I should, right?","Quote from: nelisky on October 01, 2010, 04:01:25 PM"],["t","The network will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.\n\nPosting GPU code now will just prolong the period when generation is feasible for normal people. This will attract a few users, and it might increase the network's total power on the short-term, but on the long-term it'll have little value. If I were you, I'd keep the code private. Publishing it wouldn't be bad for the network, though."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14861#msg14861"},{"f":"TTBit","d":1285949717,"b":[["t","Start a pool yourself. If you are generating 4000k/sec 10 others are generating 20,000k/sec combined, you get 4,000/24,000 of each block generated. Seems this code could be introduced. I don't think the GPU Oligarchs are making a mint, in fact, I bet they are losing money to my benefit.\n\nI bet you could pay nelisky for proprietary code yourself. But, the economics won't work out."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14863#msg14863"},{"f":"theymos","d":1285950179,"b":[["t","Pools won't eliminate the \"problem\" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14864#msg14864"},{"f":"chickenado","d":1285952632,"b":[["q","The network will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.","Quote"],["t","It will if proof-of-work comes down to something as specialized as solving a single, well-defined, simple, and predictable hash function such as SHA-2.\n\nWe need to make proof-of-work more choatic and complex if we want to avoid this. \n\nSHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work. \n\nOtherwise, it will end just like you say.\n\nThink of this vision of the year 2020: 2/3 of the world's Ghash/s is controlled by just three companies. They manufacture their own specialilsed HPUs (hash processing units) and feed them with custom-built power plants. The Chinese goverment then persuades the three companies to double spend 10% of all transactions into the Chinese government's bitcoin address, in return the companies get an exclusive deal on the rare earths they badly need for the HPU manufacture. Some people leave Bitcoin for alternative currencies without the 10% \"tax\", but most tolerate it because by then Bitcoin is accepted almost universally."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14869#msg14869"},{"f":"nelisky","d":1285953109,"b":[["q","> Quote\n> The network will eventually be run by \"oligarchs\". Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won't be able to keep up.\n\nIt will if proof-of-work comes down to something as specialized as solving a single, well-defined, simple, and predictable hash function such as SHA-2.\n\nWe need to make proof-of-work more choatic and complex if we want to avoid this. \n\nSHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work. \n\nOtherwise, it will end just like you say.\n\nThink of this vision of the year 2020: 2/3 of the world's Ghash/s is controlled by just three companies. They manufacture their own specialilsed HPUs (hash processing units) and feed them with custom-built power plants. The Chinese goverment then persuades the three companies to double spend 10% of all transactions into the Chinese government's bitcoin address, in return the companies get an exclusive deal on the rare earths they badly need for the HPU manufacture. Some people leave Bitcoin for alternative currencies without the 10% \"tax\", but most tolerate it because by then Bitcoin is accepted almost universally.","Quote from: chickenado on October 01, 2010, 05:03:52 PM"],["t","Generation will be less and less interesting in that way, as the coins per block will divide by 2 until there's no coins generated at all, and the system will need to be run by \"volunteers\", which aren't really volunteers because if no block is generated no coins can be transfered, thus removing all value from all coins...\n\nI think it's an arms wrestle to try to avoid having a few people holding most of the coins, that's all. I was trying to leverage that by making everyone have a fair chance at getting coins while they are still being generated, but I fear that it is not practical.. When it comes to currencies (and I don't want to get into a semantics discussion, humour me with 'currency') people are just wired in a very egotistic way, and even when offered the chance to balance the scoreboard, they will just try and use that to their own advantage, not everyone's... it saddens me, really, but hey I'll keep on doing what I do because I strongly believe in it, just as others believe in taking the largest slice."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14870#msg14870"},{"f":"theymos","d":1285955140,"b":[["q","Generation will be less and less interesting in that way, as the coins per block will divide by 2 until there's no coins generated at all, and the system will need to be run by \"volunteers\", which aren't really volunteers because if no block is generated no coins can be transfered, thus removing all value from all coins...","Quote from: nelisky on October 01, 2010, 05:11:49 PM"],["t","The companies can raise fees if generations aren't enough to profit.\n\nEvery calculation can be made more efficient in hardware. Trying to prevent it is pointless. It'd be a lot like making effective DRM."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14873#msg14873"},{"f":"MoonShadow","d":1285958139,"b":[["q","The strength of this project was meant to be its distributedness.\n\nBut now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It's dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.\n\nThe average user no longer has a fighting chance and has given up generating blocks altogether.\n\nWhat does this remind me of? That's right, bitcoin is becoming like the physical money economy, where a small number of central banks now guarantee the trustworthiness of paper money.","Quote from: chickenado on October 01, 2010, 11:31:46 AM"],["t","You seem to have missed the point.  The distributed nature of Bitcoin is not compromised by the consentration of block generation.  Because, unlike fiat currencies and central banking, no one group or person has monopoly control of the currency, and no one can manipulate it as such.  Not even the GPU oligarchs.  Also, they are competing among themselves.  If one of them starts thinking that he has a majority of the block generation locked up, and decides he is going to try and fork-steal, the rest are going to notice the changes and they all have a strong incentive to overtake the market leader."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14877#msg14877"},{"f":"martin","d":1285959665,"b":[["q","SHA-2 was actually designed to be computationally EASY because it's original purpose was digital signing, not proof-of-work.","Quote from: chickenado on October 01, 2010, 05:03:52 PM"],["t","SHA is easy to calculate, but it's difficult to calculate a piece of data which will generate a given hash (which is [almost] what bitcoindoes). The proof of work must be difficult to calculate but easy to prove, which SHA is"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14886#msg14886"},{"f":"hugolp","d":1285959997,"b":[["q","> Quote from: nelisky on October 01, 2010, 12:05:43 PM\n> If you feel strongly as to the need for fairness, why don't you Help the little ol CUDA developer <http://\"http://bitcointalk.org/index.php?topic=1324.msg14755#msg14755>?\n\nMy concern isn't really fairness, it's stability.\n\nI buy about $20 worth of BTC each month, but I spend most of them straight away. What is keeping me from buying $1000 worth of BTC is my concern with the problems I mentioned. As a way of transferring money Bitcoin is great, as a way of saving money it is still too risky for my tastes. To succeed as a currency it must be good at both.","Quote from: chickenado on October 01, 2010, 12:32:18 PM"],["t","Mmm... Are you sure your dollars dont depreciate quicker than bitcoins? Dollars are worthless to create.\n\nAlso, thinking that holding dollars is less risky than bitcoins might be a bit naive."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14888#msg14888"},{"f":"Anonymous","d":1285980374,"b":[["t","How many Ghash's do you think Google would do if it started to generate?"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14925#msg14925"},{"f":"LZ","d":1285982830,"b":[["t","Thash's? http://cube20.org/"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14931#msg14931"},{"f":"MoonShadow","d":1285983357,"b":[["q","How many Ghash's do you think Google would do if it started to generate?","Quote from: Anonymous on October 02, 2010, 12:46:14 AM"],["t","Probably all of them, but difference would it make?  Even if they are willing to commit the full brunt of their computing resources to overtake the generation of new coins, they can't make them faster than the difficulty system would permit.  At least not for more than two weeks.  Nor can they do anything to manipulate the value of the coins already in existance, beyond the effects of the regular generation awards.  That's the beauty of the design, even Google couldn't do more than disrupt the system temporarily.  Even at this early stage, the total proof-of-work represents a supercomputing class cluster.  For what gain would anyone do such a thing?  For a max return of 50K coins over two weeks of supercomputing time?  Even Google doesn't have the computing power to rebuild the blockchain from the beginning.  Even if they did, to what end?  To steal a quarter million dollars in wealth?  Which would likely collapse the system if it could be done at all, so that value would drop to zero.  As we have seen, that difficulty level increases as the user base increases, regardless of an analysis as to the economics of each person generating.\n\nI can accept that, however unlikely, a takeover of the system is possible; but if such a thing were to happen, it certainly wouldn't go unnoticed by the Bitcoin community.  From where I stand, the odds that the Federal Reserve will cease to exist and the FRN collapse is more likely to occur first.  For that matter, I would consider a worldwide extinction-level-event to be about as likely; but I'm not going to let the risks of a meteor strike stop me from walking out on the surface of the Earth. "]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14932#msg14932"},{"f":"asdf","d":1285995368,"b":[["q","Pools won't eliminate the \"problem\" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit.","Quote from: theymos on October 01, 2010, 04:22:59 PM"],["t","Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about \"total hash/s\", it's about \"total unique hash/s\". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated. The node that generates the coin can just keep the full amount. The group will be better off together than alone. The bigger the pool, the better. In fact if these pools get much bigger than the companies (in terms of hash/s), then THEY will be severely marginalized and be forced to join the main pool or get nothing.\n\nIf the pool gets too big, then coins may be generated almost instantly at some point. This could be bad for the stability of the currency. Can anyone do the math on how many parallel coperating cpus it would take to find a coin in say, one minute?\n\nI think this is a very important issue for the success of Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14947#msg14947"},{"f":"theymos","d":1285995664,"b":[["q","Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about \"total hash/s\", it's about \"total unique hash/s\". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated.","Quote from: asdf on October 02, 2010, 04:56:08 AM"],["t","This is already guaranteed because everyone has a unique public key in their block. You reminded me of another way that pools are bad, though: since everyone uses the same public key, they have to do weird things with extraNonce, which increases the size of the block header and makes generating more difficult for them."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14949#msg14949"},{"f":"LZ","d":1285998587,"b":[["t","Can you tell more about this:\n\"they have to do weird things with extraNonce, which increases the size of the block header\"."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14960#msg14960"},{"f":"FreeMoney","d":1285999398,"b":[["q","Can you tell more about this:\n\"they have to do weird things with extraNonce, which increases the size of the block header\".","Quote from: lzsaver on October 02, 2010, 05:49:47 AM"],["t","Usually you can start the nonce at 0 because they block you are working on is made unique by the inclusion of your unique address in the generate transaction. If a group of people all send generates to the same address you need another number included to make sure that the members are not repeating work.\n\nI have no idea how important that fact is, it doesn't seem like too big of a deal to me, but theymos can elaborate."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14965#msg14965"},{"f":"theymos","d":1285999871,"b":[["q","Can you tell more about it:\n\"they have to do weird things with extraNonce, which increases the size of the block header\".","Quote from: lzsaver on October 02, 2010, 05:49:47 AM"],["t","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. After every hash attempt, you increment the Nonce header field, but since this field is only 32 bytes long, it overflows a lot. Whenever it overflows, you increment the variable-size extraNonce field. The larger extraNonce gets, the slower generating will get. It doesn't get significantly large with normal incrementing, though.\n\nIf you have a lot of computers and they're all working on the same block with the same public key, then they're all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.\n\nUndoubtedly you could design a pooling system without this flaw, but it'd be more difficult.\n\nI see that m0mchil's getwork is doing something with extraNonce. I don't know how bad that implementation is, but it theoretically must be slower than a client without it (all things being equal; clearly adding GPU support will improve performance)."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14966#msg14966"},{"f":"chickenado","d":1286013056,"b":[["q","Even Google doesn't have the computing power to rebuild the blockchain from the beginning.  Even if they did, to what end?  To steal a quarter million dollars in wealth?  Which would likely collapse the system if it could be done at all, so that value would drop to zero. ","Quote"],["t","They wouldn't need to rebuild the blockchain from the beginning. They can double spend any transaction that happens after the 50% Ghash/s takeover. Of course, if they get too greedy, the system would collapse as users become fed up with their coins being stolen all the time. But what if they decide to double spend a certain \"optimal income\" percentage of transactions, just short of what will piss off most users?"]],"u":"https://bitcointalk.org/index.php?topic=1332.msg14990#msg14990"},{"f":"grondilu","d":1286033830,"b":[["t","Non issue, imo.\n\nThose guys are just working for us.  I'll just buy their bitcoins.  It will probably be cheaper than buying expensive hardware and running it 24/24.\n\nBy selling bitcoins those might think they screw us.  I think they're just wrong."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15010#msg15010"},{"f":"gebler","d":1286123389,"b":[["q","The larger extraNonce gets, the slower generating will get.","Quote from: theymos on October 02, 2010, 06:11:11 AM"],["t","But that effect would be totally insignificant.  Even the standard client is optimized so that it doesn't need to hash the entire block header if only the last part of it has changed.  That last part includes the nonce but not the extraNonce, so a larger extraNonce wouldn't cost anything for the vast majority of all hashes, namely those where only the normal nonce has been incremented.  With today's transaction volumes, the cost of hashing the extraNonce should be less than a millionth of a percent for pools with thousands of members.  "]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15097#msg15097"},{"f":"gebler","d":1286129030,"b":[["q","If you have a lot of computers and they're all working on the same block with the same public key, then they're all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.","Quote from: theymos on October 02, 2010, 06:11:11 AM"],["t","In a centralized system, the server could simply keep a list of extraNonces in active use and give out the lowest free one.  Then you would avoid collisions without requiring more than one unique extraNonce per client.  A 3-byte extraNonce would be sufficient for millions of clients.  Note that clients of realistic performance do not really need the extraNonce to handle nonce overflow today, since such overflows happen less frequently than the periodic nTime updates (but this is not considered by the standard client today, which updates the extraNonce more liberally)."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15101#msg15101"},{"f":"chrisdbc","d":1286136513,"b":[["t","I'm just getting into this whole bitcoin thing. It seems to me already, though, that getting\ngreat results from bitcoin mining would require a server farm, super computer, etc; worrying\nabout individuals taking advantage of their GPUs or crypto accelerators is probably pointless.\nWhat can 30000 khash/s really get you? Maybe around the equivalent of $1.50 per day at\ncurrent difficulty levels? Not really a very efficient means of recouping the cost of an expensive\ngaming rig.\n\nI'd be much more concerned about what somebody with a botnet might be capable of."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15117#msg15117"},{"f":"kiba","d":1286136723,"b":[["q","I'd be much more concerned about what somebody with a botnet might be capable of.","Quote from: chrisdbc on October 03, 2010, 08:08:33 PM"],["t","So what if a botnet generate all these bitcoins? He'll be able to move markets for his money. Big deal."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15120#msg15120"},{"f":"satoshi","d":1286141404,"b":[["q","> Quote from: lzsaver on October 02, 2010, 05:49:47 AM\n> Can you tell more about it:\n> \"they have to do weird things with extraNonce, which increases the size of the block header\".\nWhen 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.","Quote from: theymos on October 02, 2010, 06:11:11 AM"],["t","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.\n\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.\n\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.\n\nSeparate machines are automatically collision proof because they have different generated public keys in the first transaction.  That also goes for each thread too."]],"u":"https://bitcointalk.org/index.php?topic=1332.msg15142#msg15142","s":1,"n":479,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/479/"}]},{"id":"p232","k":"p","s":"bitcointalk","t":"python OpenCL bitcoin miner","u":"https://bitcointalk.org/index.php?topic=1334","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/232/","m":[{"f":"m0mchil","d":1285957319,"b":[["t","Latest miner\n\npoclbm_py2exe_20120920 <http://github.com/downloads/m0mchil/poclbm/poclbm_py2exe_20120920.7z>\n\nmirror <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/poclbm_py2exe_20120920.7z>\n\nSources for poclbm are at http://github.com/m0mchil/poclbm\n\nGUI\n\nCreated by Kiv, see http://bitcointalk.org/index.php?topic=3878.0\n\nGuides\n\nWindows - http://www.newslobster.com/random/how-to-get-started-using-your-gpu-to-mine-for-bitcoins-on-windows\n\nUbuntu - http://bitcointalk.org/index.php?topic=2636\n\nMac - http://forum.bitcoin.org/index.php?topic=12360\n\nKnown best settings\n(please PM better/best settings for your platform)\n\nAMD 5xxx and up\nuse '-v -w 128'\n\nFrequently asked questions\n\nQ: Does my video card / driver supports OpenCL?\n\nAMD - 4xxx and up. Nvidia - 8xxx and up. On Windows you can use 'GPU Caps Viewer' or similar.\n\nQ: I am seeing 'pyopencl.LogicError: clGetPlatformIDs failed', what is this?\nQ: It says 'ImportError: DLL load failed: The specified module could not be found'?\nQ: Or 'ImportError: DLL load failed: The specified procedure could not be found'?\n\nYou don't have proper OpenCL support. The reasons may vary. Be sure to remove any old drivers and SDK from different vendors you may have used. Use web search to see how to make it work for your combination of GPU and OS.\n\nQ: When I try to run it with the following parameters: '--host=http://mining.bitcoin.cz:8332' miner errors out with  'nonnumeric port'\n\nRemove 'http://', it's intended for browsers (becames '--host=mining.bitcoin.cz'). Use '--port' to specify port (default is 8332 so you don't need to specify it if the pool you use is at same port).\n\nQ: Why it uses 100% CPU?\n\nYou probably selected the CPU as OpenCL device. Or you are using it on Linux with AMD Stream SDK 2.2. Use 2.1 instead.\n\nQ: What does 'invalid or stale' means?\n\nThe block last submitted was either invalid or stale.\n\nQ: How a block becomes stale?\n\nYou submited solution for a block which was just solved by someone else.\n\nQ: Why a block is invalid?\n\nDon't overclock too much. And switch crossfire off. Or may be I screwed the search again? Smiley It's good if you see more 'accepted's than 'invalid's.\n\nWhen I try to run the miner a new CMD window flashes on my screen too rapidly to read anything, or even see if it says anything.\n\nIt's console application. You use that ugly black thing called 'Command Prompt' to run it."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14875#msg14875"},{"f":"nelisky","d":1285958113,"b":[["q","I hope someone will try this wonderful OpenCL bitcoin miner. It uses PyOpenCl <http://mathema.tician.de/software/pyopencl>. Should be generally platform independent. The OpenCL kernel uses previous work by laszlo. You will need bitcoin patched with this <http://bitcointalk.org/index.php?topic=1333.0> to enable RPC getwork(). You may use as many external miners as you wish (if running RPC with -rpcallowip).\n\nHave fun.","Quote from: m0mchil on October 01, 2010, 06:21:59 PM"],["t","Amazing solution! Not good for the masses (it's better to integrate the miner in the binary) but great for experimentation and multiple machine mining. I'll be sure to have a go at this when I get a sec, kudos for putting this out."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14876#msg14876","sj":"Re: OpenCL miner for the masses"},{"f":"jgarzik","d":1285958157,"b":[["t","It is interesting to see how you've split mining and wallet+P2P into separate pieces.  Nice and modular.\n\nI'll be interested to see feedback from people, if they actually generate coins from this."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14878#msg14878","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1285959966,"b":[["t","nelisky: Integrating CUDA/OpenCL seems to have portability issues. Also, my goal is actually to convince satoshi to patch the mainline. The patch must be crystal clear for this to happen.\n\njgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.\n\nForgot to mention that original client generation could be used in parallel."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14887#msg14887","sj":"Re: OpenCL miner for the masses"},{"f":"nelisky","d":1285961795,"b":[["q","nelisky: Integrating CUDA/OpenCL seems to have portability issues. Also, my goal is actually to convince satoshi to patch the mainline. The patch must be crystal clear for this to happen.","Quote from: m0mchil on October 01, 2010, 07:06:06 PM"],["t","Yes, that is one of my biggest concerns. I don't have enough exposure to assert in multiple platforms / hw. And I have failed to provide a simple click and use distributable, as of yet, but as interest increases and more developers tackle this I'm sure one of us will provide a clean implementation that is production quality for satoshi."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14894#msg14894","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1285962369,"b":[["t","davidonpda: you need\n\n1. Some OpenCL capable hardware and driver.\n2. python 2.6.6 <http://www.python.org/download/releases/2.6.6/>\n3. PyOpenCL <http://mathema.tician.de/software/pyopencl>. This could be tricky, follow the official installation instructions <http://wiki.tiker.net/PyOpenCL>.\n\noclbm.py -h or --help for some options, by default looks for bitcoin RPC at 127.0.0.1:8332\n\nHope this helps"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14896#msg14896","sj":"Re: OpenCL miner for the masses"},{"f":"checker","d":1285963855,"b":[["t","Will opencl client works on ati hd3850?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14898#msg14898","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1285999248,"b":[["t","ATI HD3850 has no OpenCL support.\n\n4xxx and 5xxx have."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg14963#msg14963","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286192635,"b":[["t","Due to popular demand Smiley bitcoin PyOpenCL miner is available now at http://github.com/m0mchil/poclbm\n\nThere are some minor fixes. Be sure to experiment with globalThreads to achieve better performance/dekstop lag ratio."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15263#msg15263","sj":"Re: OpenCL miner for the masses"},{"f":"ShadowOfHarbringer","d":1286195264,"b":[["q","jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.","Quote from: m0mchil on October 01, 2010, 07:06:06 PM"],["t","Hmm, that's weird. Shouldn't the speed be much bigger, like 10-fold or 100-fold faster at least ?\n\nI mean there was this guy somewhere on the BTC forum who claimed that he's getting 983 Mhash/s (983 000 khash/sec) with just 3 radeons 5870 or something."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15278#msg15278","sj":"Re: OpenCL miner for the masses"},{"f":"nelisky","d":1286195683,"b":[["q","> Quote from: m0mchil on October 01, 2010, 07:06:06 PM\n> jgarzik: I tested this against vanilla client to be sure blocks are actually accepted. On ATI 4350 it makes ~5800 khash/s.\n\nHmm, that's weird. Shouldn't the speed be much bigger, like 10-fold or 100-fold faster at least ?\n\nI mean there was this guy somewhere on the BTC forum who claimed that he's getting 983 Mhash/s (983 000 khash/sec) with just 3 radeons 5870 or something.","Quote from: ShadowOfHarbringer on October 04, 2010, 12:27:44 PM"],["t","Yeah, I'm struggling with how OpenCL compiles kernels and the impact of the work size on performance. It is quite counter intuitive coming from CUDA, as the unrolling of loops and functions actually makes performance worse, as the kernel needs more space. I don't have any numbers for that ATI, but the 4350 seems to be a LOT less performant than the 5870, so it might not be that low.\n\nOnce I have hardware to test this for real, I'll compare my approach to this one, so we can learn from each other."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15279#msg15279","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286196760,"b":[["t","There is information on wikipedia about the performance of various AMD/ATI <http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units> and Nvidia <http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units> chips.\n\n4350 is cited at 92 GFLOPS. 5870 has 2720 GFLOPS. tcatm has 3x5870s. Due to it's superior architecture 5870 is capable of more than just the difference in GFLOPS. For example I get 6 Mhash/s on 4350 and 137 Mhash/s on 5770 (ratio of 1/22) even if the ratio of GFLOPS for the relevant cards is 92 to 1360 (1/14)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15282#msg15282","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1286200672,"b":[["t","don't have an ATI card, but even after reading those performance-infos i still can't believe that 980something-mega-hash.\n\n5.800khash on a hd4350 makes sense to me, i get around 5-6.000 on a 8600gt, both listed around 100GFlops.\nmy gtx260 gets ~40Mhash, 874GFlops\ni'd expect a hd5870 makes at least 3times as much, cuz it's listed with 2700GFlops,\nwhich would result in around 400Mhash for 3 of those cards,\nthat's what i would expect, so where's those extra 600Mhash coming from? Huh\nit's superior architecture?\nif so, my next card will be ati again.  Grin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15291#msg15291","sj":"Re: OpenCL miner for the masses"},{"f":"nelisky","d":1286200974,"b":[["q","don't have an ATI card, but even after reading those performance-infos i still can't believe that 980something-mega-hash.\n\n5.800khash on a hd4350 makes sense to me, i get around 5-6.000 on a 8600gt, both listed around 100GFlops.\nmy gtx260 gets ~40Mhash, 874GFlops\ni'd expect a hd5870 makes at least 3times as much, cuz it's listed with 2700GFlops,\nwhich would result in around 400Mhash for 3 of those cards,\nthat's what i would expect, so where's those extra 600Mhash coming from? Huh\nit's superior architecture?\nif so, my next card will be ati again.  Grin","Quote from: BitLex on October 04, 2010, 01:57:52 PM"],["t","There's a lot more than GFlops to this equation. Memory bandwidth, for one, will be very important."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15292#msg15292","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1286202561,"b":[["t","of course, but still\ni'd like to know if that's a usual expectation on ati cards compared to nvidia,\nno single-hd5870-users around that want to share their hash-count?\n\ni'm gonna buy a new card sooner or later anyway and i don't mind if it says ati or nvidia on it,\nboth will surely run my game/s.\nbut if one of them is x times better crunching blocks and besides that, prolly cheaper too,\ni already know what my next favourite brand is. "]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15294#msg15294","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286206257,"b":[["t","Sorry, just realized i broke it with latest changes, please update. (It won't submit to RPC properly)"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15307#msg15307","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286292674,"b":[["t","Added auto adjustment to keep desktop responsive. Also, doing hash rate calculation at user defined interval."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15500#msg15500","sj":"Re: OpenCL miner for the masses"},{"f":"martin","d":1286317675,"b":[["q","I can't get the getwork patch to compile into bitcoin. Is that something satoshi has considered adding to the main trunk?\n\nI've got PyOpenCL finally installed but without the patch in the client, I can't request anything.","Quote from: davidonpda on October 05, 2010, 05:29:51 PM"],["t","I'm in the same position. All I need is the patch compiled into the client and I should be ready to go :/"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15573#msg15573","sj":"Re: OpenCL miner for the masses"},{"f":"L29Ah","d":1286321324,"b":[["t","i'm getting http://paste.pocoo.org/show/271546/ when trying to run it"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15581#msg15581","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286361779,"b":[["t","Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please use the repo <http://github.com/m0mchil/poclbm>."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15636#msg15636","sj":"Re: OpenCL miner for the masses"},{"f":"ShadowOfHarbringer","d":1286365948,"b":[["t","Do i need to use a special version of graphics drivers to get the OpenCL client working ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15646#msg15646","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286379325,"b":[["t","Win32 bitcoin with getwork, against SVN 161."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15659#msg15659","sj":"Re: OpenCL miner for the masses"},{"f":"martin","d":1286385248,"b":[["t","Any chance of a 64 bit windows build? Roll Eyes"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15676#msg15676","sj":"Re: OpenCL miner for the masses"},{"f":"L29Ah","d":1286385354,"b":[["q","Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please use the repo <http://github.com/m0mchil/poclbm>.","Quote from: m0mchil on October 06, 2010, 10:42:59 AM"],["t","now it segfaults: http://paste.pocoo.org/show/271825/"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15677#msg15677","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286396717,"b":[["t","Sorry, forgot about that. You should install json-rpc. See at http://json-rpc.org/wiki/python-json-rpc\n\nL29Ah, unfortunately there isn't Nvidia card here to test with it. I suppose you should try different drivers. It seems the problem is in nvidia OpenCL compiler."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15711#msg15711","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286426942,"b":[["t","Use '-server'."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15777#msg15777","sj":"Re: OpenCL miner for the masses"},{"f":"mizerydearia","d":1286440300,"b":[["q","Slightly improved kernel (~10%). Fixed a problem with rotate() and Nvidia OpenCL. I won't upload anymore to the forum, please use the repo <http://github.com/m0mchil/poclbm>.","Quote from: m0mchil on October 06, 2010, 10:42:59 AM"],["t","Added to http://www.bitcoin.org/wiki/doku.php?id=repositories"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15801#msg15801","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286455275,"b":[["t","Can anyone pls upload the Stream SDK 2.2 for 64bit Windows 7 pls ?\nAMD link is down -.-"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15822#msg15822","sj":"Re: OpenCL miner for the masses"},{"f":"nelisky","d":1286459631,"b":[["q","Got it working:\n\n295525 khash/s!!!\n\nHoly mother of <Insert supreme being here>","Quote from: davidonpda on October 07, 2010, 01:49:46 PM"],["t","Please, do share some hw details Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15832#msg15832","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286460042,"b":[["t","damn, i cant get python to register properly.\ndoes anyone know how to fix that on win7-64 ?\n\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\Pythoncore\\2.7\\InstallPath = C:\\Python27\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\Pythoncore\\2.7\\PythonPath = C:\\Python27;C:\\Python27\\Lib;C:\\Python27\\DLLs\n\nand\n\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Python\\Pythoncore\\2.7\\InstallPath = C:\\Python27\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Python\\Pythoncore\\2.7\\PythonPath = C:\\Python27;C:\\Python27\\Lib;C:\\Python27\\DLLs\n\ndont work."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15835#msg15835","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286461870,"b":[["q","Smoketoomuch, get version 2.6.6 AND get the 32 bit binaries.\n\nIf you install the 64 bit, the extensions are all based on 32 bit, and it won't find your installation. Reinstall with 32 bit and you're golden.","Quote from: davidonpda on October 07, 2010, 02:10:09 PM"],["t","oh ok, thanks, now it works.\nall I need is a stream sdk for 64 bit now -.- cmon AMD! fix it!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15843#msg15843","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286463244,"b":[["t","wtf ?\nwhen I click that link I get forwarded to http://developer.amd.com/Pages/amd404.aspx\n\nedit: works with IE O.o but not with firefox, hmm.\nmaybe I changed my http referrer settings or something.\n\n__________________________________________________\n\nwhile trying to install pyopencl 0.92 with \"python setup.py install\" I get the following error:"],["c","Traceback (most recent call last):\n  File \"setup.py\", line 160, in <module>\n    main()\n  File \"setup.py\", line 50, in main\n    warn_about_no_config=False)\n  File \"c:\\Users\\STM\\Desktop\\OpenCL Bitcoin\\pyopencl-0.92\\aksetup_helper.py\", line 164, in get_config\n    return schema.read_config()\n  File \"c:\\Users\\STM\\Desktop\\OpenCL Bitcoin\\pyopencl-0.92\\aksetup_helper.py\", line 366, in read_config\n    cfile, key))\nKeyError: 'invalid config key in .\\\\siteconf.py: SHIPPED_CL_HEADERS'"],["t","using Python 2.6.6, setuptools 0.6c11, NumPy 1.5.0, SciPy 0.8.0, Boost 1.44\n\nany recommendation ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15847#msg15847","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286472758,"b":[["c","BOOST_INC_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44']\nBOOST_LIB_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44\\lib']\nBOOST_COMPILER = 'msvc'\nBOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']\nBOOST_THREAD_LIBNAME = ['boost_thread-vc90-mt-1_44']\nCL_TRACE = False\nCL_ENABLE_GL = False\nSHIPPED_CL_HEADERS = False\nCL_INC_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\include']\nCL_LIB_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\lib\\x86']\nCL_LIBNAME = ['OpenCL']\nCXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']\nLDFLAGS = ['/FORCE']"],["t","Thats my current siteconfig.py, but I will try yours now.\n\nEdit: thx man, your my hero now ^^"],["c","BOOST_INC_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44']\nBOOST_LIB_DIR = [r'C:\\Program Files (x86)\\boost\\boost_1_44\\lib']\nBOOST_COMPILER = 'msvc'\nBOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']\nUSE_SHIPPED_BOOST = False\nCL_TRACE = False\nCL_ENABLE_GL = False\nCL_INC_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\include']\nCL_LIB_DIR = [r'C:\\Program Files (x86)\\ATI Stream\\lib\\x86']\nCL_LIBNAME = ['OpenCL']\nCXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']\nLDFLAGS = ['/FORCE']"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15871#msg15871","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286473888,"b":[["t","hey, it's me .. again ...\n\npython poclbm.py -->"],["c","Traceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n    import pyopencl as cl\n  File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>\n    import pyopencl._cl as _cl\nImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden."],["t","Seems like a DLL is missing."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15876#msg15876","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286476860,"b":[["t","I copied them into system32, this usually sloves these problems, but I'm gonna try it.\n\nPS: the German error message only says, that the module was not found.\n\nEDIT: and again, you were right Cheesy\n\nbut now a new error message shows up:"],["c","C:\\Program Files (x86)\\Bitcoin>python poclbm.py\nUnable to communicate with bitcoin RPC"],["t","I'm using this client:"],["q","Win32 bitcoin with getwork, against SVN 161. Download <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/bitcoin-getwork-svn161-win32.7z>","Quote from: m0mchil on October 06, 2010, 03:35:25 PM"],["t","EDIT2: ok forget it, forgot about the -server switch\nEDIT3: yay it works, finally.\nBUT, now it asks for username and passwords every ~8 seconds.... ?\n\nEDIT4: I changed the default values for user and pw in pocbm.py and now it works Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15888#msg15888","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286479240,"b":[["t","ASUS Radeon HD4870 512MB gpu@750MHz vram@900(1800)MHz\n~75500khashs/s\ngpu temp currently @74°C (bios-modded long ago to adjust fan speed)"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15895#msg15895","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286483160,"b":[["t","yes 4870, edited my post.\nand yes, more people should use it Smiley\nnow I can generate bitcoins on my gpu and rainbow tables on my cpu at the same time Tongue"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15906#msg15906","sj":"Re: OpenCL miner for the masses"},{"f":"martin","d":1286483751,"b":[["q"," More people need to jump on board of the OpenCL miner.","Quote from: davidonpda on October 07, 2010, 07:27:29 PM"],["t","Anyone fancy building a 64bit windows build of bitcoin suitable for the OpenCL miner? It may be worth some bitcoins Wink"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15910#msg15910","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286488172,"b":[["t","Yes, I am.\n\nUhm, does anyone know if poclbm works with mutliple graphic cards ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15923#msg15923","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286515395,"b":[["q","Here's one for you.\n\nIt just found another block, and... bitcoin doesn't show anything...","Quote from: davidonpda on October 08, 2010, 12:05:36 AM"],["t","The miner asks for work at an interval of 10 seconds. If there is a new block from the network in the last such interval your client won't even try to announce your own next block. I am not sure, but I think this is the behavior of the original client too. Please take a look at your debug.log and if possible send me an excerpt from around where this happened. Look for terms like \"SetBestChain\" and \"height=\" if you know the block number.\n\nSometimes the client just doesn't show the new transaction right away."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg15986#msg15986","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286545646,"b":[["t","Right after these lines is there something like:\n\nProcessBlock: ACCEPTED\nsending: inv (37 bytes)\n\nIf so (and you are sure this is the block in question) it was announced to the network, but another block got included in the chain instead. Do you have other blocks after that?\n\nBTW, if you want poclbm to crunch slower, start it with something like -f 400. Experiment with the number."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16039#msg16039","sj":"Re: OpenCL miner for the masses"},{"f":"lfm","d":1286659628,"b":[["q","of course, but still\ni'd like to know if that's a usual expectation on ati cards compared to nvidia,\nno single-hd5870-users around that want to share their hash-count?\n\ni'm gonna buy a new card sooner or later anyway and i don't mind if it says ati or nvidia on it,\nboth will surely run my game/s.\nbut if one of them is x times better crunching blocks and besides that, prolly cheaper too,\ni already know what my next favourite brand is.","Quote from: BitLex on October 04, 2010, 02:29:21 PM"],["t","gflops is not really relevant to bitcoin mining since gflops is measure of floating point and bitcoin mining is fixed point. It think fixed point is relatively good to ati and hard for nvidia.\n\nIf you have an app that uses floating point more than fixed point the the disparity might vanish or at least diminish."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16334#msg16334","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286670448,"b":[["q","It think fixed point is relatively good to ati and hard for nvidia.","Quote from: lfm on October 09, 2010, 09:27:08 PM"],["t","That sounds interesting. Do you have any web-sources for this ?\n\n@m0mchil:\nIs your Python OpenCL client using priorization ? like, can I start a game while using your client and it will automatically slow down the hash rate and my card will focus on the game ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16353#msg16353","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286687412,"b":[["t","It only tries to keep single kernel run under specific time by changing the number of 'global' threads. If you start a game, kernel execution will get slower. The number of threads will then be gradually adjusted to achieve the desired execution time.\n\nBy default this time is 1/60 of a second. If shorter i.e. 1/120 sec it will leave more time for other GPU tasks.\n\nThis is adjusted with the '-f' switch."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16370#msg16370","sj":"Re: OpenCL miner for the masses"},{"f":"lfm","d":1286780223,"b":[["q","I can't get the getwork patch to compile into bitcoin. Is that something satoshi has considered adding to the main trunk?\n\nI've got PyOpenCL finally installed but without the patch in the client, I can't request anything.","Quote from: davidonpda on October 05, 2010, 05:29:51 PM"],["t","try :\n\n  svn co -r 161 https://bitcoin.svn.sourceforge.net/svnroot/bitcoin\n\nIt seems any other revision fails the patch."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16519#msg16519","sj":"Re: OpenCL miner for the masses"},{"f":"lfm","d":1286781345,"b":[["t","ok, I'm really new at this GPGPU stuff, I got this message when I try to run the thing:\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 28, in <module>\n    miner = cl.Program(context, kernelFile.read()).build()\n  File \"/usr/lib/pymodules/python2.6/pyopencl/__init__.py\", line 138, in program_build\n    \"Build on %s:%s\" % (dev, log) for dev, log in build_logs))\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 8400 GS' at 0xf16c40>:\n\nError: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0\n\n-------------------\nThis is on Linux 64 bit, does the \"i32 = bswap\" mean it wants linux 32?\n\nbtw I know the 8400 GS is slow, you don't have to tell me."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16521#msg16521","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286783355,"b":[["q","Error: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0","Quote from: lfm on October 11, 2010, 07:15:45 AM"],["t","Try to update your GPU driver. See http://forums.nvidia.com/index.php?showtopic=150585\n\nIt seems OpenCL is still problematic on Nvidia GPUs. Unfortunately I don't have one to try to make a PyCuda miner."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16525#msg16525","sj":"Re: OpenCL miner for the masses"},{"f":"lfm","d":1286783803,"b":[["t","I think I have the newest stuff. Ill just have to wait for the next version by the looks of it. Maybe give up on it and find an ATI card."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16528#msg16528","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286816144,"b":[["q","SPARKLE SX84GS256D2LDPP GeForce 8400 GS 256MB 64-bit DDR2 PCI Express 2.0 x16 HDCP Ready Low Profile Ready Video Card","Quote"],["t","Well .. 256mb .. DDR2 with 64 bit interface\nthis even was crap when it came on the market ^^"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16564#msg16564","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286835419,"b":[["q","ok, I'm really new at this GPGPU stuff, I got this message when I try to run the thing:\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 28, in <module>\n    miner = cl.Program(context, kernelFile.read()).build()\n  File \"/usr/lib/pymodules/python2.6/pyopencl/__init__.py\", line 138, in program_build\n    \"Build on %s:%s\" % (dev, log) for dev, log in build_logs))\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 8400 GS' at 0xf16c40>:\n\nError: Code selection failed to select: 0x138fdc0: i32 = bswap 0x138fbc0\n\n-------------------\nThis is on Linux 64 bit, does the \"i32 = bswap\" mean it wants linux 32?\n\nbtw I know the 8400 GS is slow, you don't have to tell me.","Quote from: lfm on October 11, 2010, 07:15:45 AM"],["t","Got the same error on a Win7-64 with 8600 GTS."],["c","Build on <pyopencl.Device 'GeForce 8600 GTS' at 0x2ed2f48>:\n\nError: Code selection failed to select: 0x5d57918: i32 = bswap 0x5d57808"],["t","Seems like poclbm doesn't work on nvidia cards."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16622#msg16622","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286861370,"b":[["q","> Quote from: SmokeTooMuch on October 07, 2010, 05:51:28 PM\n> hey, it's me .. again ...\n>\n> python poclbm.py -->\n>\n>\n> Traceback (most recent call last):\n>   File \"poclbm.py\", line 5, in <module>\n>     import pyopencl as cl\n>   File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>\n>     import pyopencl._cl as _cl\n> ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden.\n> Seems like a DLL is missing.\n\nCopy your boost_python-vc90-mt-1_44.dll and boost_thread-vc90-mt-1_44.dll that you compiled with boost earlier directly into your directory where you are running poclbm.py from.\n\nI don't speak German, but that looks like what it is saying to me.","Quote from: davidonpda on October 07, 2010, 06:19:21 PM"],["t","I also get this error.  I tried copying boost_python-vc90-mt-1_44.dll and boost_thread-vc90-mt-1_44.dll directly into the directory where I am running poclbm.py but it has the same error (see below).  I copied it into Windows\\System32 but still same error.  Any ideas???"],["c","C:\\bitcoin_miner>python poclbm.py\nTraceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n    import pyopencl as cl\n  File \"C:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__i\nnit__.py\", line 3, in <module>\n    import pyopencl._cl as _cl\nImportError: DLL load failed: The specified module could not be found."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16674#msg16674","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1286886328,"b":[["t","looks like a dll is missing\n\nwhich boost version are you using ?\n\nbest is to post your siteconf.py"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16710#msg16710","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286911460,"b":[["q","Post your boost version, siteconf, and os. Should be able to help you more from there. Make sure you grabbed the right dll's because several of them are named close.","Quote from: davidonpda on October 12, 2010, 02:04:13 PM"],["t","I am using Windows Vista 64-bit.  I used boost 1.44, but there was an error so I actually downloaded the binary versions of \"boost_python-vc90-mt-1_44.dll\" and \"boost_thread-vc90-mt-1_44.dll\". I used all 32-bit installations for compatibility.  Below is siteconf.py.  I was able to run \"python setup.py install\" ok without errors."],["c","BOOST_INC_DIR = ['C:\\\boost_1_44_0']\nBOOST_LIB_DIR = ['C:\\\boost_1_44_0\\\\lib']\nBOOST_COMPILER = 'msvc'\nBOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']\nUSE_SHIPPED_BOOST = False\nCL_TRACE = False\nCL_ENABLE_GL = False\nCL_INC_DIR = ['C:\\\\Program Files (x86)\\\\NVIDIA GPU Computing Toolkit\\\\CUDA\\3.2\\\\include']\nCL_LIB_DIR = ['C:\\\\Program Files (x86)\\\\NVIDIA GPU Computing Toolkit\\\\CUDA\\3.2\\\\lib\\\\Win32']\nCL_LIBNAME = ['OpenCL']\nCXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']\nLDFLAGS = ['/FORCE']"],["t","Thanks for your help!  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16732#msg16732","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286912446,"b":[["q","Awesome, so you got it working with a CUDA card?\n\nSpecs and hash rate?","Quote from: davidonpda on October 12, 2010, 07:32:14 PM"],["t","Oh, not yet...sorry if it sounded like I declared victory too early.  I still get:"],["c","ImportError: DLL load failed: The specified module could not be found."],["t","Any ideas?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16737#msg16737","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286913939,"b":[["t","I went home for lunch to debug but now I am at work. I am hardcore to get this to work.  Will work in it tonite."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16744#msg16744","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286931863,"b":[["t","I did not do the bootstrap methon.  I used the win installer with the precompiled binaries from here http://www.boostpro.com/download/ (that was what the boost site said to do). \n\nI reinstalled Python26, Numpy, SciPi, and boost 1_39.  I copied all the dlls into the same folder as poclmb.py. \n\nStill same error.\n\nHmmm..."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16780#msg16780","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286932185,"b":[["q","I completely misunderstood you sorry.\n\nSo you did not compile the dll's yourself for boost? So you might have a problem with your boost path.\n\nWhat happens when you run the bootstrap in the boost directory?\n\nThen here is what I used to build the boost libraries after bootstrapping:\n\nbjam.exe toolset=msvc --with-python --with-date_time --with-thread threading=multi link=shared\n\nThat then created a directory starting from c:/boost called C:\\boost\\stage\\lib that had the dll's in it, and is how I pointed it inside my site.conf\n\nThen I copied those dll's over. I am wondering if the dll's you downloaded aren't the right ones or don't have all the right flags or something.","Quote from: davidonpda on October 12, 2010, 07:48:27 PM"],["t","I believe I have the right flags.  In the installer I picked msvc 2008, python, date time, and thread.  There is no option for threading or link."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16781#msg16781","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286987168,"b":[["q","bitcoin-getwork-svn166-win32.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/bitcoin-getwork-svn166-win32.7z> - with key pool support (see SVN)\n\npoclbm_py2exe.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/poclbm_py2exe.7z> - this is the miner, packed with py2exe. Must be able to run without installing python, PyOpenCL, boost etc. Needs only ATI Stream SDK. Windows only. See command line options with -h to change your\n\nThe miner itself has been improved slightly, doing first 3 sha256 rounds in python. http://github.com/m0mchil/poclbm/","Quote from: m0mchil on October 13, 2010, 03:30:22 PM"],["t","OMG!  Thx david and momchil!  I was about to give up...gonna try it when I get home."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16847#msg16847","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286988711,"b":[["t","I have an nVidia card...I hope I can install the nVidia sdk instead of the ati sdk. (Fingers crossed)"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16850#msg16850","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286998041,"b":[["q","> Quote from: m0mchil on October 13, 2010, 03:30:22 PM\n> bitcoin-getwork-svn166-win32.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/bitcoin-getwork-svn166-win32.7z> - with key pool support (see SVN)\n>\n> poclbm_py2exe.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/poclbm_py2exe.7z> - this is the miner, packed with py2exe. Must be able to run without installing python, PyOpenCL, boost etc. Needs only ATI Stream SDK. Windows only. See command line options with -h to change your\n>\n> The miner itself has been improved slightly, doing first 3 sha256 rounds in python. http://github.com/m0mchil/poclbm/\n\nOMG!  Thx david and momchil!  I was about to give up...gonna try it when I get home.","Quote from: jimbobway on October 13, 2010, 04:26:08 PM"],["t","I get this error:"],["c","C:\\Users\\Bitcoin GPU\\Desktop\\poclbm_py2exe>poclbm\nTraceback (most recent call last):\n  File \"poclbm.py\", line 40, in <module>\npyopencl.LogicError: clGetPlatformIDs failed: invalid/unknown error code\n\n[\\code]"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16877#msg16877","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1286999319,"b":[["t","I went home for lunch and I am physically at my computer...back to work for me.  I have not tried puddinpop's client."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16882#msg16882","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1286999822,"b":[["t","Jimbo, please try this <http://www.geeks3d.com/20091221/how-to-enable-opencl-support-on-nvidia-and-amd-platforms/> and see if the tool shows OpenCL is supported. It would be helpful if you post a screenshot."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16883#msg16883","sj":"Re: OpenCL miner for the masses"},{"f":"GeorgeH","d":1287009993,"b":[["q","I get a 2-3% increase on the new version. Not much, but a consistent increase. I have my hashes scaled back to about 150/m so this increases it to about 153/m.\n\nIt jumps around a little bit of course, but I don't really see it dip below 153/m\n\nEdit-\nDon't get me wrong either. 3000k/hs is an extra block a month so no complaints!","Quote from: davidonpda on October 13, 2010, 05:17:04 PM"],["t","Wow! What hardware are you running?\n\nOn a more related note, I get this error when running m0m's release (8800 GTS, Driver 258.96)"],["c","C:\\Users\\Owner\\Desktop\\BitcoinOpenCL>poclbm\nTraceback (most recent call last):\n  File \"poclbm.py\", line 46, in <module>\n  File \"pyopencl\\__init__.pyc\", line 138, in program_build\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 8800 GTS 512' at 0x2dd1600>:\n\nError: Code selection failed to select: 05102178: i32 = bswap 04EFFBA8"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16901#msg16901","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1287014923,"b":[["t","i get similar results with my nvidia card"],["c","C:\\Documents and Settings\\Administrator\\Desktop\\bitcoin_stuff\\poclbm_py2exe>poclbm\nTraceback (most recent call last):\n File \"poclbm.py\", line 46, in <module>\n File \"pyopencl\\__init__.pyc\", line 138, in program_build\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce GTX 260' at 0x24325c0>:\n\nError: Code selection failed to select: 0x4ea2128: i32 = bswap 0x516dca0"],["t","here's a screenshot <http://bitlex.co.cc/static/img/screen_poclbm.jpg> of Caps Viewer and GPU-Z (for driver-info)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16910#msg16910","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1287018663,"b":[["t","ok , i have no opencl support (see image)  Sad Sad Sad Sad Sad Sad Sad Sad Sad Sad Sad"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16918#msg16918","sj":"Re: OpenCL miner for the masses"},{"f":"GeorgeH","d":1287025123,"b":[["q","Mine's an ATI 5870.\n\n...\nrun that and see if it shows OpenCL is supported. Give us a screen shot. There are some trouble shooting steps on their website.","Quote from: davidonpda on October 13, 2010, 11:15:23 PM"],["t","Wow, nice!\n\nHere's my screenie:"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16927#msg16927","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1287073533,"b":[["q","Jim, I don't know where to help from here. Two other people have OpenCL support on their Nvidia card, and still can't get it to work. Without having a set in front of me, it's hard to troubleshoot it. I do have an Nvidia card, same one as you just about, but I don't know if I'm going to swap it out to test. I'm sure our set up varies greatly and I don't know if I would be able to make any beneficial advancements doing it, sorry.","Quote from: davidonpda on October 14, 2010, 03:04:10 AM"],["t","It's ok.  I'm sure something awesome will come out, but I'm happy to test this for momchil.  thought my 8800 would have OpenCL support but it doesn't.  Thanks anyway."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16970#msg16970","sj":"Re: OpenCL miner for the masses"},{"f":"sandos","d":1287086926,"b":[["q","On a more related note, I get this error when running m0m's release (8800 GTS, Driver 258.96)\n\nC:\\Users\\Owner\\Desktop\\BitcoinOpenCL>poclbm\nTraceback (most recent call last):\n  File \"poclbm.py\", line 46, in <module>\n  File \"pyopencl\\__init__.pyc\", line 138, in program_build\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 8800 GTS 512' at 0x2dd1600>:\n\nError: Code selection failed to select: 05102178: i32 = bswap 04EFFBA8","Quote from: Smartzkid on October 13, 2010, 10:46:33 PM"],["t","I get something very similar on a 9400GT, but in linux! No idea how to fix this."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg16998#msg16998","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1287088689,"b":[["t","has ANYONE got this working on a nvidia card ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17001#msg17001","sj":"Re: OpenCL miner for the masses"},{"f":"bethel","d":1287179865,"b":[["t","I have two machines that behave totally differently under this python client.\n\nThey both have the same hardware and OS:\nAMD Semperon Single core\n1GB RAM\nASUS ATI Radeon HD 5850 overclocked to 950mhz\n\nOne machine does 300-305mhash/s and stresses the gpu to 94-97%\nThe other does 282-289mhash/s and stresses the gpu to 89-91%\n\nHow do I increase my slow machine to get the extra 20mhash? Is there a command line way to tighten the processing loop?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17154#msg17154","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1287180023,"b":[["t","Are both machines using the same driver version ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17155#msg17155","sj":"Re: OpenCL miner for the masses"},{"f":"bethel","d":1287181400,"b":[["t","They are the same.\n8.14.10.0779 Catalyst 10.9 on Windows 7 64-bit\n\nI would not expect them to be different because one is a clone of the other."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17160#msg17160","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287212891,"b":[["t","bethel, what are 5870s showing at stock frequency (850 MHz)? Perhaps one of the cards throttles down?\n\nLatest version has new parameter, -w, to set work group size. I have best results on 5770 with -w 128 -f 35."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17203#msg17203","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287249528,"b":[["t","The IDs stay the same as long as there are no changes in hardware (new cards for example).\n\nThe -w parameter sets the number of 'work group size' (local threads). Unfortunately it's very difficult to determine the optimal value for this because it's different on different hardware platforms. The default is to use maximum reported by OpenCL for the specific hardware. This also was the behavior of previous versions. Last days I tried an optimization which tests two hashes in kernel run and it is 1-2% slower with default local threads (5770 - 256), but 5-6% faster with half of them (128) and global threads little bit more (-f 35). Generally, with default parameters one should achieve about the same or slightly worse performance than before."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17239#msg17239","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287273110,"b":[["t","Hello All,\n\nI tried without success to use the Python OpenCL Miner, here's what I did and what I got :\n\nFirst my config, I run on Windows 7 Pro 32 bits with a NVIDIA GeForce 9800 GT.\n\nI downloaded and installed CUDA Toolkit from :\nhttp://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7\n-> cudatoolkit_3.2.7_win_32.msi\n\nI downloaded Boost 1.44.0 and built it with :"],["c","bjam.exe toolset=msvc --with-python --with-date_time --with-thread threading=multi link=shared"],["t","as did davidonpda on the post #81.\nThen I copied all the dll from H:\\boost_1_44_0\\stage\\lib to system32.\n\nI downloaded and built pyopencl-0.92 :\n1) running > python configure.py\n2) modifying siteconf.py :\n(example from http://www.mail-archive.com/pyopencl@tiker.net/msg00349.html)"],["c","BOOST_INC_DIR = [r'H:\\boost_1_44_0']\nBOOST_LIB_DIR = [r'H:\\boost_1_44_0\\stage\\lib']\nBOOST_COMPILER = 'msvc'\nBOOST_PYTHON_LIBNAME = ['boost_python-vc90-mt-1_44']\nUSE_SHIPPED_BOOST = False\nCL_TRACE = False\nCL_ENABLE_GL = False\nCL_INC_DIR = [r'E:\\NVIDIA GPU Computing Toolkit\\CUDA3.2\\include']\nCL_LIB_DIR = [r'E:\\NVIDIA GPU Computing Toolkit\\CUDA3.2\\lib\\Win32']\nCL_LIBNAME = ['OpenCL']\nCXXFLAGS = ['/EHsc', '/DBOOST_PYTHON_NO_PY_SIGNATURES']\nLDFLAGS = ['/FORCE']"],["t","3) running > ctags -R src || true\n4) running > python setup.py build\n -> compilation without error\n5) running > python setup.py install\n -> installation without error\n\nI downloaded poclbm from http://github.com/m0mchil/poclbm\n-> m0mchil-poclbm-cf33815.zip\n\nAnd trying to run it : > python poclbm.py"],["c","Traceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n    import pyopencl as cl\n  File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 3, in <module>\n    import pyopencl._cl as _cl\nImportError: DLL load failed: La procÚdure spÚcifiÚe est introuvable."],["t","(the text in french with the fucked accents means : The specified procedure could not be found).\n\nNote : I don't make all running together the first time, it took a long time and I can forget some step.\n\nI also tried poclbm_py2exe.7z that I got from the board (post #87), first with the original OpenCL.dll in the archive, I got an error due to my Nvidia card I gess :"],["c","No device specified, you may use -d to specify one of the following\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 57, in <module>\n  File \"pyopencl\\__init__.pyc\", line 138, in program_build\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 9800 GT' at 0x28d2be8>:\n\n:37: error: incompatible type assigning 'int', expected 'uint2'\n        work[5]=0x00000000;\n               ^~~~~~~~~~~\n:38: error: incompatible type assigning 'int', expected 'uint2'\n        work[6]=0x00000000;\n               ^~~~~~~~~~~\n..."],["t","then I tried by replacing the dll with the one from the CUDA Toolkit, and I got the same error than while running poclbm I built :"],["c","  File \"poclbm.py\", line 5, in <module>\n  File \"pyopencl\\__init__.pyc\", line 3, in <module>\n  File \"pyopencl\\_cl.pyc\", line 12, in <module>\n  File \"pyopencl\\_cl.pyc\", line 10, in __load\nImportError: DLL load failed: La procÚdure spÚcifiÚe est introuvable."],["t","So the problem come from OpenCL dll from Nvidia !\n\nI checked _cl.pyd with dependency walker, if I'm correct (this is the first time I use this tool), some functions are missing in the OpenCL.dll from Nvidia :"],["c","clSetUserEventStatus (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1051,31))\nclCreateUserEvent (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1062,20))\n                  (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1063,32))\nclCreateSubBuffer (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1165,22))\n                  (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1168,36))\nclEnqueueReadBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1416,27))\nclEnqueueWriteBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1460,27))\nclEnqueueCopyBufferRect (pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp(1496,27))"],["t","In the file OpenCL.dll in poclbm_py2exe.7z, those 6 functions exist !\n\nI got the explication with a little more search on the net, with the confirmation on those two pages :\nhttp://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/\nhttp://www.khronos.org/registry/cl/sdk/1.1/docs/man/xhtml/\n\nThe 6 functions where added in OpenCL 1.1, and Nvidia OpenCL implements the version 1.0 !\n\nSo if I'm correct pyopencl won't work on Nvidia cards until Nvidia release an OpenCL 1.1 compliant Toolkit and driver.\nSee the post below.\n\nNote from http://developer.nvidia.com/object/opencl.html"],["q","On the same day Khronos Group announced the new OpenCL v1.1 specification update (June 14th, 2010), NVIDIA released OpenCL v1.1 pre-release drivers and SDK code samples to all GPU Computing registered developers.","Quote"],["t","So you have to register as a \"GPU Computing developer\" to get the SDK and driver, I don't do it for now (you have to fill a big form which is verified before validation, and I'm not \"GPU Computing developer\"  Grin ).\n\nPS : I think you might have guessed, I'm French. sorry for mistakes and strange turns of phrase that can be  Embarrassed"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17269#msg17269","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287275448,"b":[["t","After writing the post above, I checked the file pyopencl-0.92\\src\\wrapper\\wrap_cl.hpp to see the use of the 6 functions that are not in OpenCL 1.0, and I saw an interesting point :\n\nThe use of the 6 functions is \"protected\" by blocks #ifdef CL_VERSION_1_1 / #endif.\nSo I will check why CL_VERSION_1_1 was defined when I compiled the wrapper and will try to compil it without this macro defined.\n\nMore informations to come ... later (it is now 2h33 AM in France, time to go to bed Grin ) Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17270#msg17270","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287289427,"b":[["t","jef.blanc, try to replace the rotate() function with some native rotate left. rotate() is compiled to bit_align AMD specific instruction on AMD. Also there are problems with casts... I switched to uint2 vectors and all operations with mixed types (vector, scalar) work fine on AMD, but Nvidia compilator has problems."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17303#msg17303","sj":"Re: OpenCL miner for the masses"},{"f":"GeorgeH","d":1287306405,"b":[["t","Definitely hoping to see this on nvidia in the near future! I have 2 graphics cards now and can only use one with the CUDA client!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17331#msg17331","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287308254,"b":[["t","After verification, the macro CL_VERSION_1_1 is defined in CL/cl.h from the Cuda Toolkit I installed, and this file declare the OpenCL 1.1 functions (it's logic in fact, I should have a compilation error otherwise) !\n\nSo the Toolkit I installed take in charge OpenCL 1.1, and my current Nvidia driver (that I didn't update) is still on OpenCL 1.0.\n\nI checked on the \"public\" drivers on the net, the version is still 258.96 (the one I use), so I downloaded and installed the \"Developer Drivers for WinVista and Win7 (260.61)\" from http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 (the page on which I download the CUDA Toolkit).\n\nMy OpenCL.dll file now provides the OpenCL 1.1 functions.\nI tried to run poclbm.py, as m0mchil said there is a problem with the rotate function, but pyopencl seems to work*, that's a good point Smiley\n\n* There are still some errors while running the tests provided with pyopencl, but I don't know if this is crucial.\n\nErrors on rotate :"],["c","<program source>:204:2: error: no matching function for call to 'rotate'\n        sharound(D,E,F,G,H,A,B,C,R(61),0xA4506CEB);\n        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n<program source>:4:103: note: instantiated from:\n#define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a,\n19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}\n                                                                                                      ^\n<program source>:2:19: note: instantiated from:\n#define rot(x, y) rotate(x, (uint)y)\n                  ^~~~~~\n<built-in>:3025:26: note: candidate function\nulong16 __OVERLOADABLE__ rotate(ulong16, ulong16);\n                         ^\n<built-in>:3024:25: note: candidate function\nulong8 __OVERLOADABLE__ rotate(ulong8, ulong8);\n                        ^\n<built-in>:3023:25: note: candidate function\nulong4 __OVERLOADABLE__ rotate(ulong4, ulong4);\n                        ^\n<built-in>:3019:25: note: candidate function\nulong2 __OVERLOADABLE__ rotate(ulong2, ulong2);\n                        ^\n<built-in>:3018:25: note: candidate function\nlong16 __OVERLOADABLE__ rotate(long16, long16);\n                        ^\n<built-in>:3017:24: note: candidate function\nlong8 __OVERLOADABLE__ rotate(long8, long8);\n                       ^\n<built-in>:3016:24: note: candidate function\nlong4 __OVERLOADABLE__ rotate(long4, long4);\n                       ^\n<built-in>:3012:24: note: candidate function\nlong2 __OVERLOADABLE__ rotate(long2, long2);\n                       ^\n<built-in>:3011:25: note: candidate function\nuint16 __OVERLOADABLE__ rotate(uint16, uint16);\n                        ^\n<built-in>:3010:24: note: candidate function\nuint8 __OVERLOADABLE__ rotate(uint8, uint8);\n                       ^\n<built-in>:3009:24: note: candidate function\nuint4 __OVERLOADABLE__ rotate(uint4, uint4);\n                       ^\n<built-in>:3005:24: note: candidate function\nuint2 __OVERLOADABLE__ rotate(uint2, uint2);\n                       ^\n<built-in>:3004:24: note: candidate function\nint16 __OVERLOADABLE__ rotate(int16, int16);\n                       ^\n<built-in>:3003:23: note: candidate function\nint8 __OVERLOADABLE__ rotate(int8, int8);\n                      ^\n<built-in>:3002:23: note: candidate function\nint4 __OVERLOADABLE__ rotate(int4, int4);\n                      ^\n<built-in>:2998:23: note: candidate function\nint2 __OVERLOADABLE__ rotate(int2, int2);\n                      ^\n<built-in>:2997:27: note: candidate function\nushort16 __OVERLOADABLE__ rotate(ushort16, ushort16);\n                          ^\n<built-in>:2996:26: note: candidate function\nushort8 __OVERLOADABLE__ rotate(ushort8, ushort8);\n                         ^\n<built-in>:2995:26: note: candidate function\nushort4 __OVERLOADABLE__ rotate(ushort4, ushort4);\n                         ^\n<built-in>:2991:26: note: candidate function\nushort2 __OVERLOADABLE__ rotate(ushort2, ushort2);\n                         ^\n<built-in>:2990:26: note: candidate function\nshort16 __OVERLOADABLE__ rotate(short16, short16);\n                         ^\n<built-in>:2989:25: note: candidate function\nshort8 __OVERLOADABLE__ rotate(short8, short8);\n                        ^\n<built-in>:2988:25: note: candidate function\nshort4 __OVERLOADABLE__ rotate(short4, short4);\n                        ^\n<built-in>:2984:25: note: candidate function\nshort2 __OVERLOADABLE__ rotate(short2, short2);\n                        ^\n<built-in>:2983:26: note: candidate function\nuchar16 __OVERLOADABLE__ rotate(uchar16, uchar16);\n                         ^\n<built-in>:2982:25: note: candidate function\nuchar8 __OVERLOADABLE__ rotate(uchar8, uchar8);\n                        ^\n<built-in>:2981:25: note: candidate function\nuchar4 __OVERLOADABLE__ rotate(uchar4, uchar4);\n                        ^\n<built-in>:2977:25: note: candidate function\nuchar2 __OVERLOADABLE__ rotate(uchar2, uchar2);\n                        ^\n<built-in>:2976:25: note: candidate function\nchar16 __OVERLOADABLE__ rotate(char16, char16);\n                        ^\n<built-in>:2975:24: note: candidate function\nchar8 __OVERLOADABLE__ rotate(char8, char8);\n                       ^\n<built-in>:2974:24: note: candidate function\nchar4 __OVERLOADABLE__ rotate(char4, char4);\n                       ^\n<built-in>:2970:24: note: candidate function\nchar2 __OVERLOADABLE__ rotate(char2, char2);\n                       ^\n<built-in>:2967:24: note: candidate function\nulong __OVERLOADABLE__ rotate(ulong, ulong);\n                       ^\n<built-in>:2966:23: note: candidate function\nlong __OVERLOADABLE__ rotate(long, long);\n                      ^\n<built-in>:2965:23: note: candidate function\nuint __OVERLOADABLE__ rotate(uint, uint);\n                      ^\n<built-in>:2964:22: note: candidate function\nint __OVERLOADABLE__ rotate(int, int);\n                     ^\n<built-in>:2963:25: note: candidate function\nushort __OVERLOADABLE__ rotate(ushort, ushort);\n                        ^\n<built-in>:2962:24: note: candidate function\nshort __OVERLOADABLE__ rotate(short, short);\n                       ^\n<built-in>:2961:24: note: candidate function\nuchar __OVERLOADABLE__ rotate(uchar, uchar);\n                       ^\n<built-in>:2960:23: note: candidate function\nchar __OVERLOADABLE__ rotate(char, char);\n                      ^"],["t","Edit : I just see the rot function in poclbm.py (the one m0mchil was talking in fact I gess), I will try to see how to change the two rot functions, and perhaps bytereverse in btc_miner. cl ?\n\nEdit2 : pfiuuu, it's hard !\nfirst time I work on python and therefore on pyopencl, and using the nvidia toolkit. I don't even know from where the rotate functions come (the candidates functions), where are they defined (nividia toolkit, boost, standard c++, ... and from which include) ?\n\nEdit3 : ...\nI made some tries, and I don't succed for now:"],["c","Traceback (most recent call last):\n  File \"poclbm.py\", line 57, in <module>\n    miner = cl.Program(context, kernelFile.read()).build()\n  File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 138, in program_build\n    \"Build on %s:%s\" % (dev, log) for dev, log in build_logs))\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 9800 GT' at 0x2312eb8>:\n\nError: Code selection failed to select: 0x527c7f8: i32 = bswap 0x527cbb0"],["t","... I have no idea of what that means  Grin\n\n(for this test I just change #define rot(x, y) rotate(x, (uint)y) to #define rot(x, y) rotate(x, (uint2)y) in btc_miner.cl, trying to make it running first before checking the operations made).\n\nEdit 4 :\na \"funny\" thing, the problem I have come from the end of the function search in btc_miner.cl\n\nIf I remove those lines"],["c","    if((H.x==0) && (bytereverse(G.x)<=target))\n    {\n        output[0] = 1;\n        output[1] = nonce.x;\n    }\n\n    if((H.y==0) && (bytereverse(G.y)<=target))\n    {\n        output[0] = 1;\n        output[1] = nonce.y;\n    }"],["t","the script is built without error and start.\n\nIf I leave the tests without output[n] = ... it builds, and if I leave output[n] = ... without the tests, it builds also.\nbut if I put the test and output[n] = ... I have the following error :"],["c","Traceback (most recent call last):\n  File \"poclbm.py\", line 57, in <module>\n    miner = cl.Program(context, kernelFile.read()).build()\n  File \"E:\\Python26\\lib\\site-packages\\pyopencl-0.92-py2.6-win32.egg\\pyopencl\\__init__.py\", line 138, in program_build\n    \"Build on %s:%s\" % (dev, log) for dev, log in build_logs))\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce 9800 GT' at 0x2952eb8>:\n\nError: Code selection failed to select: 0x4f5a8d0: i32 = bswap 0x4f94670"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17334#msg17334","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287378681,"b":[["t","Jef, at least it's now clear the problem is in the bytereverse(x) macro. Please try to replace it with:\n\nuint bytereverse(const uint x)\n{\n   uint result;\n   uchar* b = (uchar *)&x;\n   uchar* l = (uchar *)&result;\n   l[0] = b[3];\n   l[1] = b[2];\n   l[2] = b[1];\n   l[3] = b[0];\n   return result;\n}"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17456#msg17456","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287425014,"b":[["t","Hello again, thanks for the code  Smiley\n\nbut it still doesn't work  Sad\nNvidia doesn't like reversing numbers it seems  Angry\nhowever, if I comments anyone of the four affectations, it builds  Grin\n\nAfter trying by decomposing the reversing in many ways, I abandoned this path to bypass the problem.\n\nI made a first version running with byte reversing and comparaisons made in the python script, and a second version with a function that make the comparison directly between a word and a reversed word in the OpenCl code. For now this version works only on big endian memory mapping (I hope it's what is used in the GPUs).\n\nNote: I added somme print to the screen to show some informations when running the script.\nI also let some comments in the code.\n\nThe two versions build and run without error, but I'm not sure that operations are correct.\nAs expected the second version is more effective (about 14800 khashs/sec with the 1st version, and 15200 khashs/sec with the 2nd version).\n\nVersion 1 : reversing and comparison in the python script"],["c","--- F:/Desktop/m0mchil-poclbm-cf33815/poclbm.py    Fri Oct 15 08:48:48 2010\n+++ F:/Desktop/m0mchil-poclbm-cf33815/poclbm_nv1.py    Mon Oct 18 23:36:46 2010\n@@ -21,6 +21,9 @@\n     t2=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b)))\n     return (uint32(d + t1), uint32(t1+t2))\n \n+def bytereverse(x):\n+    return (((x & 0x000000ffL) << 24) | ((x & 0x0000ff00L) << 8) | ((x & 0x00ff0000L) >> 8) | ((x & 0xff000000L) >> 24))\n+\n def sysWrite(format, args=()):\n     sys.stdout.write('\r                                        \r' + format % args)\n     sys.stdout.flush()\n@@ -50,16 +53,40 @@\n     context = cl.Context([devices[options.device]], None, None)\n else:\n     print 'No device specified, you may use -d to specify one of the following'\n+    # create_some_context should ask for the platform and device to use\n     context = cl.create_some_context()\n+\n+device = context.devices[0]\n+print \"===============================================================\"\n+print \"Platform name:\", platform.name\n+print \"Platform profile:\", platform.profile\n+print \"Platform vendor:\", platform.vendor\n+print \"Platform version:\", platform.version\n+print \"---------------------------------------------------------------\"\n+print \"Device name:\", device.name\n+print \"Device type:\", cl.device_type.to_string(device.type)\n+print \"Device memory: \", device.global_mem_size//1024//1024, 'MB'\n+print \"Device max clock speed:\", device.max_clock_frequency, 'MHz'\n+print \"Device compute units:\", device.max_compute_units\n+print \"===============================================================\"\n+\n queue = cl.CommandQueue(context)\n \n-kernelFile = open('btc_miner.cl', 'r')\n+kernelFile = open('btc_miner_nv1.cl', 'r')\n miner = cl.Program(context, kernelFile.read()).build()\n kernelFile.close()\n \n+print \"===============================================================\"\n+print \"build OK\"\n+print \"===============================================================\"\n+\n if (options.worksize == -1):\n     options.worksize = miner.search.get_work_group_info(cl.kernel_work_group_info.WORK_GROUP_SIZE, context.devices[0])\n \n+print \"===============================================================\"\n+print \"worksize = \", options.worksize\n+print \"===============================================================\"\n+\n frames = options.frames\n frame = float(1)/frames\n window = frame/30\n@@ -75,7 +102,7 @@\n work['extraNonce'] = 0\n work['block'] = ''\n \n-output = np.zeros(2, np.uint32)\n+output = np.zeros(6, np.uint32)\n \n while True:\n     try:\n@@ -117,10 +144,12 @@\n     output_buf = cl.Buffer(context, mf.WRITE_ONLY | mf.USE_HOST_PTR, hostbuf=output)\n \n     rate = start = time()\n+    success = 0\n+    nonce = 0\n     while True:\n-        if (output[0]):\n-            work['block'] = work['block'][:152] + pack('I', long(output[1])).encode('hex') + work['block'][160:]\n-            sysWriteLn('found: %s, %s', (output[1], datetime.now().strftime(\"%d/%m/%Y %H:%M\")))\n+        if (success):\n+            work['block'] = work['block'][:152] + pack('I', long(nonce)).encode('hex') + work['block'][160:]\n+            sysWriteLn('found: %s, %s', (nonce, datetime.now().strftime(\"%d/%m/%Y %H:%M\")))\n             break\n \n         if (time() - start > options.askrate or base + globalThreads == 0x7FFFFFFF):\n@@ -131,8 +160,20 @@\n             base = 0x7FFFFFFF - globalThreads\n \n         kernelStart = time()\n-        miner.search(queue, (globalThreads, ), (options.worksize, ), block2[0], block2[1], block2[2], state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7], state2[1], state2[2], state2[3], state2[5], state2[6], state2[7], target[6], pack('I', base), output_buf)\n+        miner.search(queue, (globalThreads, ), (options.worksize, ), block2[0], block2[1], block2[2], state[0], state[1], state[2], state[3], state[4], state[5], state[6], state[7], state2[1], state2[2], state2[3], state2[5], state2[6], state2[7], pack('I', base), output_buf)\n         cl.enqueue_read_buffer(queue, output_buf, output).wait()\n+        #target = target[6]\n+        #H.x = output[0] ; H.y = output[1]\n+        #G.x = output[2] ; G.y = output[3]\n+        #nonce.x = output[4] ; nonce.y = output[5]\n+        if (output[0] == 0 and bytereverse(output[2])<=target[6]):\n+            success = 1\n+            nonce = output[4]\n+       \n+        if (output[1] == 0 and bytereverse(output[3])<=target[6]):\n+            success = 1\n+            nonce = output[5]\n+       \n         kernelTime = time() - kernelStart\n \n         if (kernelTime < lower):\n@@ -142,4 +183,4 @@\n \n         if (time() - rate > options.rate):\n             rate = time()\n-            sysWrite('%s khash/s', int((base / (time() - start)) / 500))\n\\ No newline at end of file\n+            sysWrite('%s : %s khash/s', (datetime.now().strftime(\"%d/%m/%Y %H:%M:%S\"),int((base / (time() - start)) / 500)))\n\\ No newline at end of file"],["c","--- F:/Desktop/m0mchil-poclbm-cf33815/btc_miner.cl    Fri Oct 15 08:48:48 2010\n+++ F:/Desktop/m0mchil-poclbm-cf33815/btc_miner_nv1.cl    Mon Oct 18 22:01:08 2010\n@@ -1,5 +1,4 @@\n-#define bytereverse(x) ( ((x) << 24) | (((x) << 8) & 0x00ff0000) | (((x) >> 8) & 0x0000ff00) | ((x) >> 24) )\n-#define rot(x, y) rotate(x, (uint)y)\n+#define rot(x, y) rotate(x, (uint2)y)\n #define R(x) (work[x] = (rot(work[x-2],15)^rot(work[x-2],13)^((work[x-2])>>10)) + work[x-7] + (rot(work[x-15],25)^rot(work[x-15],14)^((work[x-15])>>3)) + work[x-16])\n #define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}\n \n@@ -8,7 +7,6 @@\n                         const uint state4, const uint state5, const uint state6, const uint state7,\n                         const uint B1, const uint C1, const uint D1,\n                         const uint F1, const uint G1, const uint H1,\n-                        const uint target,\n                         const uint base,\n                         __global uint * output)\n {\n@@ -209,17 +207,12 @@\n     G+=0x1f83d9ab;\n     H+=0x5be0cd19;\n \n-    if((H.x==0) && (bytereverse(G.x)<=target))\n-    {\n-        output[0] = 1;\n-        output[1] = nonce.x;\n-    }\n-\n-    if((H.y==0) && (bytereverse(G.y)<=target))\n-    {\n-        output[0] = 1;\n-        output[1] = nonce.y;\n-    }\n+    output[0] = H.x;\n+    output[1] = H.y;\n+    output[2] = G.x;\n+    output[3] = G.y;\n+    output[4] = nonce.x;\n+    output[5] = nonce.y;\n }\n \n // end\n\\ No newline at end of file"],["t","Version 2 : function that make the comparison between inversed and non inversed word"],["c","--- F:/Desktop/m0mchil-poclbm-cf33815/poclbm.py    Fri Oct 15 08:48:48 2010\n+++ F:/Desktop/m0mchil-poclbm-cf33815/poclbm_nv2.py    Mon Oct 18 23:53:18 2010\n@@ -50,16 +50,40 @@\n     context = cl.Context([devices[options.device]], None, None)\n else:\n     print 'No device specified, you may use -d to specify one of the following'\n+    # create_some_context should ask for the platform and device to use\n     context = cl.create_some_context()\n+\n+device = context.devices[0]\n+print \"===============================================================\"\n+print \"Platform name:\", platform.name\n+print \"Platform profile:\", platform.profile\n+print \"Platform vendor:\", platform.vendor\n+print \"Platform version:\", platform.version\n+print \"---------------------------------------------------------------\"\n+print \"Device name:\", device.name\n+print \"Device type:\", cl.device_type.to_string(device.type)\n+print \"Device memory: \", device.global_mem_size//1024//1024, 'MB'\n+print \"Device max clock speed:\", device.max_clock_frequency, 'MHz'\n+print \"Device compute units:\", device.max_compute_units\n+print \"===============================================================\"\n+\n queue = cl.CommandQueue(context)\n \n-kernelFile = open('btc_miner.cl', 'r')\n+kernelFile = open('btc_miner_nv2.cl', 'r')\n miner = cl.Program(context, kernelFile.read()).build()\n kernelFile.close()\n \n+print \"===============================================================\"\n+print \"build OK\"\n+print \"===============================================================\"\n+\n if (options.worksize == -1):\n     options.worksize = miner.search.get_work_group_info(cl.kernel_work_group_info.WORK_GROUP_SIZE, context.devices[0])\n \n+print \"===============================================================\"\n+print \"worksize = \", options.worksize\n+print \"===============================================================\"\n+\n frames = options.frames\n frame = float(1)/frames\n window = frame/30\n@@ -142,4 +166,4 @@\n \n         if (time() - rate > options.rate):\n             rate = time()\n-            sysWrite('%s khash/s', int((base / (time() - start)) / 500))\n\\ No newline at end of file\n+            sysWrite('%s : %s khash/s', (datetime.now().strftime(\"%d/%m/%Y %H:%M:%S\"),int((base / (time() - start)) / 500)))\n\\ No newline at end of file"],["c","--- F:/Desktop/m0mchil-poclbm-cf33815/btc_miner.cl    Fri Oct 15 08:48:48 2010\n+++ F:/Desktop/m0mchil-poclbm-cf33815/btc_miner_nv2.cl    Mon Oct 18 23:33:50 2010\n@@ -1,8 +1,88 @@\n-#define bytereverse(x) ( ((x) << 24) | (((x) << 8) & 0x00ff0000) | (((x) >> 8) & 0x0000ff00) | ((x) >> 24) )\n-#define rot(x, y) rotate(x, (uint)y)\n+#define rot(x, y) rotate(x, (uint2)y)\n #define R(x) (work[x] = (rot(work[x-2],15)^rot(work[x-2],13)^((work[x-2])>>10)) + work[x-7] + (rot(work[x-15],25)^rot(work[x-15],14)^((work[x-15])>>3)) + work[x-16])\n #define sharound(a,b,c,d,e,f,g,h,x,K) {h=(h+(rot(e, 26)^rot(e, 21)^rot(e, 7))+(g^(e&(f^g)))+K+x); t1=(rot(a, 30)^rot(a, 19)^rot(a, 10))+((a&b)|(c&(a|b))); d+=h; h+=t1;}\n \n+// test 1 : recursive function, build error :\n+// Error: Code selection failed to select: 0x504c1d8: i8 = NVPTXISD::MoveParam 0x504c150\n+/*\n+bool recurseReversedCompare(uchar *reversed, uchar *normal, uchar ir, uchar in)\n+{\n+    if(reversed[ir] > normal[in])\n+    {\n+        return false;\n+    }\n+    else if(reversed[ir] < normal[in])\n+    {\n+        return true;\n+    }\n+    else if(in > 0)\n+    {\n+        return recurseReversedCompare(reversed, normal, ir+1, in-1);\n+    }\n+    else\n+    {\n+        return true;\n+    }\n+}\n+\n+bool reversedSmallerThan(uint reversed, uint normal)\n+{\n+    uchar *r = (uchar *)&reversed;\n+    uchar *n = (uchar *)&normal;\n+\n+    return recurseReversedCompare(r, n, 0, 3);\n+}\n+*/\n+\n+// test 2 : non recursive\n+bool reversedSmallerThan(uint reversed, uint normal)\n+{\n+    uchar *r = (uchar *)&reversed;\n+    uchar *n = (uchar *)&normal;\n+\n+    if(r[0] > n[3])\n+    {\n+        return false;\n+    }\n+    else if(r[0] < n[3])\n+    {\n+        return true;\n+    }\n+    else\n+    {\n+        if(r[1] > n[2])\n+        {\n+            return false;\n+        }\n+        else if(r[1] < n[2])\n+        {\n+            return true;\n+        }\n+        else\n+        {\n+            if(r[2] > n[1])\n+            {\n+                return false;\n+            }\n+            else if(r[2] < n[1])\n+            {\n+                return true;\n+            }\n+            else\n+            {\n+                if(r[3] > n[0])\n+                {\n+                    return false;\n+                }\n+                else\n+                {\n+                    return true;\n+                }\n+            }\n+        }\n+    }\n+}\n+\n __kernel void search(    const uint block0, const uint block1, const uint block2,\n                         const uint state0, const uint state1, const uint state2, const uint state3,\n                         const uint state4, const uint state5, const uint state6, const uint state7,\n@@ -209,13 +289,13 @@\n     G+=0x1f83d9ab;\n     H+=0x5be0cd19;\n \n-    if((H.x==0) && (bytereverse(G.x)<=target))\n+    if((H.x==0) && reversedSmallerThan(G.x, target)) // (bytereverse(G.x)<=target)\n     {\n         output[0] = 1;\n         output[1] = nonce.x;\n     }\n \n-    if((H.y==0) && (bytereverse(G.y)<=target))\n+    if((H.y==0) && reversedSmallerThan(G.y, target)) // (bytereverse(G.y)<=target)\n     {\n         output[0] = 1;\n         output[1] = nonce.y;"],["t","There are probably some optimisations to make Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17530#msg17530","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287500094,"b":[["t","Thanks Jef! There is new version that should work on Nvidia now. I also changed default getwork request rate to 5 seconds to reduce the risk of solving stale block. The patch itself has now one more check to not show 'proof of work found' in this case.\n\nCan someone with Nvidia please test this, it should resolve the 'code selection failed to select' issue."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17621#msg17621","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287505631,"b":[["t","you’re welcome  Smiley\nThank you for your better code design than mine Grin\n\nThe new code you provided runs on my computer."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17626#msg17626","sj":"Re: OpenCL miner for the masses"},{"f":"sandos","d":1287520141,"b":[["q","you’re welcome  Smiley\n\nThe new code you provided runs on my computer.","Quote from: jef.blanc on October 19, 2010, 04:27:11 PM"],["t","OpenCL-wise it seems to work fine on my 9400 GT, now I just have trouble compiling bitcoind Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17659#msg17659","sj":"Re: OpenCL miner for the masses"},{"f":"sandos","d":1287523135,"b":[["q","> Quote from: jef.blanc on October 19, 2010, 04:27:11 PM\n> you’re welcome  Smiley\n>\n> The new code you provided runs on my computer.\n\nOpenCL-wise it seems to work fine on my 9400 GT, now I just have trouble compiling bitcoind Smiley","Quote from: sandos on October 19, 2010, 08:29:01 PM"],["t","Ah, it worked it was just using another port.\n\nI knew the 9400 GT would be slow relative to other cards, but maybe not this slow: I get 1800kh/s, which is slower than my cpu =)\n\nI was hoping to maybe double performance, but oh well."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17668#msg17668","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287561450,"b":[["t","Only 1800kh/s ? It seems very low in comparison to my 9800 GT which give me about 15200 kh/s\n\nPerhaps for some strange reason your GPU is not fully used, if your graphical card gives you this information you can check the GPU load with GPU-Z, in the \"Sensors\" tab (http://www.techpowerup.com/gpuz/)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17723#msg17723","sj":"Re: OpenCL miner for the masses"},{"f":"ArtForz","d":1287586481,"b":[["t","9400GT 16SPs @ 1.4GHz\n9800GT 112SPs @ 1.5GHz\n-> a 9800GT is about 7.5x 9400GT ..."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17785#msg17785","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287598103,"b":[["t","ah ... yes, I didn't check that before talking  Embarrassed\n1800 * 7.5 = 13500 ... no so far than my 15200 ... logical then in fact."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17795#msg17795","sj":"Re: OpenCL miner for the masses"},{"f":"Guybrush01","d":1287626315,"b":[["t","Hi there!\n\nTrying to use this, but here is the error I see:"],["c","D:\\pycuda>poclbm.exe\nNo device specified, you may use -d to specify one of the following\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 58, in <module>\n  File \"pyopencl\\__init__.pyc\", line 138, in program_build\npyopencl.RuntimeError: clBuildProgram failed: build program failure\n\nBuild on <pyopencl.Device 'GeForce GTX 470' at 0x2d112d8>:\n\n:52: error: incompatible type assigning 'int', expected 'uint2'\n        work[5]=0x00000000;\n               ^~~~~~~~~~~\n:53: error: incompatible type assigning 'int', expected 'uint2'\n        work[6]=0x00000000;\n               ^~~~~~~~~~~\n:54: error: incompatible type assigning 'int', expected 'uint2'\n        work[7]=0x00000000;\n               ^~~~~~~~~~~\n:55: error: incompatible type assigning 'int', expected 'uint2'\n        work[8]=0x00000000;\n               ^~~~~~~~~~~\n:56: error: incompatible type assigning 'int', expected 'uint2'\n        work[9]=0x00000000;\n               ^~~~~~~~~~~\n:57: error: incompatible type assigning 'int', expected 'uint2'\n        work[10]=0x00000000;\n                ^~~~~~~~~~~\n:58: error: incompatible type assigning 'int', expected 'uint2'\n        work[11]=0x00000000;\n                ^~~~~~~~~~~\n:59: error: incompatible type assigning 'int', expected 'uint2'\n        work[12]=0x00000000;\n                ^~~~~~~~~~~\n:60: error: incompatible type assigning 'int', expected 'uint2'\n        work[13]=0x00000000;\n                ^~~~~~~~~~~\n:61: error: incompatible type assigning 'int', expected 'uint2'\n        work[14]=0x00000000;\n                ^~~~~~~~~~~\n:62: error: incompatible type assigning 'int', expected 'uint2'\n        work[15]=0x00000280;\n                ^~~~~~~~~~~\n:141: error: incompatible type assigning 'int', expected 'uint2'\n        work[9]=0x00000000;\n               ^~~~~~~~~~~\n:142: error: incompatible type assigning 'int', expected 'uint2'\n        work[10]=0x00000000;\n                ^~~~~~~~~~~\n:143: error: incompatible type assigning 'int', expected 'uint2'\n        work[11]=0x00000000;\n                ^~~~~~~~~~~\n:144: error: incompatible type assigning 'int', expected 'uint2'\n        work[12]=0x00000000;\n                ^~~~~~~~~~~\n:145: error: incompatible type assigning 'int', expected 'uint2'\n        work[13]=0x00000000;\n                ^~~~~~~~~~~\n:146: error: incompatible type assigning 'int', expected 'uint2'\n        work[14]=0x00000000;\n                ^~~~~~~~~~~\n:147: error: incompatible type assigning 'int', expected 'uint2'\n        work[15]=0x00000100;\n                ^~~~~~~~~~~\n:149: error: incompatible type assigning 'int', expected 'uint2'\n        A=0x6a09e667;\n         ^~~~~~~~~~~\n:151: error: incompatible type assigning 'int', expected 'uint2'\n        C=0x3c6ef372;\n         ^~~~~~~~~~~\n:153: error: incompatible type assigning 'int', expected 'uint2'\n        E=0x510e527f;\n         ^~~~~~~~~~~\n:155: error: incompatible type assigning 'int', expected 'uint2'\n        G=0x1f83d9ab;\n         ^~~~~~~~~~~\n:156: error: incompatible type assigning 'int', expected 'uint2'\n        H=0x5be0cd19;"],["t","Wish I were smart enough to understand what that means!\n\nAny ideas?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17839#msg17839","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287645386,"b":[["t","Hello, it is the errors I had when running poclbm from poclbm_py2exe.7z with the original OpenCL.dll inside.\n\nThe 7z archive contains the dll from the ATI driver, so using an nvidia card I had to replace this dll by the one provided by my nvidia driver which is in C:\\Windows\\System32\\\n\nIs it your case, executing poclbm from the package poclbm_py2exe.7z ?\n\nThe things I had to do for using poclbm :\n- building pyopencl for my system, I installed the latest CUDA Toolkit from here http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 to build pyopencl.\n- using the latest driver (Developer Drivers) from here http://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html#Windows%20XP,%20Windows%20Vista%20and%20Windows7 , I had the following errors without that :"],["c","ImportError: DLL load failed: La procÚdure spÚcifiÚe est introuvable."],["t","- using the latest version of poclbm from http://github.com/m0mchil/poclbm , a correction has been made to make poclbm running on nvidia GPU without errors"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17864#msg17864","sj":"Re: OpenCL miner for the masses"},{"f":"LZ","d":1287649369,"b":[["t","Can someone give direct links to NVIDIA OpenCL 1.1 drivers <https://web.archive.org/web/2009/http://developer.nvidia.com/object/opencl.html>?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17866#msg17866","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287656967,"b":[["q","Can someone give direct links to NVIDIA OpenCL 1.1 drivers <http://developer.nvidia.com/object/opencl.html>?","Quote from: lzsaver on October 21, 2010, 08:22:49 AM"],["t","I didn't success to found a link to this driver (and I found two cd iso on bittorent, but I don't try to get them) ...\n\nBut Nvidia has apparently merge his OpenCL implementation in his CUDA Toolkit and drivers. The latest \"Developer Drivers\" from the \"CUDA Toolkit 3.2 RC\" page contains an OpenCL 1.1 compliant* driver (it is the one I use).\n\n*at least concerning the openCL 1.1 functions needed by pyopencl\n\nhttp://developer.nvidia.com/object/cuda_3_2_toolkit_rc.html\nScroll down in the page to found the drivers for windows, linux (some distributions), and MacOS)\n\nNote : GPU Caps Viewer shows me OpenCL 1.0, but it works anyway."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17878#msg17878","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287668740,"b":[["t","bitcoin-getwork-svn170-win32.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/bitcoin-getwork-svn170-win32.7z>\n\npoclbm_win32_exe.7z <http://github.com/downloads/m0mchil/poclbm/poclbm_win32_exe.7z> Wrong kernel was packed in the py2exe version, now fixed. Removed AMD OpenCL.dll to prevent conflicts.\n\nI also reverted back to scalars. With vectors it was faster, but required hardware specific tweaks and was making it slower for others. Unfortunately OpenCL is not mature enough to provide means of automatic performance optimization."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17908#msg17908","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1287673333,"b":[["t","seems to work now on my GTX260\n\nhashcount results are similar to puddinpops cuda-code,\nboth get around 45Mhash/s."],["c","C:\\Documents and Settings\\Administrator\\Desktop\\bitcoin_stuff\\OpenCL\\poclbm_win3\n2_exe>poclbm --user=*** --pass=***\nNo device specified, you may use -d to specify one of the following\n\n44120 khash/s"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17915#msg17915","sj":"Re: OpenCL miner for the masses"},{"f":"kwukduck","d":1287680302,"b":[["t","I'm not sure if and whats going wrong, i started bitcoin in server mode. start poclbm with user and pass, then it shows khash/s for about 5 seconds then pops back to asking username and pass. i can keep doing that over and over."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17926#msg17926","sj":"Re: OpenCL miner for the masses"},{"f":"kwukduck","d":1287692151,"b":[["t","tnx, working fine now, forgot the username.\n\nOn my other pc i get this error \"ImportError: DLL load failed: The specified module could not be found.\"\n\nI already updated to latest graphics drivers and nvidia cuda toolkit..\n\nGeforce 9800 GX2 @ win7 32 bit\n\ni also noticed that the old puddingpop cuda client only puts out 2000khash/s on that gpu... i should get at least ten times as much...\n\nany ideas?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17939#msg17939","sj":"Re: OpenCL miner for the masses"},{"f":"jef.blanc","d":1287693798,"b":[["t","hum, you can check with dependency walker (http://www.dependencywalker.com/) that your OpenCL.dll file (in C:\\Windows\\System32\\) provides the OpenCL 1.1 functions needed by pyopencl :\n\nclCreateSubBuffer\nclCreateUserEvent\nclEnqueueCopyBufferRect\nclEnqueueReadBufferRect\nclEnqueueWriteBufferRect\nclSetUserEventStatus\n\nIf not, then either the driver installation has failed, or it is not the good driver.\nOtherwise ... I don't know  Huh\n\nEdit : you can check with GPU Caps Viewer if this GPU really manage OpenCL, because 2000 kh/s is what is currently made by the CPU alone.\nThe Geforce 9800 GX2 is if I'm rigth two 8800 GTX functionning in pair, not sure that they manage OpenCL."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg17943#msg17943","sj":"Re: OpenCL miner for the masses"},{"f":"gim","d":1287742578,"b":[["t","Hi,\n\nFirst, thanks for this wonderful miner.\nI managed to make it work on linux (lib64 only) with a 8600 GT\n(A bit disappointed about my card performance though: 5300kh/s)"],["q",":52: error: incompatible type assigning 'int', expected 'uint2'\n        work[5]=0x00000000;\n               ^~~~~~~~~~~\nAny ideas?","Quote from: Guybrush01 on October 21, 2010, 01:58:35 AM"],["t","Got this error too, just put some \"u\"s at the end of all these uint constants. Example:"],["c","        work[5]=0x00000000u;"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18038#msg18038","sj":"Re: OpenCL miner for the masses"},{"f":"L29Ah","d":1287823864,"b":[["t","Just pulled a fresh version and got this:\n\n$ python2.6 poclbm.py -u l29ah --pass=hackme\nNo device specified, you may use -d to specify one of the following\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 133, in <module>\n    target[6], pack('I', base), output_buf)\n  File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call\n    self.set_arg(i, arg)\nTypeError: expected a readable buffer object"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18159#msg18159","sj":"Re: OpenCL miner for the masses"},{"f":"gim","d":1287828053,"b":[["q","  File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call\n    self.set_arg(i, arg)\nTypeError: expected a readable buffer object","Quote from: L29Ah on October 23, 2010, 08:51:04 AM"],["t","Upgrade to pyopencl-0.92."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18166#msg18166","sj":"Re: OpenCL miner for the masses"},{"f":"L29Ah","d":1287828567,"b":[["q","> Quote from: L29Ah on October 23, 2010, 08:51:04 AM\n>   File \"/usr/lib64/python2.6/site-packages/pyopencl/__init__.py\", line 158, in kernel_call\n>     self.set_arg(i, arg)\n> TypeError: expected a readable buffer object\n\nUpgrade to pyopencl-0.92.","Quote from: gim on October 23, 2010, 10:00:53 AM"],["t","Thank you! Getting 31MH/s from GeForce 9800 GTX if run with -f 10."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18168#msg18168","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287840555,"b":[["t","It finally work on my side !\nWithout optimisation, I got around 265000 khash/sec. I got an i7 920 oc to 3.6ghz with a radeon 5970. I'm gonna look to do some tweak to speed up this thing a bit Wink If you have any comment or something you want me to try don't hesitate. By the way, I've been running this thing tonight, and in 8 hours, my wallet is still at 0. Is it normal ? Do I need to restart it? Or it's just like the way it should work, which mean it's still pretty long to generate? Thanks for your OpenCL gui Moo, I really appreciate it !\n\nMalouin\n\nP-S I think I only got 265000 khash/sec on my 5970 because i'm only using 1 heart. When I'm at the point I need to choose the device, I see 3 option, 0 = my cpu, and 1 and 2 is the same thing. is it possible ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18183#msg18183","sj":"Re: OpenCL miner for the masses"},{"f":"LZ","d":1287841154,"b":[["t","265 mhps? Shocked"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18186#msg18186","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287841650,"b":[["t","Yes, just took you a screenshot\n\nhttp://static/img835.imageshack.us/static/img835/2157/bitcoin.jpg\n\nI'm pretty sure I can get the 500 by using my 2 heart, or maybe i'm totally wrong XD\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18187#msg18187","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287844276,"b":[["t","The 4 that you see was just after I finished installing it. It was still downloading block. About the public or the test, I supose i'm on the public network. I simply did the bitcoin -server, and started the poclbm. While I was reading, I heard about a shared pool. Is it really that good ? If you have any info you can help me don't hesitate, I'm open to anything =) Btw i'm on irc ( Malouin ) presently if you wanna talk !\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18195#msg18195","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287845637,"b":[["t","I see\n\nThanks for the info and for the help david, I really appreciate it. If you want me to do some test or help you on something, don't hesitate.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18198#msg18198","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287852212,"b":[["t","The miner should display 'bitcoin is downloading blocks...' until all blocks are downloaded. Please test. This was added in the SVN 163 patched client.\n\nDavid, I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18218#msg18218","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1287853166,"b":[["t","From now on I'll post latest versions only in the initial post of this thread."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18224#msg18224","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287856260,"b":[["t","Tried the -f 35 and -w 128. I get around 270m khash/s. And yes, I can load 2 separate poclbm, using device 1 and device 2, both are doing around 268m khash/s. Total of 536m khash/s.\n\nAnd yes, it display the bitcoin is downloading blocks... Thanks !\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18229#msg18229","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287860257,"b":[["t","Update : I Oc'ed my 5970 GPU clock from 725 MHZ to 800 MHZ and my memory clock from 1000 to 1305MHZ.\n\nI'm now at 295m on each heart, total of 590m. Everything seem to be fine, I will let you know about futur update and how much I can get with the 5970.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18247#msg18247","sj":"Re: OpenCL miner for the masses"},{"f":"LZ","d":1287868868,"b":[["t","590 mhps!!! Shocked Shocked Shocked"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18260#msg18260","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287891119,"b":[["t","hehehe thanks guys =P\n\nI was speaking with Art on irc today, and my next step will be to OC my 5970 from 800 to 910mhz. I should reach the 320mhash/s on each heart, which mean a big total of 640mhash/s.\n\nI restarted my client at 15h30 EAST time, and will stop it tomorrow at the same time. It gonna give me some data to work on. After that, i'm going to OC it at 910mhz and see the result and report here with some screenshots.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18279#msg18279","sj":"Re: OpenCL miner for the masses"},{"f":"bethel","d":1287903755,"b":[["q","bethel, what are 5870s showing at stock frequency (850 MHz)? Perhaps one of the cards throttles down?\n\nLatest version has new parameter, -w, to set work group size. I have best results on 5770 with -w 128 -f 35.\n\nLatest py2exe version is http://github.com/downloads/m0mchil/poclbm/poclbm.7z","Quote from: m0mchil on October 16, 2010, 07:08:11 AM"],["t","Sorry for the late reply, I have been away for a while.\n\nI found my problem and it was so simple it is silly. I had not yet enabled the -frames switch to crunch faster. I still don't know why one card was faster without the switch but they are about equal now.\n\nAs for the mhash @ 850mhz I get about 265mhps."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18297#msg18297","sj":"Re: OpenCL miner for the masses"},{"f":"bethel","d":1287903904,"b":[["q","Tried the -f 35 and -w 128. I get around 270m khash/s. And yes, I can load 2 separate poclbm, using device 1 and device 2, both are doing around 268m khash/s. Total of 536m khash/s.\n\nAnd yes, it display the bitcoin is downloading blocks... Thanks !\n\nMalouin","Quote from: xxmalouinxx on October 23, 2010, 05:51:00 PM"],["t","xxmalouinxx, what OS, SDK, and driver version are you on?\n\nI can't seem to get my two cards to both run at the same time under Windows 7. Any hints?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18298#msg18298","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287920865,"b":[["t","Windows 7 Ultimate / ATI SDK 2.2 for Win7 64 / Catalyst 10.7\n\nI got a radeon 5970, so I don't have 2 cards, but 2 hearts on it. Art got 4 cards on 1 motherboard doing this, I'm gonna ask him when I see him.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18317#msg18317","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1287953527,"b":[["t","Update :\n\nHere's a screenshot of my last setting\n\nhttp://static/img143.imageshack.us/static/img143/2157/bitcoin.jpg\n\n640mhash/s - radeon 5970 870mhz/1305mhz - temp : 83c\n\nPresently it run fine, but i'm not sure it gonna be stable, gonna update here if I have any news.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18363#msg18363","sj":"Re: OpenCL miner for the masses"},{"f":"LZ","d":1287998579,"b":[["t","I want it! Grin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18451#msg18451","sj":"Re: OpenCL miner for the masses"},{"f":"davout","d":1288002294,"b":[["t","incredible hashes/sec are incredible\ndo you think a Radeon 5970 would work fine with linux ?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18459#msg18459","sj":"Re: OpenCL miner for the masses"},{"f":"fergalish","d":1288003672,"b":[["t","core i7 quad, nvidia GT240, 64bit ubuntu 10.04\n\nCPU: 7000 khps\nGPU: 20000 khps\n\nShould I be getting more?  I have python 2.6.5 installed."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18460#msg18460","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1288005049,"b":[["t","Davout : Yea it should work without any problem on linux. ArtForz actually use that.\n\nFergalish : the Nvidia GT240 got 385 Gflops, the radeon 5970 got 4640. If we base it on the fact that the 5970 got 230 000khash/s per core without being OC, it should be around 20 000 khash/s yes.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18466#msg18466","sj":"Re: OpenCL miner for the masses"},{"f":"sturle","d":1288009149,"b":[["t","Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?"],["c","  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           \n 4885 sturle    20   0  420m  56m  26m S  264  0.7  53:15.06 bitcoin           \n 5522 sturle    20   0  231m  63m  24m S   97  0.8   9:44.01 poclbm.py         \n14130 root      20   0  491m 174m 122m S   27  2.2  12:25.19 Xorg               "],["t","I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores.  While poclbm.py is running, hash production from bitcoin is reduced to about 8k.  Is this normal?  Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.\n\nGPU is some ATI HD 5400 series."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18469#msg18469","sj":"Re: OpenCL miner for the masses"},{"f":"davout","d":1288009552,"b":[["t","I think it's a really good thing that such a client gets public, it decreases the chance that the blockchain gets overtaken by NSA XD"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18471#msg18471","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288031512,"b":[["q","core i7 quad, nvidia GT240, 64bit ubuntu 10.04\n\nCPU: 7000 khps\nGPU: 20000 khps\n\nShould I be getting more?  I have python 2.6.5 installed.","Quote from: fergalish on October 25, 2010, 10:47:52 AM"],["t","compared to my GTX260 which gets ~37.000 stock (575core/1240shader) and up to 45.000 oc'd (685/1480),\nyou should be ok with 20.000.\n\ngonna run it on a radeon 5850 as soon as it arrives, should be by tomorrow.\nhopefully i'll get some more outof that."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18514#msg18514","sj":"Re: OpenCL miner for the masses"},{"f":"bethel","d":1288048217,"b":[["q","640mhash/s - radeon 5970 870mhz/1305mhz - temp : 83c\n\nPresently it run fine, but i'm not sure it gonna be stable, gonna update here if I have any news.\n\nMalouin","Quote from: xxmalouinxx on October 24, 2010, 08:52:07 PM"],["t","What are your -frames and -worksize arguments like? Also what -askrate interval do you have?\n\nI did get two cards working (had to use the crossfirex cable and enable crossfirex).\n\nThe thing that baffles me is how to get the same performance out of two cards together as I got out of two cards seperately. It seems if i set the frames very low like -frames=2 I can get one card to do about 97% gpu capacity. The other card, however drops to 60-80%. When I make the frames high like 256 it does ok but any other program on my machine seems to have a higher priority and will make poclbm.exe run slow.\n\nCurrently the best compromise I found was\n--frames=25 --rate=3 --worksize=256 --device=1 --askrate=30\n\nOn a single core processor machine this produces about 90% on each card average but has wild swings.\n\nFor a while I thought the issue was my MB or CPU not feeding the data fast enough but I tried the cards in my gaming machine with a quad core and dual x16PCIe slots and it still was about the same.\n\nAny ideas?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18542#msg18542","sj":"Re: OpenCL miner for the masses"},{"f":"da2ce7","d":1288051371,"b":[["t","A quick question, I have had the miner running, if found a \"found: 339339279, 26/10/2010 06:27\"  however, the coins for that block haven't been added to my bit coin wallet...  Have I missed something, or is my wallet corrupt or something?\n\nI have had non open-cl coins generated, maybe my node isn't announcing the newly found block, It dose say 8 connections.."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18548#msg18548","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1288055697,"b":[["t","bethel : -f 35 and -w 128 . I don't have any rate or askrate variable.\n\nda2ce7 : If you started to generate before having all the block downloaded, then the block you found isn't valid. Restart your client and start to generate once you got all the block. This happened to me too, david explained it to me pretty well =)\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18564#msg18564","sj":"Re: OpenCL miner for the masses"},{"f":"da2ce7","d":1288056344,"b":[["t","do you need to have they client generating at the same time as the open-cl miner?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18569#msg18569","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1288058585,"b":[["t","Nop, my bitcoin client don't generate from CPU."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18593#msg18593","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288093952,"b":[["t","HD5850 just arrived and gets a whopping ~235.000khash/s stock, very nice indeed.\nthat's 5 times a GTX260 oc'd at nearly the same power consumption (~200W),\nit's actually a few watts less on the HD5850, still room to oc it a 'lil.  Grin\n\nsome updates:\nran fine througout the day so i did some more testings,\nright now i'm up to 267.000 with default poclbm-settings*,\nthe core clocked at 825MHz (stock 725MHz) doesn't even get close to hot,\nstock <63°C vs. current <66°C, it's fan is still idle,\nwith a bit of luck it might even break 300Mhash, but i'm more than pleased for now.\n\nthis card is well worth its money.\n\n* ~270.000 with frames=10, desktop gets kinda unusable then though, but if i dont need it anway there's some extra Mhs to gain\n\nwoot! Grin\nand just as i write this i generated my first OpenCL block!\n\nit no longer just seems to work, it really does.  Shocked"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18650#msg18650","sj":"Re: OpenCL miner for the masses"},{"f":"Vasiliev","d":1288138475,"b":[["q","Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?\n\nI get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores.  While poclbm.py is running, hash production from bitcoin is reduced to about 8k.  Is this normal?  Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.\n\nGPU is some ATI HD 5400 series.","Quote from: sturle on October 25, 2010, 12:19:09 PM"],["t","OpenCL can run on CPUs, too. It seems like that's what is happening. Maybe. Does poclbm ask you to choose your device when you start it?\n\nMy CPU usage is <5% for poclbm, so something's wrong."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18752#msg18752","sj":"Re: OpenCL miner for the masses"},{"f":"sturle","d":1288164899,"b":[["q","> Quote from: sturle on October 25, 2010, 12:19:09 PM\n> Is poclbm.py supposed to use 100% CPU, and increase CPU usage of Xorg quite a bit as well?\n>\n> I get about 11500 khash/s maximum from poclbm.py, which is the same I get from bitcoin when running on all 4 CPU cores.  While poclbm.py is running, hash production from bitcoin is reduced to about 8k.  Is this normal?  Production from poclbm.py decreases if I reduce it's CPU share, e.g. by niceing it.\n>\n> GPU is some ATI HD 5400 series.\nOpenCL can run on CPUs, too. It seems like that's what is happening. Maybe. Does poclbm ask you to choose your device when you start it?\n\nMy CPU usage is <5% for poclbm, so something's wrong.","Quote from: Vasiliev on October 27, 2010, 12:14:35 AM"],["t","poclbm.py is instructed to use the video card, not the CPU.  If I choose both (0,1), it uses 400% CPU for only 4 khash/s.\n\ncProfile on poclbm.py overnight, and here is the function hogging my CPU:"],["c","  2549577 85597.463    0.034 85597.463    0.034 __init__.py:284(event_wait)"],["t","This is defined in pyopencl:"],["c","    def event_wait(self):\n        wait_for_events([self])\n        return self"],["t","Some kind of active wait loop in wait_for_events?\n\nBtw -- polcbm.py claims to have found two blocks since it started, but only one is registered in my bitcoin client. :-/"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18791#msg18791","sj":"Re: OpenCL miner for the masses"},{"f":"fergalish","d":1288172481,"b":[["t","$ nice -n 15 ./poclbm.py  --user=******** --pass=******** -f 60 -w 256\nNo device specified, you may use -d to specify one of the following\n\nfound: 46380061, 26/10/2010 14:46\nfound: 46380061, 26/10/2010 14:46\n17616 khash/s                          \n\nFound this just now.  Why did it find the same block twice?  Could it be there are, oh, like two threads repeating the same work?\n\nEDIT: also, the main bitcoin client credited me with 50btc, one block, at 14:45.  Total to my credit is just one block 50btc.  What's going on?  I looked through the source, and the RPC commands list.  Where does the source poclbm.py tell the bitcoin client that it found a hash below the target?  (I'm a python newbie)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18803#msg18803","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288183019,"b":[["t","can't help you with that one, the 2 blocks i found so far just showed up once,\n\nbut i'v got another update on the HD5850.\nthe core is up to 910MHz now (from 725@stock), which gives me ~297.000 khashes at default poclbm settings.\nsystem needs ~230W now, plus ~15% power to get plus ~25% hashes, still a good deal.\n\nseems like that's it for basic catalystcc oc'ing, maybe a bit more using higher voltages/other tools, but i'm fine with it.  Cool\n\nto satisfy your screeny-fetish <http://bitlex.co.cc/static/img/screen_HD5850_opencl_btc.jpg>"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18833#msg18833","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288244849,"b":[["t","mornin' miners, up for another update?\nhere we go...\n\nshort version:\n\nHD5850 300.000 khash/s @ 925MHz\n\nlong version:\n\ni did some more testings and tweaks and finally reached my goal,\nto break the 300M-barrier while keeping below 70°C (setting higher voltages would not only consume more energy, as a result it'll also create noise which i really don't like).\n\nwhile Catalysts (and others) tests fail at clocksets above 910MHz, the pocl-miner doesnt care much about it, it runs fine up to 935MHz, more and the miner starts to get laggy and just starting the GPU Caps Viewer crashes the system (not if it's already running).\n\nto stay safe i set it to 925MHz, which still gives hangups and failures in tests, Fallout:New Vegas doesn't even start, stuff like that,\nbut the miner runs fine, stable and averages at above 300Mhash/s.\ni think i'll keep it like that and just set it to defaults to kill Mr.House and save (or rule?) the world, that old guy kinda scares me.\n\nhowever, the ordinary screenshot <http://bitlex.co.cc/static/img/screen_GTX260vsHD5850_opencl_btc.jpg> this time is also a nice comparison of both of my OpenCL-capable Cards, funny that both of 'em found a block within 1hour.\n\nto the left (via vnc) we see a GTX260@685MHz at work, mining 45.000 khash/s on win7x64,\nto the right her greatness HD5850@925MHz, mining 300.000 khash/s on xp64.\n\nnot to mention that theres still 5x2-3GHz CPUs left on those 2 machines that don't do anything right now, but hey, i'd get what, ~1000 khash/s per core? on the HD-miner that's <1%! and it'll also create more heat and noise and will need more energy too,\ni'd rather tweak the card/s a little more. Cheesy\nbut i think i'm done now and more than happy, hell i'm thrilled by those results, never thought the card would go that far.\n\nwhat do you think?\nhow's your machine/s working?\ntell us about it, we wanna know, well at least i do.\n\nhave a great day."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18963#msg18963","sj":"Re: OpenCL miner for the masses"},{"f":"sandos","d":1288249983,"b":[["t","Well, I recently stopped mining on my  CPUs. Really no reason for that anymore it seems =)"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18969#msg18969","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288255974,"b":[["t","nah, i wouldn't say that,\nthe bitcoin-randomizer-node only runs at ~800khash/s on a single core and still generates blocks every now and then,\ni even got miners running on an intel-Atom and PIII-1GHz that just get ~250khash/s.\n\nyou just need some more luck, any single hash could be the one we'r all looking for.\n\nif your running a GPU-miner anyway though, there's at least on midclass-ati-cards no real need to run CPUs, they'll consume more power than needed to get what you want. give your gfx-core another 1-2% speed and your done, this'll take ~5W+ instead of >50W+ for CPUs@full throttle.\n\nif your thinking about, or going to build a new miner-machine, i agree,\ndon't bother with CPUs, nor with nvidia.  Wink\n\ncareful though if you buy new stuff, dont get one of those shiny new HD6850/70, or you'll be dissapointed."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18976#msg18976","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1288268744,"b":[["t","Hey Bitlex !\n\nI'm happy to see that everything's going well on your side =) I'm presently at 650-660mhash/s with my radeon 5970\n\nSetting : 900mhz/1000 memory clock/ vcore to 1.15v / Temps : 78c, with 100% fan on. I use this command :\n\n --user=***** --pass=***** -f 35 -w 128\n\nYou should try to add the -f 35 -w 128 and see how many % you gain. I gained around 20-30mhash with that.\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg18984#msg18984","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288290960,"b":[["t","yeah, that's why i didn't use it"],["q","... I removed usage of vectors. So the '-w 128' is not relevant anymore. Of course you can grab the vectors version from git and use it like before. It is really difficult to optimize for all possible devices. Current version is kind of best for all.","Quote from: m0mchil on October 23, 2010, 04:43:32 PM"],["t","and i havent been compiling any miners myself (tried a few times but had no luck so far installing all required components on x64), so grabbing code x from y to patch z wouldn't help me much.\ni'm just a user anyway, not a coder (php-scripter for fun, but that's it),\none could say i represent the masses (at least those that are interested in how it works), that's why i'm so happy that there's a few nice people to realease binaries.\n\nplaying around with frames just gives me a ~1-2% increase, not really worth mentioning and for the cost of a very low responding desktop.\n\n@m0mchil: you should really put your btc-address either into the initial post of this thread, or your sig, kinda hard to find already and will get even worse over time.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19048#msg19048","sj":"Re: OpenCL miner for the masses"},{"f":"Syke","d":1288394020,"b":[["t","Can anyone post a walkthrough on how to install this (and any dependencies) on Ubuntu? Or post a Linux binary? I have a Tesla I'm dying to try out."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19243#msg19243","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288397713,"b":[["t","i noticed some strange disconnections lately,\neverything seems alright, but it somehow hangs and doesnt get new blocks,\nhappens while\nconnected un-forwarded (showing 8connections),\n-connect=<forwarded-nodes-ip> (showing 1connection),\n-addnode=<forwaded-nopdes-ip> (showing 8connections),\nforwarded-node has 50<80connections and seems to always have all blocks, other nodes sometimes just don't get them, no matter how i connect them.\nnot sure yet what's causing this, a feature to force getblock or somethin' would be handy sometimes.\n\nbut this made me try to set up both OpenCL miners to run on one node.\nstarting the (former GTX-only) node with -rcpallowip, connection and mining works fine,\neatin' a few Mhashes though.\nwhile running the (remote) HD-miner at defaults (askrate=5), the (local) GTX-miner slows down from ~45M to ~43M average, setting (remote) askrate=10 helped here, still a noticable but <1M loss,\nthe HD-miner also goes down ~2%, from 300 to 294.\n\ntested on 100MBit, maybe there's <2% loss on gigabit networks, i'll try as soon as i find someone to pay for some switches and cards.  Cheesy\n\nhappy crunching\nand if anyone knows of, or finds a solution to that spooky non-forwarded-node-disconnects, let me know, thanks."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19259#msg19259","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288400497,"b":[["t","while running standalone, non-forwarded, it's 8connections\nwhile addnode'd, it's 8connections,\nwhile connect'ed to forwarded node, it's only one.\n\nwhat also might help is just running on different (but forwarded) ports,\nas mentioned before silly me isn't able to compile/patch, so i'm not able to try yet. "]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19264#msg19264","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288403176,"b":[["t","i usually start 'em all using addnode, these getblock-lags just happened quite often lately, so i tried using the connect-switch,\nhere's a screeny <http://bitlex.co.cc/static/img/screen_connect-switch.jpg>* of 2 nodes seem to be connected to forwarded-node,  both show only 1 connection, the higher blockcount is, the lower isn't, it sometimes even tells me, drops to 0connections for a sec, then back to 1, but still doesnt get any new blocks.\n\nsame happens when both are addnode'd and showing 8connections, connections drop below 8 and no more blocks are downloaded, mining doesnt stop though, lots of wasted energy, at least it's green.\n\n* from front to back\n- GPU mining to (addnode'd) remote node (not on screen)\n- HD-miner-node -connect=<ip> (idle)\n- a random node -connect=<ip> (idle, running in VM)\n\nabout half an hour after the shot was taken, the random node still hasnt loaded any blocks,\nit's not that it's always the VM that lags blocks though, sometimes it's the other way around."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19267#msg19267","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288454721,"b":[["t","here's <http://bitlex.co.cc/static/img/screen_block_lost.jpg> another unusual behaviour, a lost block.\n\nthe GTX-miner found 2blocks, both show the proof-of-work found...generated 50.00 in the debug.log,\nbut it seems only one of them made it into my wallet."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19321#msg19321","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288456589,"b":[["t","yeah, i also noticed that some blocks need some time to show up,\ni already restarted bitcoin, hoping it might materialize somehow,  Grin\nbut it didn't.\n\nfirst time i noticed this, hopefully the last too."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19327#msg19327","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288469426,"b":[["q","...about deleting the block chain, and having the client re download it to see if it adds that block....","Quote from: davidonpda on October 30, 2010, 04:40:34 PM"],["t","i just tried not a completely new, but <80.000blocks chain and re-downloading,\nthe block is still missing."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19347#msg19347","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1288473283,"b":[["t","The block won't show up. This happens when the network discovered block just after last request for work by the miner. This is the drawback of the pull manner in which getwork... works. The probability for this to happen is 1/60 with ask rate of 10 seconds and 1/120 with ask rate of 5 seconds. It will be better if work is provided in 'push' manner, but I didn't want to complicate the client with separate server thread."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19353#msg19353","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288476026,"b":[["t","ok, thanks,\nso it's nothing to worry about, no big deal anyway, GTX already found a new one,\nshe's lucky lately. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19355#msg19355","sj":"Re: OpenCL miner for the masses"},{"f":"dust","d":1288479347,"b":[["t","I was generating some blocks today on a 5970 and I noticed that both instances of the the miner claimed to have found the same block (see attached image) The main bitcoin client only counts them once (as it should.)  Does anyone know what is happening?  I am running with default settings and -f 30."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19360#msg19360","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1288506219,"b":[["t","Well, this is not good. I will take a look to figure it out."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19376#msg19376","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1288513039,"b":[["t","Sorry guys, I screwed it with the update to SVN 170. There is a bug in getwork patch that makes poclbm useless with more than a single instance. Until this is fixed anyone using more than one instance should use previous version of the patch (against SVN 166). Win32 binary bitcoin-getwork-svn166-win32.7z <http://debian.fmi.uni-sofia.bg/~maurice/bitcoin/bitcoin-getwork-svn166-win32.7z>"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19380#msg19380","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1288573820,"b":[["t","Hey, anyone interested in discussing mining, especially with this miner, please join us in #bitcoin-mining on freenode IRC.\n\nI think it'd be a good idea for everyone to be on the same page, and currently most of the mining discussion is happening in #bitcoin-dev, which may not be appropriate."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19439#msg19439","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1288606550,"b":[["t","Just fixed problem with getwork (different miners were showing same results). Updated to SVN 173. See for windows build in first post."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19483#msg19483","sj":"Re: OpenCL miner for the masses"},{"f":"zipslack","d":1288666275,"b":[["t","Thank you for your hard work, m0mchil!\n\nI seem to have this working properly on my GeForce 8800 GTS. I was pretty proud of my 32000 khash/s until I saw what some of you guys are getting. Wink"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19631#msg19631","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1288711632,"b":[["t","Wow, zipslack, that's almost as much as I get on my GTS 250!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19693#msg19693","sj":"Re: OpenCL miner for the masses"},{"f":"fenpark15","d":1288739515,"b":[["t","Sorry, I'm behind the curve.  I am running the pocl binary (Win 7 64) and it says \"Unable to communicate with bitcoin RPC\"  I have tried installing json-rpc in my Python26 directory using: setup.py install   and it seems to complete without error.  I already have checked my ATI 4600 drivers and ATI Stream so that Open CL is available. \n\nAlso, what user name and password are we supposed to use?   \n\nAgain, I apologize if these questions are dumb.  Until today my only experience with bitcoin is the GUI client hashing on my CPU (4600 k/s = not enough).  "]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19753#msg19753","sj":"Re: OpenCL miner for the masses"},{"f":"fenpark15","d":1288742979,"b":[["t","I was on Bitcoin client 3.08 beta and now have also installed and tried 3.14 beta.  My bitcoin.conf file is located in directory \"c:\\Users\\<my Windows user name>\\AppData\\Roaming\\Bitcoin\"\n\nIt contains 2 lines with syntax : rcpuser=<my unique user name>\n rcppassword=<my unique password>\n\nI am running poclbm from a windows command line with syntax:\npoclbm.exe --user=<username> --pass=<password>\n\nIt recognizes my CPU and GPU, then when I choose one, I get the \"Unable to communicate with bitcoin RPC\"\n\nThank you in advance for any help."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19768#msg19768","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1288747934,"b":[["t","Did you build your client yourself?\nit needs to have the getwork-patch included, so if you didn't,\njust grab the win32-binary in the first post of this thread (works fine for me on 64bit XP&win7).\n\nIf you did (compile with patch, or grab),\nyou need to start the bitcoin-client with the -server switch (maybe -rpcallowip=<IP> if a miner is running on a remote machine)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19777#msg19777","sj":"Re: OpenCL miner for the masses"},{"f":"xxmalouinxx","d":1288751372,"b":[["t","Like BitLex told, I think it's the getwork-patch. Just replace the old bitcoin.exe by the one from the getwork and it should work. Enjoy your Bitcoin !\n\nMalouin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19782#msg19782","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1288789869,"b":[["q","I was on Bitcoin client 3.08 beta and now have also installed and tried 3.14 beta.  My bitcoin.conf file is located in directory \"c:\\Users\\<my Windows user name>\\AppData\\Roaming\\Bitcoin\"\n\nIt contains 2 lines with syntax : rcpuser=<my unique user name>\n rcppassword=<my unique password>\n\nI am running poclbm from a windows command line with syntax:\npoclbm.exe --user=<username> --pass=<password>\n\nIt recognizes my CPU and GPU, then when I choose one, I get the \"Unable to communicate with bitcoin RPC\"\n\nThank you in advance for any help.","Quote from: fenpark15 on November 03, 2010, 12:09:39 AM"],["t","Hmm, are you aware of that you have to start bitcoin in server mode for this to work ?"],["c","bitcoin.exe -server"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19835#msg19835","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1288790445,"b":[["t","Got my new 5970 and it's only showing half performance it should. I'm on Linux with SDK 2.1 and catalyst drivers 10.10. I know others have seen this problem, but I don't know whether I've seen a resolution. Does anyone know how to fix it?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19839#msg19839","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1288792099,"b":[["t","Its not for the masses obviously.  Sad\n\nEdit btc_miner.cl\n\nInsert at the top\n\n#pragma OPENCL EXTENSION cl_amd_media_ops : enable\n\nchange\n\n#define rot(x, y) rotate(x, (uint)y)\n\nto\n\n#define rot(x, y) amd_bitalign(x, x, (uint)(32-y))\n\nSee Stream SDK OpenCL Programming Guide <http://developer.amd.com/gpu_assets/ATI_Stream_SDK_OpenCL_Programming_Guide.pdf> for details.\n\nI'll try to add some macro to resolve this by default."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19847#msg19847","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1288792961,"b":[["t","Ah, that did it, thanks!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19848#msg19848","sj":"Re: OpenCL miner for the masses"},{"f":"fenpark15","d":1288795373,"b":[["t","OK - Have it working now!  I needed to fix some hidden characters that snuck in during the creation of my .conf file.  Also, I was previously not running bitcoin in server mode.\n\n  Only 20740 khash/s with my ATI HD 4600 (work computer) but it sure beats 4600 from the CPU.  Thanks for the help."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19855#msg19855","sj":"Re: OpenCL miner for the masses"},{"f":"ciuciu","d":1288824711,"b":[["t","Hi,\n\nI hope I can get an answer, although my question might seem stupid to some of you.\nI try to run poclbm.exe after I downloaded the files from the first post in this thread and I only get this message:\n\nC:\\Users\\First\\Desktop\\my>poclbm.exe\nTraceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n  File \"pyopencl\\__init__.pyc\", line 3, in <module>\n  File \"pyopencl\\_cl.pyc\", line 12, in <module>\n  File \"pyopencl\\_cl.pyc\", line 10, in __load\nImportError: DLL load failed: The specified procedure could not be found.\n\nThank you."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19954#msg19954","sj":"Re: OpenCL miner for the masses"},{"f":"ciuciu","d":1288826527,"b":[["t","Solved  by reinstalling all drivers. Smiley\n\nYes, installed both.\nI have a Radeon HD 5850 and Windows 7 x64.\n\nThank you."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg19962#msg19962","sj":"Re: OpenCL miner for the masses"},{"f":"teknohog","d":1288975661,"b":[["t","59.5 Mhash/s on a Radeon HD 5570. Cheers to m0mchil Smiley\n\nEdit:\n\nThis is using --frames 1. With the default frames, I only get about 52 Mhash/s.\n\nAfter updating the Radeon Linux drivers from 10.9 to 10.10, the rate decreased slightly to 59.2. However, I then tried the vectors option, which gave a small boost up to 60.65 Mhash/s. The motherboard only has 1x PCIe slots, which may affect things."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg20212#msg20212","sj":"Re: OpenCL miner for the masses"},{"f":"Need2Revolt","d":1288990566,"b":[["t","great work m0mchil!!!\nlaptop with an ATI HD5650 running at 46Mhash/s\n\nthanks a lot for this app and i hope you can put your work in the official trunk asap"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg20252#msg20252","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1289241532,"b":[["t","I am working on a daemon-like version of this miner via a fork on github. The script is minerd.py, and it uses a config file.\n\nIt's still in development / testing, but if you'd like to give it a try here it is:\n\nhttps://github.com/brocktice/poclbm"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg20681#msg20681","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1289266191,"b":[["t","Linux Miner Howto\n\nDonations: 1Nw7aQcdtGVPmMsMtSJrDoQPEu1FJspyfd\n\nI'll probably miss something, so please propose changes if you see fit.\n\n1. Install Linux. For now I recommend Ubuntu 10.04 LTS Server, and I will be targeting it in this guide.\n\n2. Install prerequisites, including compilers."],["c","sudo aptitude install build-essential linux-headers-`uname -r`"],["t","3. Install the ATI drivers. The ubuntu packages are old. First,"],["c","wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-10-x86.x86_64.run"],["t","(then build dpkgs, need to add instructions here)\n\n-OR-\n\nTry "],["c","apt-cache search fglrx"],["t"," on debian-based systems (including ubuntu). If it's available, do "],["c","sudo apt-get install fglrx"],["t",", otherwise, download (and you may want to check for an update) using"],["c","wget https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/drivers/linux/ati-driver-installer-10-10-x86.x86_64.run"],["t","4. Run the installer with "],["c","sudo sh ./ati-driver-installer-10-10-x86.x86_64.run"],["t"," You may instead want to build packages. This may be added later.\n\n5. Do the initial X configuration with "],["c","sudo aticonfig --initial --adapter=all -f"],["t"," as root. And restart X. Logging out of X and back in should work. If you get a black screen, try ctrl-alt-f1, hopefully this will get you to a terminal where you can log in and recover.\n\n6. Get the ATI streaming SDK v2.1 NOT v2.2, from here: http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDK-Archive.aspx\n\n7. Untar it somewhere, I just used ~/ since it's a dedicated mining machine.\n\n8. Edit your ~/.bashrc and add these lines:"],["c","ATISTREAMSDKSAMPLESROOT=/path/to/the/sdk\nATISTREAMSDKROOT=/path/to/the/sdk"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg20817#msg20817","sj":"Re: OpenCL miner for the masses"},{"f":"brocktice","d":1289314807,"b":[["t","By the way, I'd like to add an accuracy-checking opencl code to make sure the video cards are working right before starting generation, or as an optional run-mode. Art is using something similar to do precision overclocking.\n\nI'll probably get around to it eventually, but if someone would like to contribute it feel free. Basically it should take known inputs and hashed outputs, and verify that the card correctly hashes the inputs to the outputs."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21001#msg21001","sj":"Re: OpenCL miner for the masses"},{"f":"InterArmaEnimSil","d":1289318896,"b":[["t","I see all kinds of discussion regarding AMD/ATI drivers here...does this work on nVidia cards which support OpenCL?  Mine is on the list at the beginning of the thread, but I think I may be missing/skipping something, or misinterpreting whether my card is supported by this fork at all.  Thanks to everyone in advance."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21016#msg21016","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1289331861,"b":[["q","does this work on nVidia cards which support OpenCL?","Quote from: InterArmaEnimSil on November 09, 2010, 04:08:16 PM"],["t","yes, it does.\nworks fine for me on 8600GT and gtx260, so it should also work on all in between and above."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21060#msg21060","sj":"Re: OpenCL miner for the masses"},{"f":"LobsterMan","d":1289337172,"b":[["t","Very nice, thanks a lot m0mchil, I'll send some coins as gratitude once I start generating some blocks  Grin\n(running successfully on win7-64 with 2x gtx275's and version 260.99 of the nvidia drivers at present)\n\nI fire up one instance polcbm.exe for each of my gfx cards, specifying 0 or 1 to select which device:\nhttp://i.imgur.com/uONpy.png for example\n\nWorking nicely so far giving me 45-50mhash/s per card, vs. just around 4.1mhash for my i7 running @ 2.67GHz.\n\nA few questions:\n\n-I've obtained the patched bitcoin.exe and I run that with \"bitcoin.exe -server\", is this more or less the same as specifying -daemon? just that daemon has no gui?\n\n-Is there any \"proper\" way to close the miners? ctrl-c works but generates some weird warnings like:"],["c","Traceback (most recent call last):\n  File \"poclbm.py\", line 144, in <module>\n  File \"pyopencl\\__init__.pyc\", line 286, in event_wait\nKeyboardInterrupt"],["t","-At present is the only way to run these and be able to view your hash rate to have command windows open? I imagine I could whip up some sort of batch script to launch 2 of them, but that is still going to need at least 2 console windows, one for each miner?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21074#msg21074","sj":"Re: OpenCL miner for the masses"},{"f":"InterArmaEnimSil","d":1289338278,"b":[["q","> Quote from: InterArmaEnimSil on November 09, 2010, 04:08:16 PM\n> does this work on nVidia cards which support OpenCL?\nyes, it does.\nworks fine for me on 8600GT and gtx260, so it should also work on all in between and above.","Quote from: BitLex on November 09, 2010, 07:44:21 PM"],["t","Great to know that it will work on my card.  I've gotten PyOpenCL installed, but I've hit an impasse patching Satoshi's mainline client.  I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot.  Could someone clue me in to what I'm supposed to be doing here?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21077#msg21077","sj":"Re: OpenCL miner for the masses"},{"f":"lfm","d":1289350087,"b":[["q"," I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot.  Could someone clue me in to what I'm supposed to be doing here?","Quote"],["t","You need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.\nsvn -r {num} http:....\n\nhave fun."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21108#msg21108","sj":"Re: OpenCL miner for the masses"},{"f":"davout","d":1289381225,"b":[["q","> Quote\n>  I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot.  Could someone clue me in to what I'm supposed to be doing here?\n\nYou need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.\nsvn -r {num} http:....\n\nhave fun.","Quote from: lfm on November 10, 2010, 12:48:07 AM"],["t","Go to sources root and then :\n$ patch -i -p0 < /path/to/the/patch"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21219#msg21219","sj":"Re: OpenCL miner for the masses"},{"f":"InterArmaEnimSil","d":1289405991,"b":[["q","> Quote from: lfm on November 10, 2010, 12:48:07 AM\n> > Quote\n> >  I'm running Linux, and the standard \"patch\" command responds that the input is garbage, while copying the patch files on top of the mainline ones won't compile by a long shot.  Could someone clue me in to what I'm supposed to be doing here?\n>\n> You need exactly the right revision of the bitcoin sources to use the patch. Most of the patch versions I have seen are for the \"svn\" development revisions of bitcoin. I think the top few lines of the patch should have a svn revision number that you can use to get the right revision of the source using a svn command.\n> svn -r {num} http:....\n>\n>\n> have fun.\n\nGo to sources root and then :\n$ patch -i -p0 < /path/to/the/patch","Quote from: davout on November 10, 2010, 09:27:05 AM"],["t","Thanks!  The next issue seems to be wxWidgets.  The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work.  Anyone know where I can get 2.9.0?  Or, does 2.9.1 indeed work, and I'm just doing something wrong?  Sorry for the dearth of questions..."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21319#msg21319","sj":"Re: OpenCL miner for the masses"},{"f":"darich","d":1289425902,"b":[["t","On winxp I downloaded binaries and trying with last nvidia driver (geforce 6200).\npoclbm write this:"],["c","C:\\Documents and Settings\\David Richter\\poclbm>poclbm\nTraceback (most recent call last):\n  File \"poclbm.py\", line 55, in <module>\npyopencl.LogicError: clGetPlatformIDs failed: invalid/unknown error code\n\nC:\\Documents and Settings\\David Richter\\poclbm>"],["t","Is it due to nvidia? Is anyone using it with nvidia?\nthnx"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21376#msg21376","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1289427343,"b":[["t","afaik the geforce 6 series does not have support for CUDA/OpenCL.\nyou need geforce 8 and newer."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21390#msg21390","sj":"Re: OpenCL miner for the masses"},{"f":"slush","d":1289507776,"b":[["t","Hi, I cannot get it work Sad\n\nStarted patched bitcoin with rpc enabled, then poclbm.exe, but it displayed"],["c","No device specified, you may use -d to specify one of the following\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 61, in <module>\n    context = cl.create_some_context()\n  File \"pyopencl\\__init__.pyc\", line 350, in create_some_context\npyopencl.RuntimeError: Context failed: out of host memory"],["t","I have already latest development version of OpenCL installed.\n\nAny ideas?  Undecided Thanks  Smiley\nMarek"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21573#msg21573","sj":"Re: OpenCL miner for the masses"},{"f":"SmokeTooMuch","d":1289605239,"b":[["q","(...)\n\n(...)\npyopencl.RuntimeError: Context failed: out of host memory\n(...)","Quote from: slush on November 11, 2010, 08:36:16 PM"],["t","Seems like you have some memory issues O.o"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21754#msg21754","sj":"Re: OpenCL miner for the masses"},{"f":"LobsterMan","d":1289776300,"b":[["t","Any chance of getting a win32 binary of bitcoin.exe for 0.3.15 with the getwork patch?  Grin"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg21985#msg21985","sj":"Re: OpenCL miner for the masses"},{"f":"sandos","d":1289812479,"b":[["t","So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?"],["q","Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet","Quote"],["t","These are $2.10 per hour. "]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22042#msg22042","sj":"Re: OpenCL miner for the masses"},{"f":"Anonymous","d":1289814525,"b":[["q","So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?\n\n> Quote\n> Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet\n\nThese are $2.10 per hour.","Quote from: sandos on November 15, 2010, 09:14:39 AM"],["t","That would be pretty sweet. Didnt someone already try that as an experiment?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22044#msg22044","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1289832927,"b":[["t","See first post for updated (SVN 179, 0.3.15) win32 getwork patched client"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22088#msg22088","sj":"Re: OpenCL miner for the masses"},{"f":"bitcoin2","d":1289842392,"b":[["t","With ATI 5970 Card and ubuntu I get with one Thread ~ 250 000 khash/s. But when I start a second thread the first thread rate is going down and I get with the two threats together not more as 250 000 khash/s. With \"watch -n0 aticonfig --adapter=0 --od-getclocks\" and \"watch -n0 aticonfig --adapter=0 --od-getclocks\" I can see that both GPUs are in use but only under 50% per GPU. I get this Problems with DISPLAY=:0 and with DISPLAY=:0.0 / :0.1 . What is wrong?\n\nThank you."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22109#msg22109","sj":"Re: OpenCL miner for the masses"},{"f":"LobsterMan","d":1289842819,"b":[["q","See first post for updated (SVN 179, 0.3.15) win32 getwork patched client","Quote from: m0mchil on November 15, 2010, 02:55:27 PM"],["t","Thanks  Cool\n\nIf you want to make a quick launch for your miners in windows, just name a file something.bat, open it up in your text editor and then add a few lines like this, substituting your information:"],["c","start /DC:\\Users\\[username]\\Desktop\\poclbm_py2exe_20101102 poclbm.exe --user=youruser --pass=yourpw --device=0 -w 256\nstart /DC:\\Users\\[username]\\Desktop\\poclbm_py2exe_20101102 poclbm.exe --user=youruser --pass=yourpw --device=1 -w 256"],["t","The above is how I launch for my 2 nvidia gtx275's\n-w specifies the work size and changing that (use powers of 2) can affect your hashrate, 256 works best for me on my nvidia gtx275's, but your mileage may vary.\n\nAlso do not forget to make your bitcoin.conf file at:\n(win7)\nC:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf\n\nor\n(xp)\nC:\\Documents and Settings\\USERNAMEHERE\\Application Data\\Bitcoin\\bitcoin.conf\n\ncontaining"],["c","rpcuser=youruser\nrpcpassword=yourpw"],["t","which is what you use in your calls to poclbm.exe\n\nbitcoin.exe must also be launched with the -server argument from the command line to use external miners.\n\nEDIT: Would still like clarification if simply using ctrl-c is an adequate way to exit these miners, or if there is a more \"graceful\" way to do so?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22111#msg22111","sj":"Re: OpenCL miner for the masses"},{"f":"jimbobway","d":1289853612,"b":[["q","> Quote from: sandos on November 15, 2010, 09:14:39 AM\n> So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?\n>\n>\n> > Quote\n> > Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet\n>\n> These are $2.10 per hour.\n\n$2.10 x 24 hours = $50.40.\n\n2 X M2050 = ~ 75 mkhash/s\n\nDifficulty Factor   4536.35372328\n\nHash Target   5.94299671841E+63\n\nProbability   Time\nAverage   3 days, 0 hours, 9 minutes\n50%   2 days, 2 hours, 1 minute\n95%   9 days, 0 hours, 10 minutes\n\n^ From http://www.alloscomp.com/bitcoin/calculator.php\n\nSo, if one block for $150 is a good deal, then yes, it could make you money depending on what you think bitcoins value are now and in the future.\n\nOf course the difficulty is jumping up again in a few days, current generation is still over 9 blocks an hour average.","Quote from: davidonpda on November 15, 2010, 02:36:23 PM"],["t","$150 for a block means, by cloud computing industry standards, is $3 a bitcoin!  $150/50 = $3.  Is this the true worth of a bitcoin?!?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22137#msg22137","sj":"Re: OpenCL miner for the masses"},{"f":"zipslack","d":1289877461,"b":[["q","$150 for a block means, by cloud computing industry standards, is $3 a bitcoin!  $150/50 = $3.  Is this the true worth of a bitcoin?!?","Quote from: jimbobway on November 15, 2010, 08:40:12 PM"],["t","No, it's not what they're worth. It's just what they cost to mine using the EC2 cluster. Just like everything else, bitcoins are worth whatever people are willing to pay for them."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22207#msg22207","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1289903441,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22251#msg22251","sj":"Re: OpenCL miner for the masses"},{"f":"Remote","d":1289955912,"b":[["t","Hey guys, I'm really interested in generating Bitcoins and want to see how much I can get from my GPU. I've used \"Geeks3D GPU Caps Viewer\" and made sure that I do support \"OpenCL(GPU)\".\n\nProblem is that the only clear instruction phases I see is:\n\n1. Download \"(GPU patch) bitcoin-getwork-svn181-win32.7z\" and \"poclbm_py2exe_20101102.7z\".\n2. ?\n3. Profit!\n\nCan a kind somebody please write a proper step-by-step guide as to how you get this to work in Windows 7 64-bit? With all the baby steps, including what files to download and where they can be downloaded from (direct links) plus where stuff should be extracted/configurated.\n\nOf course a half-arsed how-to is better than how it is now, so any effort would be welcome. Smiley I and a lot of others would really appreciate it, and I believe you will be doing the community a huge favor.\n\nPeople that try out making Bitcoins will stay much longer if they have 2000000 khash/s instead of 2000 khash/s."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22356#msg22356","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1289965762,"b":[["t","it's actually all said in this thread, you just have to read it.\n\n1. download (getwork patched client) bitcoin-getwork-* and the miner poclbm_py2exe_*.\n\n2. make sure, you got a bitcoin.conf file at\nC:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf\n(or on xp)\nC:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf\n\ncontaining"],["c","rpcuser=someone\nrpcpassword=secret"],["t","3.a start bitcoin -server and wait for connections to get the last block\n3.b start poclbm --user=someone --pass=secret\nif you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.\nif you don't know how to handle your commandline, just create\na bitcoin.bat containing"],["c","start /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server"],["t","and a poclbm.bat containing"],["c","start /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret"],["t","to feed your clicking-needs.\n\n4. wait and/or pray Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22366#msg22366","sj":"Re: OpenCL miner for the masses"},{"f":"GeorgeH","d":1289969994,"b":[["q","> Quote from: sandos on November 15, 2010, 09:14:39 AM\n> So, someone want to compute wether amazon EC2 Cluster GPU instances would make you any money?\n>\n>\n> > Quote\n> > Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet\n>\n> These are $2.10 per hour.\n\n$2.10 x 24 hours = $50.40.\n\n2 X M2050 = ~ 75 mkhash/s\n\nDifficulty Factor   4536.35372328\n\nHash Target   5.94299671841E+63\n\nProbability   Time\nAverage   3 days, 0 hours, 9 minutes\n50%   2 days, 2 hours, 1 minute\n95%   9 days, 0 hours, 10 minutes\n\n^ From http://www.alloscomp.com/bitcoin/calculator.php\n\nSo, if one block for $150 is a good deal, then yes, it could make you money depending on what you think bitcoins value are now and in the future.\n\nOf course the difficulty is jumping up again in a few days, current generation is still over 9 blocks an hour average.","Quote from: davidonpda on November 15, 2010, 02:36:23 PM"],["t","How did you estimate the hashrate of the cards? By my calculations, they'd hit at least 100mhash/s each.\n\nFermi M2050 = ~2 TFLOPS each\n\nMy NVidia card (8800 GTS 512MB) = ~624 GFLOPS, hashrate = 33mhash/s\n\nFermi hashrate = ~105mhash/s x2 = ~210 mhash/s\n\nDifficulty Factor   4536.35372328\nHash Target   5.94299671841E+63\nHash Rate (khps)   \n\nProbability   Time\nAverage   1 day, 1 hour, 46 minutes\n50%   17 hours, 51 minutes\n95%   3 days, 5 hours, 12 minutes"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22368#msg22368","sj":"Re: OpenCL miner for the masses"},{"f":"Edogaa","d":1289976239,"b":[["t","I'm confused here, how exactly is this installed. I got the bitcoin-getwork-svn181-win32 WHICH I am going to assume is a patched .exe and dll, and the other py2exe thing now that I have those I don't know what to do or exactly hwo to install this pyopencl application.\n\nWindows Vista user by the way, (oh dread)."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22375#msg22375","sj":"Re: OpenCL miner for the masses"},{"f":"ribuck","d":1290003124,"b":[["t","OpenCL HOWTO FOR FEDORA 12 LINUX\n\nHere are some notes which may be useful to anyone who wishes to mine for bitcoins on Fedora 12 Linux. It took me about ten hours to get all of this working, because many of the standard Fedora packages are different to what bitcoin needs and generate all kinds of odd errors when you try to build the makefile.\n\nIf you aren't already running Fedora, save yourself a lot of time and hassles by installing Ubuntu instead.\n\n===\n\nCheck your software versions, and upgrade as necessary. The gcc compiler needs to be 4.x (for PyOpenCL), and Python needs to be 2.4 or newer (again, for PyOpenCL)."],["c","$ gcc --version\ngcc (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10)\n\n$ python --version\nPython 2.6.2"],["t","You need to have either the full kernel source, or the kernel headers (because the ATI GPU driver is installed by compiling a kernel module."],["c","$ rpm -q kernel-devel\nkernel-devel-2.6.32.23-170.fc12.i686\n$ rpm -q kernel-PAE-devel\nkernel-PAE-devel-2.6.32.21-168.fc12.i686"],["t","===\n\nUpdate your display driver.\n\nI followed the instructions from here:\nhttp://gofedora.com/how-to-install-ati-catalyst-fglrx-98-drivers-fedora-11/\nexcept that I used the version 10.10 of the ATI Catalyst Display Driver for Linux x86 from here:\nhttp://support.amd.com/us/gpudownload/linux/Pages/radeon_linux.aspx?type=2.4.1&product=2.4.1.3.42&lang=English\n\nApparently some of the installation steps are no longer needed with version 10.10, but I wasn't completely certain which ones, so I did them all anyway.\n\n===\n\nGet the ATI Stream SDK v2.1 (NOT any later version, according to brocktice), from here: http://developer.amd.com/gpu/ATIStreamSDK/pages/ATIStreamSDK-Archive.aspx\n\nYou need two downloads from that page: the Linux SDK (32-bit or 64-bit according to your version of Linux), plus icd-registration.tgz\n\nUntar the SDK anywhere convenient. Add these lines to your .bash_profile file (in your login directory):"],["c","export ATISTREAMSDKSAMPLESROOT=...<some path>.../ati-stream-sdk-v2.1-lnx32\nexport ATISTREAMSDKROOT=...<some path>.../ati-stream-sdk-v2.1-lnx32\nexport LD_LIBRARY_PATH=$ATISTREAMSDKROOT/lib/x86:$LD_LIBRARY_PATH"],["t","Move icd-registration.tgz into your root directory and (as root) untar it from there. It puts some config files into /etc.\n\nFollow the documentation that is included in the SDK to compile the examples. Execute ati-stream-sdk-v2.1-lnx32/samples/opencl/bin/x86/CLInfo to check that things are working and that your GPU card is detected.\n\n===\n\nInstall the Python OpenCL module (PyOpenCL). Broadly, follow the instructions here:\nhttp://wiki.tiker.net/PyOpenCL/Installation/Linux\n\nHowever, in step 2 I couldn't install the Numpy dependency this way. Instead I ran \"System | Administration | Add/Remove Software\", then searched for numpy and installed it.\n\nIn step 3, the OpenCL headers and libraries weren't found, so I had to use the longer configure.py example and provide explicit paths.\n\nThe \"Boost C++\" libraries are not required for this version of PyOpenCL, but we will need them later (see below).\n\n===\n\nInstall the JSON-RPC module for Python. This was straightforward using the instructions here:\nhttp://json-rpc.org/wiki/python-json-rpc\n\n===\n\nGo to m0mchil's Git repository:\nhttps://github.com/m0mchil/poclbm\n\nClick the \"Download\" button. Download and unpack these files anywhere convenient. Change poclbm.py to executable and check that it's working:"],["c","chmod 744 poclbm.py\n./poclbm.py --help"],["t","===\n\nNext we need to get bitcoin's dependencies correct.\n\nInstall wxWidgets version 2.9.0 (not 2.8 or 2.9.1). You can get version 2.9.0 from here:\nhttp://biolpc22.york.ac.uk/pub/2.9.0/\nFollow the instructions in file build-unix.txt from the /src directory of the bitcoin distribution, except that you will need to be root (\"su -\") for the whole install, not just the \"make install\" step.\n\n===\n\nThe version of OpenSSL that ships with Fedora excludes the elliptic curve cryptography due to patent concerns. Assuming you're in a country without absurd software patent laws, download the source for the latest 0.9.8 version (currently 0.9.8p) of OpenSSL from here:\nhttp://www.openssl.org/source/\n\nBuild, test and install it according to the instructions in the download. However, the standard installation doesn't install the static libraries, so I made some symbolic links:"],["c","sudo ln -s `pwd`/libssl.a /usr/lib\nsudo ln -s `pwd`/libcrypto.a /usr/lib"],["t","===\n\nYou need the static version of the Boost C++ development libraries installed. I installed this from package boost-static-1.39.0\n\n===\n\nYou need the static version of the Berkeley DB development libraries installed. I installed this from package db4-devel-static-4.7.25\n\nThis installed a file libdb_cxx-4.7.a in /usr/lib, but the makefile wanted libdb_cxx.a, so I created a symbolic link:"],["c","cd /usr/lib\nsudo ln -s libdb_cxx-4.7.a libdb_cxx.a"],["t","===\n\nGo to the GIT repository for m0mchil's bitcoin-getwork patch:\nhttps://github.com/m0mchil/bitcoin-getwork\n\nNotice which SVN revision number the patch is for, and use that number instead of 181 in the following command (which downloads the development version of bitcoin):"],["c","svn co -r 181 https://bitcoin.svn.sourceforge.net/svnroot/bitcoin"],["t","Change into the newly-created directory that holds the sources:"],["c","cd bitcoin/trunk"],["t","From m0mchil's repository, click \"Download\" and download the archive. Extract the file getwork-latest.patch into the bitcoin/trunk directory.\n\nModify the sources by applying the patch:"],["c","patch -p0 -i getwork-latest.patch"],["t","It should tell you that it has updated files main.cpp, main.h and rpc.cpp.\n\n===\n\nWe need to tweak Bitcoin's makefile, which is the file bitcoin/trunk/build-unix.txt\n\nIn the WXLIBS section of the makefile, add the line\n-l Xxf86vm\nand also add a trailing backslash to the previous line (it's a line-continuation character). A comment in the makefile says you only need to do this if you have wxWidgets 2.9.1, but I had to do it for 2.9.0.\n\nIf your version of \"Boost\" is less than 1.40 (I'm using 1.39), edit bitcoin's makefile (src/build-unix.txt) and add -mt to the end of the name of each of the \"Boost\" libraries. There are four of these, in the four lines after the line that contains the string \"-Bstatic\".\n\n===\n\nBuilt the getwork-modified version of bitcoin:"],["c","make -f makefile.unix"],["t","This should build a binary called 'bitcoin' in this directory. Try it out! If you already have another instance of bitcoin running, close it. Type ./bitcoin to check that your newly-compiled instance works. If it works OK, close it and we'll move on to mining.\n\n===\n\nIf you don't already have a file bitcoin.conf in your ~/.bitcoin directory, create one and put a username and password in it:"],["c","rpcuser=yourusername\nrpcpassword=yourpassword"],["t","Go back to the bitcoin/trunk directory and start bitcoin in rpc server mode:"],["c","./bitcoin -server &"],["t","Go to the directory where you built poclbm.py and run it:"],["c","./poclbm.py --user=yourusername --pass=yourpassword"],["t","It will ask you which device to use. Choose the one that's not your CPU.\n\nWatch the khash/s figures with sweet delight, and enjoy the few moments before the roar of your cpu fan starts up.\n\nMany thanks to m0mchil and the many others who have offered code or helpful tips."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22412#msg22412","sj":"Re: OpenCL miner for the masses"},{"f":"Essjay","d":1290029667,"b":[["q","I'm using the SHA hashing rate information from golubev's hash tables. His programs brute force attach md5 and sha algorythm's using GPU's. His numbers are extremely accurate and recently updated. Remember we are running two SHA calculations per try.\n\nhttp://btco.in/4s\n\nTake his single sha1 speed and devide it by 4.5 And somehow I messed it up really nicely, and I now get the 200 mhash/s as well. Must have been sleeping when I did that before.","Quote from: davidonpda on November 17, 2010, 02:49:57 PM"],["t","The other issue is, we are using SHA-256, not SHA-1. This means that we take a further speed penalty... SHA-256 is both more computationally complex (more steps to run) and more data complex (more memory to need to shuffle around).\n\nNot sure how you got a factor of 4.5. I would estimate 2 (due to needing 2 iterations of SHA-256 instead of 1) multiplied by 1.5 (penalty of using SHA-256 instead of SHA-1). So a factor of 3?\n\nMaybe there is room for optimisation in our SHA-256 program, yet!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22472#msg22472","sj":"Re: OpenCL miner for the masses"},{"f":"wumpus","d":1290031197,"b":[["t","Thank you very much for the wonderful miner. Good use of GPU power Smiley\n\nI sent you a donation.\n\nBTW, what about adding an option to get the username/password directly from ~/.bitcoin/bitcoin.conf instead of providing them on the command line. That's a little bit safer, as command line arguments can be seen by everyone on the system:"],["c","def read_config_file(filename):\n    '''\n    Read a simply = delimited config file.\n    Raises IOError if unable to open file, or ValueError\n    if an parse error occurs.\n    '''\n    f = open(filename)\n    try:\n        cfg = {}\n        for line in f:\n     line = line.rstrip()\n     if line:\n         (key, value) = line.split('=', 1)\n         cfg[key] = value\n    finally:\n        f.close()\n    return cfg\n\nimport os\nhome = os.getenv(\"HOME\")\nif home:\n    try:\n        cfg = read_config_file(os.path.join(home, '.bitcoin/bitcoin.conf'))\n    except (IOError,ValueError):\n        pass # Cannot read config file, ignore\n    else:\n        options.user = cfg['rpcuser']\n        options.password = cfg['rpcpassword']"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22477#msg22477","sj":"Re: OpenCL miner for the masses"},{"f":"ribuck","d":1290032252,"b":[["q","wxWidgets ... The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work.  Anyone know where I can get 2.9.0?  Or, does 2.9.1 indeed work","Quote from: InterArmaEnimSil on November 10, 2010, 04:19:51 PM"],["t","wxWidgets 2.9.1 won't work, because debugging has been changed around in 2.9.1.\n\nYou can get 2.9.0 here:\nhttp://biolpc22.york.ac.uk/pub/2.9.0/"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22481#msg22481","sj":"Re: OpenCL miner for the masses"},{"f":"wumpus","d":1290032556,"b":[["q","> Quote from: InterArmaEnimSil on November 10, 2010, 04:19:51 PM\n> wxWidgets ... The revision calls for 2.9.0, but I can only find 2.9.1 now, which doesn't appear to work.  Anyone know where I can get 2.9.0?  Or, does 2.9.1 indeed work\n\nwxWidgets 2.9.1 won't work, because debugging has been changed around in 2.9.1.\n\nYou can get 2.9.0 here:\nhttp://biolpc22.york.ac.uk/pub/2.9.0/","Quote from: ribuck on November 17, 2010, 10:17:32 PM"],["t","Works fine here with 2.9.1, then again, I'm not using debugging. I did have to change the makefile a bit, because the library has been split up:"],["q","   -l wx_gtk2u_core-2.9 \\\n   -l wx_gtk2u_adv-2.9 \\\n   -l wx_gtk2u_html-2.9 \\","Quote"],["t","instead of"],["q","-l wx_gtk2ud-2.9 \\","Quote"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22483#msg22483","sj":"Re: OpenCL miner for the masses"},{"f":"ribuck","d":1290033664,"b":[["q","Works fine here with 2.9.1","Quote from: witchspace on November 17, 2010, 10:22:36 PM"],["t","Yes, I just mean that wxWidgets 2.9.1 won't work with the makefile that comes with bitcoin 0.3.15."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22489#msg22489","sj":"Re: OpenCL miner for the masses"},{"f":"wumpus","d":1290033805,"b":[["q","> Quote from: witchspace on November 17, 2010, 10:22:36 PM\n> Works fine here with 2.9.1\n\nYes, I just mean that wxWidgets 2.9.1 won't work with the makefile that comes with bitcoin 0.3.15.","Quote from: ribuck on November 17, 2010, 10:41:04 PM"],["t","Ah, I wouldn't know about that. I had to upgrade bitcoin to SVN trunk version before the getwork patch (from git) could be applied at all."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22491#msg22491","sj":"Re: OpenCL miner for the masses"},{"f":"Remote","d":1290039233,"b":[["q","it's actually all said in this thread, you just have to read it.\n\n1. download (getwork patched client) bitcoin-getwork-* and the miner poclbm_py2exe_*.\n\n2. make sure, you got a bitcoin.conf file at\nC:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf\n(or on xp)\nC:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf\n\ncontaining\n\nrpcuser=someone\nrpcpassword=secret\n\n3.a start bitcoin -server and wait for connections to get the last block\n3.b start poclbm --user=someone --pass=secret\nif you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.\nif you don't know how to handle your commandline, just create\na bitcoin.bat containing\n\nstart /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server\nand a poclbm.bat containing\n\nstart /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret\nto feed your clicking-needs.\n\n4. wait and/or pray Cheesy","Quote from: BitLex on November 17, 2010, 03:49:22 AM"],["t","Thanks for the guide, although it looks like you left something out. When I start the miner I get the following error:\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n  File \"pyopencl\\__init__.pyc\", line 3, in <module>\n  File \"pyopencl\\_cl.pyc\", line 12, in <module>\n  File \"pyopencl\\_cl.pyc\", line 10, in __load\nImportError: DLL load failed: The specified procedure could not be found.\n\nEdit: Please post links if something needs to be downloaded.\n\nI'm on Windows 7 64bit and have a NVIDIA GeForce 8800 GTS (with \"OpenCL 1.0 CUDA 3.1.1 - CU: 12 @ 1188MHz (GPU)\")."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22502#msg22502","sj":"Re: OpenCL miner for the masses"},{"f":"wumpus","d":1290102684,"b":[["t","Wow, I just went from 2000 khash/s to almost 5000 by playing with the -f option Smiley\n\nEdit : this variance changed when going to NV driver  260.19.21, now it's about 5500 and the -f has a lot less influence.\nAlso, CPU usage of the GPU miner went down with this driver. It was 100% with the old driver, now 2% Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22640#msg22640","sj":"Re: OpenCL miner for the masses"},{"f":"LobsterMan","d":1290135759,"b":[["t","I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:\n\nThere seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.\nIs this something to worry about, or just a peculiarity of testnet? "]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22741#msg22741","sj":"Re: OpenCL miner for the masses"},{"f":"Remote","d":1290152242,"b":[["q","> Quote from: BitLex on November 17, 2010, 03:49:22 AM\n> it's actually all said in this thread, you just have to read it.\n>\n> 1. download (getwork patched client) bitcoin-getwork-* and the miner poclbm_py2exe_*.\n>\n>\n> 2. make sure, you got a bitcoin.conf file at\n> C:\\Users\\[username]\\AppData\\Roaming\\Bitcoin\\bitcoin.conf\n> (or on xp)\n> C:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\\bitcoin.conf\n>\n> containing\n>\n> rpcuser=someone\n> rpcpassword=secret\n>\n>\n> 3.a start bitcoin -server and wait for connections to get the last block\n> 3.b start poclbm --user=someone --pass=secret\n> if you only have one GPU, this is it, if there's more, you'd need to specify the device to use for the miner, but it will tell you.\n> if you don't know how to handle your commandline, just create\n> a bitcoin.bat containing\n>\n> start /DC:\\Users\\[username]\\Desktop\\bitcoin bitcoin.exe -server\n> and a poclbm.bat containing\n>\n> start /DC:\\Users\\[username]\\Desktop\\poclbm poclbm.exe --user=someone --pass=secret\n> to feed your clicking-needs.\n>\n>\n> 4. wait and/or pray Cheesy\n\nThanks for the guide, although it looks like you left something out. When I start the miner I get the following error:\n\nTraceback (most recent call last):\n  File \"poclbm.py\", line 5, in <module>\n  File \"pyopencl\\__init__.pyc\", line 3, in <module>\n  File \"pyopencl\\_cl.pyc\", line 12, in <module>\n  File \"pyopencl\\_cl.pyc\", line 10, in __load\nImportError: DLL load failed: The specified procedure could not be found.\n\nEdit: Please post links if something needs to be downloaded.\n\nI'm on Windows 7 64bit and have a NVIDIA GeForce 8800 GTS (with \"OpenCL 1.0 CUDA 3.1.1 - CU: 12 @ 1188MHz (GPU)\").","Quote from: Remote on November 18, 2010, 12:13:53 AM"],["t","Nobody that can help me? I'm about to give up on running Bitcoins since I could use my CPU for other things, but I would like to use my GPU while I'm doing those other things. Please take a moment and explain how to fix this error."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22764#msg22764","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1290156497,"b":[["t","i'm not sure about that error,\nbut do you have latest devdriver and cudatoolkit <http://developer.nvidia.com/object/cuda_3_2_downloads.html> installed on your machine?"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22774#msg22774","sj":"Re: OpenCL miner for the masses"},{"f":"AHZ","d":1290199158,"b":[["q","I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:\n...\nThere seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.\nIs this something to worry about, or just a peculiarity of testnet?","Quote from: LobsterMan on November 19, 2010, 03:02:39 AM"],["t","I had 2 such events with bitcoin-getwork-svn173-win32 in a real network\nthe miner had the event, but bitcoin did not catch it at all.\nI still do not know what happened there and how to to trace it Sad"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22900#msg22900","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1290199847,"b":[["t","that's just one of those ~10% \"lost blocks\",\nyour miner finds one, your client checks the network, network tells your client it's to late.\n\nwithin the last weeks i'v been able to \"find\" 50hashes, only 45 of them have been accepted/shown up in the client-gui/generating coins.\nget used to it."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22904#msg22904","sj":"Re: OpenCL miner for the masses"},{"f":"LobsterMan","d":1290202449,"b":[["q","> Quote from: LobsterMan on November 19, 2010, 03:02:39 AM\n> I made a bit of a discovery when testing m0m's latest binaries in -testnet, look at the times when blocks are generated in the miners, and note that they don't all show up in bitcoin's UI:\n>\n> There seems to be a delay of 1 or more minutes between when they show up in the miner and when bitcoin picks up the transaction, if it picks it up at all.\n> Is this something to worry about, or just a peculiarity of testnet?\n\nWhen they show up in the command window, they have zero confirmations. They do not show in the bitcoin UI until they have one confirmation. That delay can be a minute or 10. It is not a bug.","Quote from: davidonpda on November 19, 2010, 03:55:59 AM"],["t","I don't think that is true...some of my blocks have shown up immediately with \"0 confirmations\" as soon as the miner locates them."],["q","that's just one of those ~10% \"lost blocks\",\nyour miner finds one, your client checks the network, network tells your client it's to late.\n\nwithin the last weeks i'v been able to \"find\" 50hashes, only 45 of them have been accepted/shown up in the client-gui/generating coins.\nget used to it.","Quote from: BitLex on November 19, 2010, 08:50:47 PM"],["t","That's....not cool  Angry"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22917#msg22917","sj":"Re: OpenCL miner for the masses"},{"f":"BitLex","d":1290204142,"b":[["q","That's....not cool","Quote"],["t","but that's how it is, you can't always win the race.\nif your CPU/regular-miner does this, you wouldn't even notice/care, except when checking your debug.log."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg22927#msg22927","sj":"Re: OpenCL miner for the masses"},{"f":"m0mchil","d":1290248179,"b":[["t","updated to SVN 186"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg23018#msg23018","sj":"Re: OpenCL miner for the masses"},{"f":"wumpus","d":1290265380,"b":[["q","updated to SVN 186","Quote from: m0mchil on November 20, 2010, 10:16:19 AM"],["t","Applies cleanly, thanks Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg23072#msg23072","sj":"Re: OpenCL miner for the masses"},{"f":"satoshi","d":1290273860,"b":[["q","updated to SVN 186","Quote from: m0mchil on November 20, 2010, 10:16:19 AM"],["t","Thanks m0mchil for keeping up on the updates!\n\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."],["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.","Quote from: m0mchil on November 16, 2010, 10:30:41 AM"],["t","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)"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097","s":1,"n":506,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/506/","sj":"Re: OpenCL miner for the masses"},{"f":"slush","d":1290536933,"b":[["t","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!"]],"u":"https://bitcointalk.org/index.php?topic=1334.msg23867#msg23867","sj":"Re: OpenCL miner for the masses"},{"f":"satoshi","d":1290621189,"b":[["t","A revised version of getwork is now in the official client, but the miners need to be updated a little to use it."]],"u":"https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101","s":1,"n":510,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/510/","sj":"Re: OpenCL miner for the masses"}]},{"id":"p233","k":"p","s":"bitcointalk","t":"[PATCH] increase block size limit","u":"https://bitcointalk.org/index.php?topic=1347","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/233/","m":[{"f":"jgarzik","d":1286136822,"b":[["t","We should be able to at least match Paypal's average transaction rate..."],["c","diff --git a/main.h b/main.h\nindex c5a0127..c92592a 100644\n--- a/main.h\n+++ b/main.h\n@@ -14,7 +14,10 @@ class CBlockIndex;\n class CWalletTx;\n class CKeyItem;\n \n-static const unsigned int MAX_BLOCK_SIZE = 1000000;\n+static const unsigned int TX_PER_MINUTE = 1400;\n+static const unsigned int TX_AVG_SIZE_GUESS = 256;\n+static const unsigned int MAX_BLOCK_SIZE =\n+ TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;\n static const unsigned int MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;\n static const int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;\n static const int64 COIN = 100000000;"],["t","URL: http://yyz.us/bitcoin/patch.bitcoin-block-sz-limit"]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15121#msg15121"},{"f":"theymos","d":1286137719,"b":[["t","Applying this patch will make you incompatible with other Bitcoin clients."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15126#msg15126"},{"f":"satoshi","d":1286140048,"b":[["q","Applying this patch will make you incompatible with other Bitcoin clients.","Quote from: theymos on October 03, 2010, 08:28:39 PM"],["t","+1 theymos.  Don't use this patch, it'll make you incompatible with the network, to your own detriment.\n\nWe can phase in a change later if we get closer to needing it."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139","s":1,"n":478,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/478/"},{"f":"jgarzik","d":1286141926,"b":[["q","We can phase in a change later if we get closer to needing it.","Quote from: satoshi on October 03, 2010, 09:07:28 PM"],["t","IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15145#msg15145"},{"f":"FreeMoney","d":1286177975,"b":[["q","> Quote from: satoshi on October 03, 2010, 09:07:28 PM\n> We can phase in a change later if we get closer to needing it.\n\nIMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.","Quote from: jgarzik on October 03, 2010, 09:38:46 PM"],["t","Satoshi just said it can be changed, so technically the network is capable."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15207#msg15207"},{"f":"jgarzik","d":1286179801,"b":[["q","> Quote from: jgarzik on October 03, 2010, 09:38:46 PM\n> > Quote from: satoshi on October 03, 2010, 09:07:28 PM\n> > We can phase in a change later if we get closer to needing it.\n>\n> IMO it's a marketing thing.  It's tough to get people to buy into a system, if the network is technically incapable of supporting high transaction rates.\n\nSatoshi just said it can be changed, so technically the network is capable.","Quote from: FreeMoney on October 04, 2010, 07:39:35 AM"],["t","It is also an incompatible change, as you see....."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15215#msg15215"},{"f":"martin","d":1286193035,"b":[["t","No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15268#msg15268"},{"f":"jgarzik","d":1286217235,"b":[["q","No, it's incompatible if just a few people change their behaviour. To roll out a change to the network you need to get most of the clients understanding both the old and the new protocol, and then when you have a majority you turn on the new protocol.","Quote from: martin on October 04, 2010, 11:50:35 AM"],["t","You just described a whole-network upgrade.  I'd call that an incompatible change Smiley\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15342#msg15342"},{"f":"satoshi","d":1286221720,"b":[["t","It can be phased in, like:\n\nif (blocknumber > 115000)\n    maxblocksize = largerlimit\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366","s":1,"n":485,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/485/"}]},{"id":"p234","k":"p","s":"bitcointalk","t":"Tor connections not working reliably, many seednodes offline","u":"https://bitcointalk.org/index.php?topic=1375","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/234/","m":[{"f":"theymos","d":1286330378,"b":[["t","While I was trying out Bitcoin with Tor a while ago, I found that it was impossible to get connected in a reasonable amount of time. See the debug.log excerpt below."],["c","Starting 2 BitcoinMiner threads\nBitcoinMiner started\nBitcoinMiner started\ntrying connection  lastseen=-2.0hrs lasttry=-357170.7hrs\nproxy connecting\nproxy connecting\nproxy connected\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.\nIRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)\nIRC socket closed\nIRC waiting 71 seconds to reconnect\nproxy connecting\nproxy connected\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.\ntrying connection  lastseen=-2.0hrs lasttry=-357170.7hrs\nproxy connecting\nIRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)\nIRC socket closed\nIRC waiting 138 seconds to reconnect\ntrying connection  lastseen=-2.1hrs lasttry=-357170.7hrs\nproxy connecting\nproxy connecting\nproxy connected\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.\nDelayedRepaint\ntrying connection  lastseen=-2.1hrs lasttry=-357170.8hrs\nproxy connecting\nIRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)\nIRC socket closed\nIRC waiting 211 seconds to reconnect\nDelayedRepaint\ntrying connection  lastseen=-2.1hrs lasttry=-357170.8hrs\nproxy connecting\nproxy connecting\ntrying connection  lastseen=-2.2hrs lasttry=-357170.8hrs\nproxy connecting\nproxy connected\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Looking up your hostname...\nIRC :giraffe.heliacal.net NOTICE AUTH :*** Your forward and reverse DNS do not match, ignoring hostname.\nIRC ERROR :Closing Link: 208.53.142.42 (Registration timed out)\nIRC socket closed\nIRC waiting 292 seconds to reconnect\ntrying connection  lastseen=-2.2hrs lasttry=-357170.9hrs\nproxy connecting\nDelayedRepaint\nDBFlush(false)\naddr.dat refcount=0\naddr.dat flush\nler exiting\nThreadMessageHandler exiting\nblkindex.dat refcount=0\nblkindex.dat flush\nThreadIRCSeed exiting\nThreadBitcoinMiner exiting, 1 threads remaining\nThreadBitcoinMiner exiting, 0 threads remaining\nwallet.dat refcount=0\nwallet.dat flush\nStopNode()\nDBFlush(true)\nBitcoin exiting"],["t","I know that the guy who operates irc.lfnet.org is around here. Maybe he can remove that hostname limitation, since it's blocking some users.\n\nAlso, most of the seednodes are gone. Only 37 out of 230 are accepting connections on port 8333. This makes connecting without IRC very slow. The offline ones should be removed. A list of online seednodes is attached."]],"u":"https://bitcointalk.org/index.php?topic=1375.msg15593#msg15593"},{"f":"jgarzik","d":1286332740,"b":[["t","IMO, there needs to be a method besides IRC and compiled-in seed nodes.  A middle ground.\n\nMaybe a few volunteers could independently host a DNS zone that returns a fresh list of nodes as 'A' records.  A simple cron job could fetch fresh addresses from the bitcoin client, to update the DNS zone every so often.  A DNS lookup would be far faster than an IRC connection, and if we have enough volunteers, the loss of a DNS server or two would not impact the service."]],"u":"https://bitcointalk.org/index.php?topic=1375.msg15594#msg15594"},{"f":"The Madhatter","d":1286334074,"b":[["t","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.\n\nSee https://www.bitcoin.org/smf/index.php?topic=59.msg14635#msg14635"]],"u":"https://bitcointalk.org/index.php?topic=1375.msg15596#msg15596"},{"f":"satoshi","d":1286386601,"b":[["t","Maybe you were just unlucky to have an exit node without reverse lookup.\n\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.\n\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.\n\nI don't know if it's really required to wait for the server to finish looking up hostname before sending nick.\n\nHow long did it take to get connected with TOR the first time, having to use the seed nodes?"]],"u":"https://bitcointalk.org/index.php?topic=1375.msg15682#msg15682","s":1,"n":488,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/488/"}]},{"id":"p235","k":"p","s":"bitcointalk","t":"Key pool feature for safer wallet backup","u":"https://bitcointalk.org/index.php?topic=1414","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/235/","m":[{"f":"satoshi","d":1286655573,"b":[["t","SVN rev 163 (ver 0.3.13.3) has the key pool feature.  Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you'll use in the future.\n\nFor now I made the default pool size 100.  It can be configured with -keypool=.  Be aware, it takes a little time to increase the pool size, so don't go crazy with it.  Disk space is about 1K per key.\n\nI have not addressed the recovery side of this yet.  If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.\n\nI've only tested this moderately.  You might not want to use this for a website server until it's had some more testing."]],"u":"https://bitcointalk.org/index.php?topic=1414.msg16316#msg16316","s":1,"n":490,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/490/"}]},{"id":"p236","k":"p","s":"bitcointalk","t":"Version 0.3.14","u":"https://bitcointalk.org/index.php?topic=1528","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/236/","m":[{"f":"satoshi","d":1287679167,"b":[["t","Version 0.3.14 is now available\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/\n\nChanges:\n- Key pool feature for safer wallet backup\nGavin Andresen:\n- TEST network mode with switch -testnet\n- Option to use SSL for JSON-RPC connections on unix/osx\n- validateaddress RPC command\neurekafag:\n- Russian translation"]],"u":"https://bitcointalk.org/index.php?topic=1528.msg17924#msg17924","s":1,"n":491,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/491/"}]},{"id":"p237","k":"p","s":"bitcointalk","t":"ERROR - PLEASE HELP ME!","u":"https://bitcointalk.org/index.php?topic=1530","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/237/","m":[{"f":"Dhaw","d":1287694329,"b":[["t","My Bitcoin have this ERROR:\n\n\"Warning: displayed transactions may not be correct! you may need to upgrade, or other nodes may need to upgrade\"\n\nMy bitcoin is in error. I had about 13,000 BTC. I tried to transfer these coins to another computer. But I find the following error. Did not transfer the blocks that are being generated are invalid. What to do?"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17947#msg17947"},{"f":"theymos","d":1287698426,"b":[["t","Dhaw sent me some of his debug.log files. Symptoms I saw:\n- In most of the files his block count remains \"stuck\" at 1698.\n- In one file he accepted blocks beyond that, but it went back to 1698 after he restarted Bitcoin.\n- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.\n- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.\n\nI'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.\n\nHe speaks 'Portuguese (Brazilian)'. A translator would be helpful."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955"},{"f":"nelisky","d":1287698582,"b":[["q","Dhaw sent me some of his debug.log files. Symptoms I saw:\n- In most of the files his block count remains \"stuck\" at 1698.\n- In one file he received blocks up to 2933, but it went back to 1698 after he restarted Bitcoin.\n- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.\n- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.\n\nI'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.\n\nHe speaks 'Portuguese (Brazilian)'. A translator would be helpful.","Quote from: theymos on October 21, 2010, 10:00:26 PM"],["t","I can translate. Just post or PM and I'll have it in English for all."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17956#msg17956"},{"f":"Dhaw","d":1287698724,"b":[["t","I wanted a providence. A few months bitcoin'm using the same open 24 hours a day, and right now I want to sell BTC, I have this problem. I beg you to solve my problem. I thank Theymos, tried to help me for some time. But please, solve my problem, I have no intention of stealing, just want to sell my coins, which have long'm joining. I can not lose 13,000 BTC, took a long time to stop generating."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17958#msg17958"},{"f":"Dhaw","d":1287698798,"b":[["q","> Quote from: theymos on October 21, 2010, 10:00:26 PM\n> Dhaw sent me some of his debug.log files. Symptoms I saw:\n> - In most of the files his block count remains \"stuck\" at 1698.\n> - In one file he received blocks up to 2933, but it went back to 1698 after he restarted Bitcoin.\n> - Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.\n> - He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.\n>\n> I'm almost sure that Dhaw is not a scammer, and is a victim of some bug. My guess is that every time he restarts Bitcoin, his block database is corrupted.\n>\n> He speaks 'Portuguese (Brazilian)'. A translator would be helpful.\n\nI can translate. Just post or PM and I'll have it in English for all.","Quote from: nelisky on October 21, 2010, 10:03:02 PM"],["t","Thanks for the help. In what can help me, everything will be easier."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17959#msg17959"},{"f":"LZ","d":1287717020,"b":[["t","I can't reproduce it. I think he should get the block chain in a different way.\n\nThis is a link to the block chain up to the block 74000: download <https://ipfs.io/ipns/lzsaver.name/share/bins/blk74000.exe>."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg17994#msg17994"},{"f":"joe","d":1287727077,"b":[["t","1. Go to a different computer\n2. Download and install bitcoin from bitcoin.org\n3. Run bitcoin\n4. Wait for block count to reach the latest current block count\n5. Stop bitcoin\n6. Copy wallet.dat from old computer with the 13000 bitcoins over to the new computer's installation's wallet.dat file.\n7. Restart bitcoin\n8. Problem should be solved now and your 13000 bitcoin balance should be displayed."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18014#msg18014"},{"f":"Dhaw","d":1287728827,"b":[["t","i will try!"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18016#msg18016"},{"f":"caveden","d":1287731133,"b":[["q","He speaks 'Portuguese (Brazilian)'. A translator would be helpful.","Quote from: theymos on October 21, 2010, 10:00:26 PM"],["t","I speak it too. If you need help PM me."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18026#msg18026"},{"f":"Dhaw","d":1287741496,"b":[["q","1. Go to a different computer\n2. Download and install bitcoin from bitcoin.org\n3. Run bitcoin\n4. Wait for block count to reach the latest current block count\n5. Stop bitcoin\n6. Copy wallet.dat from old computer with the 13000 bitcoins over to the new computer's installation's wallet.dat file.\n7. Restart bitcoin\n8. Problem should be solved now and your 13000 bitcoin balance should be displayed.","Quote from: joe on October 22, 2010, 05:57:57 AM"],["t","Not getting results with this procedure. The coins remain to be sent, and I sent has not arrived yet."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18035#msg18035"},{"f":"Dhaw","d":1287741567,"b":[["q","I can't reproduce it. I think he should get the block chain in a different way.\n\nThis is a link to the block chain up to the block 74000: download <http://dl.dropbox.com/u/10683110/blk74000.exe>.","Quote from: lzsaver on October 22, 2010, 03:10:20 AM"],["t","just perform the installation procedure on the machine that has the BTCS?"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18036#msg18036"},{"f":"mcjohn","d":1287751701,"b":[["t","Somewhere on the 21st of this month more than 10000 BTC's had to be sent to Dhaw (should be in the block chain)\n\nas he had 1200 BTC at 11:33 am (see http://bitcointalk.org/index.php?action=profile;u=1904;sa=showPosts )\n\nand reported that he is missing 13000 BTC at 08:46 pm (in this forum subject)\n\nwhen he wanted to sent some of the 13000 BTC"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18055#msg18055"},{"f":"Dhaw","d":1287753265,"b":[["t","try to understand my case, I send you all the screenshots if needed. I had BTC 8200, and transferred to another computer, but that did not. I continued to leave the program generates, and generated more than 4,200, only the site that sent the first 8200 not received. That is, I have all these bitcoins, those who currently own and was not sent and received, adding that gives BTC 8200. Theymos saw all my case it was an afternoon trying to help me. I hope it is resolved and not lose my coins."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18062#msg18062"},{"f":"Gavin Andresen","d":1287757514,"b":[["t","Dhaw generated all of these coins on his (her?) own machines.\n\nUnfortunately, either due to a bug or some oddness with Dhaw's network connections they were all generated on an alternate block chain.\n\nThe Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074"},{"f":"theymos","d":1287763564,"b":[["q","Dhaw generated all of these coins on his (her?) own machines.\n\nUnfortunately, either due to a bug or some oddness with Dhaw's network connections they were all generated on an alternate block chain.\n\nThe Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.","Quote from: gavinandresen on October 22, 2010, 02:25:14 PM"],["t","That's probably the case, but something must have failed really badly. His block count is constantly stuck at 1698, but he somehow managed to generate and mature 13,000 BTC? He's generating at a work computer, so maybe it's some crazy antivirus.\n\nJust to be sure that the entire balance is bad (maybe it just failed recently), Dhaw should post the raw transaction so that the inputs can be checked against the block chain.\n\nDhaw:\n1. On the computer where you sent the 8,750, modify the Bitcoin shortcut so it runs in debug mode:\nhttp://static/img264.imageshack.us/static/img264/2526/85647303.png\nhttp://static/img146.imageshack.us/static/img146/723/90684161.png\n2. Run Bitcoin.\n3. Double-click the 8,750 transaction:\nhttp://static/img525.imageshack.us/static/img525/6200/90747626.png\n4. Copy all of the \"inputs\" to http://pastebin.com/ and post the link here.\nhttp://static/img263.imageshack.us/static/img263/6645/68205424.png\nTo copy from that window, you have to use Ctrl+C after selecting the text. I've found that it sometimes takes a few tries to work."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18081#msg18081"},{"f":"LZ","d":1287777502,"b":[["q","just perform the installation procedure on the machine that has the BTCS?","Quote from: Dhaw on October 22, 2010, 09:59:27 AM"],["t","Yes, but before that make sure that the client is closed. Your block chain will be overwritten.\nAnd also it will be nice, if you will make backup of your block chain and upload it for analysis.\nJust open %APPDATA%\\Bitcoin directory and make copy of blk0001.dat and blkindex.dat files.\nThis should be done before the block chain will be overwritten. Be careful with the wallet.dat!"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18097#msg18097"},{"f":"joe","d":1287821357,"b":[["q","Dhaw sent me some of his debug.log files. Symptoms I saw:\n- In most of the files his block count remains \"stuck\" at 1698.\n- In one file he accepted blocks beyond that, but it went back to 1698 after he restarted Bitcoin.\n- Any blocks he receives after 1698 he probably considers invalid. I haven't seen the actual block rejection (it keeps getting removed by the auto-trim), but his debug.log is full of \"block xxx have\" messages for blocks that he clearly doesn't recognize as valid.\n- He is connected to real peers. He connected successfully to IRC, and he was able to connect to me with -addnode. I verified at my end that he is successfully sending getblocks messages.","Quote from: theymos on October 21, 2010, 10:00:26 PM"],["t","What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.\n\nIn any case, all the 1000s of bitcoins he generated were generated into a chain branch that only he was participating on, so they are worthless on the main chain. He would be generating 50 every 5 minutes being the only participant on that branch. The other curiosity is why he stood at 1698; this should have eventually started going up by 1 every 5 minutes when he recalculated difficulty."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18155#msg18155"},{"f":"Dhaw","d":1287857091,"b":[["t","And now??\n=(\nMore than 3 months lose?"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18235#msg18235"},{"f":"theymos","d":1287857677,"b":[["q","What does it take for a client to reject an incoming block from the network? If we know this we can work backwards and find out why he wants to reject every new block. There must be a transaction in the main chain 1699 or prior that his client disagrees with.","Quote from: joe on October 23, 2010, 08:09:17 AM"],["t","He would have to disagree with 1699, but that is an empty block. There's no reason he should disagree with that one.\n\nMy theory:\n\nHis antivirus cuts off files after a certain size. This caused his block database to be limited at 1698 (and maybe he rejects blocks after that due to corruption). However, his block index was not cut off (because it's shorter), so he ignores incoming blocks as \"already have\", even though he doesn't really have them. Every time he generates a block, it is quickly destroyed by the antivirus, but its confirmations are preserved by the block index for some reason."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18238#msg18238"},{"f":"jimbobway","d":1287857809,"b":[["t","dhaw, what kind of antivirus or spyware are you running?"]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18239#msg18239"},{"f":"satoshi","d":1287858169,"b":[["q","his block count remains \"stuck\" at 1698.","Quote from: theymos on October 21, 2010, 10:00:26 PM"],["t","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.\n\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."],["q","The Bitcoin client really shouldn't allow coin generation until you have all of the blocks up to the last block checkpoint.","Quote from: gavinandresen on October 22, 2010, 02:25:14 PM"],["t","Good idea, I made a change to make sure it won't generate before checkpoint block 74000."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241","s":1,"n":493,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/493/"},{"f":"theymos","d":1287858559,"b":[["q","He was generating invalid blocks at difficulty 1.0.  He must have a corrupted txindex entry in his blkindex.dat file.  He just needs to delete blk*.dat and let it redownload.","Quote from: satoshi on October 23, 2010, 06:22:49 PM"],["t","He already did that, and the same problem occurred right away. So it's probably an antivirus issue."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18243#msg18243"},{"f":"satoshi","d":1287859084,"b":[["t","OK, if it really won't get past block 1698 on redownload, then we're in stranger territory.\n\nYes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.\n\nIt would be instructive to get knightmb's blk*.dat and see if that gets him past that point."]],"u":"https://bitcointalk.org/index.php?topic=1530.msg18245#msg18245","s":1,"n":494,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/494/"}]},{"id":"p238","k":"p","s":"bitcointalk","t":"Win7 64bit since last patch Tues now crashes","u":"https://bitcointalk.org/index.php?topic=1540","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/238/","m":[{"f":"Odin","d":1287782678,"b":[["t","This is from 0.3.14-win32-setup.exe.  Previously I was running (up until an hour ago) a version of bitcoin.exe from Jul-2010 (which also was crashing) and the crash reports look similar.  So I upgraded to see if the problem has been fixed.\n\nTo clarify what I am saying any starting of the EXE immediately reports the crash.  So when I login I see the Win7 crash report and if I manually try to start it the same.  The dialog beyond the crash report is \"The application was unable to start correctly (0xc0000005).  Click OK to close the application.\"\n\nPlease also try to tag the application .EXE with the version information if possible, as you can see it is 0.0.0.0."],["c","Problem signature:\n  Problem Event Name: APPCRASH\n  Application Name: bitcoin.exe\n  Application Version: 0.0.0.0\n  Application Timestamp: 4cbf4979\n  Fault Module Name: mingwm10.dll\n  Fault Module Version: 0.0.0.0\n  Fault Module Timestamp: 46b3b561\n  Exception Code: c0000005\n  Exception Offset: 00001470\n  OS Version: 6.1.7600.2.0.0.256.1\n  Locale ID: 2057\n  Additional Information 1: 4c0d\n  Additional Information 2: 4c0d4d78887f76d971d5d00f1f20a433\n  Additional Information 3: 4c0d\n  Additional Information 4: 4c0d4d78887f76d971d5d00f1f20a433"]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105"},{"f":"Odin","d":1287783029,"b":[["t","Have tried turning off Windows Defender, Real Time checking and excluding \"C:\\Program Files (x86)\\bitcoin\" but this made no difference.\n\nAs another recent thread indicates their problem was fixed or potential solution in this way.\n\nThis thread below is the closest match.  I can say the crash started the moment I rebooted after October 2010 patch Tuesday, windows update (which were only applied a few days ago).\n\nhttp://bitcointalk.org/index.php?topic=991.0\n\nFYI - I was not overclocking or otherwise buggering about with anything in ways I'm not meant to.  Which the above thread OP claims to have done.  Also My Wallet.dat looks fine, none of the AppRoaming files have been modified since I rebooted after installing the 23 updates all in one go."]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18108#msg18108"},{"f":"satoshi","d":1287859922,"b":[["q","  Fault Module Name:   mingwm10.dll","Quote from: Odin on October 22, 2010, 09:24:38 PM"],["t","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.\n\nIs anyone else running OK on Windows 64-bit?"]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18246#msg18246","s":1,"n":495,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/495/"},{"f":"LZ","d":1287869235,"b":[["t","I have no problems with the official Bitcoin and 64-bit Windows 7."]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18261#msg18261"},{"f":"Drifter","d":1287887219,"b":[["t","Running just fine on Win7 64bit as well"]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18272#msg18272"},{"f":"Odin","d":1287922187,"b":[["t","Ok good to know others are able to run it ok.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18319#msg18319"},{"f":"satoshi","d":1288027667,"b":[["t","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.\"\n\nThe end of your debug.log file might show the last thing it was doing before it crashed."]],"u":"https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511","s":1,"n":499,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/499/"}]},{"id":"p239","k":"p","s":"bitcointalk","t":"Suggestion: Allow short messages to be sent together with bitcoins ?","u":"https://bitcointalk.org/index.php?topic=1545","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/239/","m":[{"f":"ShadowOfHarbringer","d":1287846677,"b":[["t","Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.\n\nPerhaps it should be possible to include short (<=512 bytes) message for each transaction.\nThe message could be encrypted with public/private keys so only the receiver can see its contents.\n\nWhat do You think ?\n\nPS.\nI might be wrong, but the messages could also be used to increase randomness of hashing process by the way, couldn't they ? If not, never mind."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18205#msg18205"},{"f":"grondilu","d":1287847714,"b":[["q","Bitcoin is great, but it misses one thing that usual bank transfers have: payment title.\n\nPerhaps it should be possible to include short (<=512 bytes) message for each transaction.\nThe message could be encrypted with public/private keys so only the receiver can see its contents.\n\nWhat do You think ?","Quote from: ShadowOfHarbringer on October 23, 2010, 03:11:17 PM"],["t","I red somewhere that the kind of keys used in the software supports signature, but not encryption.\n\nSince it is very easy to create a new bitcoin address for each transaction, a paiement label is not necessary.  Just use the bitcoin address as a reference for your message, and transmit it via email or any other way of communication."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18208#msg18208"},{"f":"ShadowOfHarbringer","d":1287848745,"b":[["q","a paiement label is not necessary.","Quote from: grondilu on October 23, 2010, 03:28:34 PM"],["t","Sure it is \"not necessary\" but still would be useful for people.\n\nPerhaps some people would like to keep one BTC address for some reasons.\nAlso bigger financial institutions won't really like the idea of different account number for each transation."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18211#msg18211"},{"f":"grondilu","d":1287850188,"b":[["q","> Quote from: ShadowOfHarbringer on October 23, 2010, 03:45:45 PM\n> > Quote from: grondilu on October 23, 2010, 03:28:34 PM\n> > a paiement label is not necessary.\n>\n> Sure it is \"not necessary\" but still would be useful for people.\n>\n> Perhaps some people would like to keep one BTC address for some reasons.\n> Also bigger financial institutions won't really like the idea of different account number for each transation.\n\nI don't think the keys should really be thought of as an account number per transaction. That logic I think is misleading. You can have millions of keys associated to one wallet / account.","Quote from: davidonpda on October 23, 2010, 04:03:03 PM"],["t","What about the increase of the block size, then ?\n\nEven if 512o per transaction is small, it might represent a significative amount since all has to be stored in the block chain."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18215#msg18215"},{"f":"ShadowOfHarbringer","d":1287853981,"b":[["q","What about the increase of the block size, then ?\nEven if 512o per transaction is small, it might represent a significative amount since all has to be stored in the block chain.","Quote from: grondilu on October 23, 2010, 04:09:48 PM"],["t","I will tell You what have i just done.\nI clicked \"quote\", copied the message and pasted it in a text file.\n\nThen, i have truncated the file to 512 bytes, and EDIT: GZIPPED  it. It now takes 329 bytes.\nNext, i have bzipped it. Now it takes 288 bytes.\n\nOf course, there is no need for such a long message. Let's try 384 bytes. I used lorem ipsum generator from here: http://lipsum.com/\nResults:"],["c","-rw-r--r--  1 user user  384 2010-10-23 19:09 ipsum.txt (uncompressed)\n-rw-r--r--  1 user user  274 2010-10-23 19:08 ipsum.txt.bz2 (bzip2)\n-rw-r--r--  1 user user  268 2010-10-23 19:10 ipsum.txt.gz (gzip)"],["t","I think that maximum ~260-280 bytes per transaction is not bad."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18228#msg18228"},{"f":"theymos","d":1287856564,"b":[["t","Like grondilu said, encryption isn't possible.\n\nIt's possible to modify Bitcoin to send messages. Just create transactions that start with something like this:"],["c","BTCMESSAGEv1--This is a message OP_DROP "],["t","The network will accept these, but I don't think your recipient will recognize them unless he is also using your modified Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18231#msg18231"},{"f":"ShadowOfHarbringer","d":1287856783,"b":[["t","I found something interesting.\n\nhttp://stackoverflow.com/questions/1138345/best-compression-algorithm-for-short-text-strings\n\nThere is a small OS project on github, which does good compression of short text strings.\nhttp://github.com/antirez/smaz"],["q","'This is a small string' compressed by 50%\n'foobar' compressed by 34%\n'the end' compressed by 58%\n'not-a-g00d-Exampl333' enlarged by 15%\n'Smaz is a simple compression library' compressed by 39%\n'Nothing is more difficult, and therefore more precious, than to be able to decide' compressed by 49%\n'this is an example of what works very well with smaz' compressed by 49%\n'1000 numbers 2000 will 10 20 30 compress very little' compressed by 10%\n\nIn general, lowercase English will work very well. It will suck with a lot\nof numbers inside the strings. Other languages are compressed pretty well too,\nthe following is Italian, not very similar to English but still compressible\nby smaz:\n\n'Nel mezzo del cammin di nostra vita, mi ritrovai in una selva oscura' compressed by 33%\n'Mi illumino di immenso' compressed by 37%\n'L'autore di questa libreria vive in Sicilia' compressed by 28%\n\nIt can compress URLS pretty well:\n\n'http://google.com' compressed by 59%\n'http://programming.reddit.com' compressed by 52%\n'http://github.com/antirez/smaz/tree/master' compressed by 46%","Quote"],["t","So we could further get the 384 bytes down to <200 or <175 bytes."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18233#msg18233"},{"f":"grondilu","d":1287857261,"b":[["t","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.\n\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.\n\nEdit.  I have a funny idea.  Imagine that numeric precision is increased way beyond 8 decimals, say 128 decimals for instance.\n\nWhat about using those decimals to code your message ?  Somehow you would have a \"natural fee\" for this service, and we won't have to modify anything from the protocol.\n\nEdit #2.  Gosh I LOVE this idea Smiley\n\nEdit #3.  We don't need 128 decimals.  Correct me if I'm wrong, but with 32 decimals you can code a 17 characters-longed uncompressed message in a 64 characters set.  (32*log(10)/log(64)  = 7.717)"]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18237#msg18237"},{"f":"ShadowOfHarbringer","d":1287858836,"b":[["q","I 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.","Quote from: grondilu on October 23, 2010, 06:07:41 PM"],["t","Yeah, I'm curious of that too."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18244#msg18244"},{"f":"satoshi","d":1287860577,"b":[["t","ECDSA can't encrypt messages, only sign signatures.\n\nIt would be unwise to have permanently recorded plaintext messages for everyone to see.  It would be an accident waiting to happen.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1545.msg18250#msg18250","s":1,"n":496,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/496/"}]},{"id":"p240","k":"p","s":"bitcointalk","t":"Some testing that I did on the testnetwork, my findings.","u":"https://bitcointalk.org/index.php?topic=1668","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/240/","m":[{"f":"Anonymous","d":1289000640,"b":[["t","adgadg "]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20278#msg20278","sj":"af"},{"f":"theymos","d":1289002450,"b":[["t","Spent transactions can be forgotten (though they currently aren't). That would prevent your sending coins back and forth from having a big impact on block size.\n\nThe transaction inclusion issue is fixed by increasing fees and making non-generators aware of the current blocksize. The fees after 250KB should increase faster.\n\nI think this attack would be more difficult on the real network because of the differing fee schedules. You'll have half of the network including your transactions and half of the network not including them. Half of the network considers a block \"filled\" at 500KB, and half at the network-enforced maximum of 1MB."],["q","Or maybe the entire size exceeded the 1 MB limit.","Quote"],["t","You're right. That message is produced if fees bring a transaction over your balance, and the fee when the blocksize is over 500 KB is 21 million BTC. You wouldn't have gotten that if you weren't generating, since you wouldn't have known the current blocksize."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20283#msg20283"},{"f":"theymos","d":1289066899,"b":[["q","Even if you made non-generators aware of the current blocksize, by doing this you could force everyone to pay transaction fees.","Quote from: davidonpda on November 06, 2010, 05:57:50 PM"],["t","There's no avoiding that. An attacker will always be able to create millions of transactions; the only defense is fees on every transaction. Bitcoin was never intended to remain free forever."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20355#msg20355"},{"f":"Gavin Andresen","d":1289096069,"b":[["t","Actually... prioritizing free transactions based on both amount and their \"age\" should make this attack toothless.\n\nThe basic idea is that if you're spamming lots of small free transactions, you'll be creating lots of brand-new \"pennies\" (you'll take an old 50BTC generated transaction, then split off a penny and get a penny and 49.99 change.  Then split that 49.99 to get another penny, and so on and so on).\n\nSorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (\"old money\") are given priority would let normal transactions go through.\n\nThe spammy transactions would still take up network bandwidth and disk space; if that becomes a problem, nodes could just ignore small, new transactions (not relay them) and let the nodes that are doing the spamming queue up and rebroadcast the transactions.  They'd trickle into the network eventually, and in the meantime the spammer's bit-pennies would be tied up."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20419#msg20419"},{"f":"ByteCoin","d":1289183482,"b":[["q","Actually... prioritizing free transactions based on both amount and their \"age\" should make this attack toothless.\n\nSorting pending free transactions so that larger-value transactions and free transactions with inputs deep in the block chain (\"old money\") are given priority would let normal transactions go through.","Quote from: gavinandresen on November 07, 2010, 02:14:29 AM"],["t","Prioritizing larger value transactions doesn't really solve the problem because it's perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.\n\nIf you prioritize older transactions, people would be incentivised to split their bitcoin holdings in such a fashion as to ensure that they do not generate significant amounts of change when they buy things with bitcoins. If you hold your bitcoins in powers of 2 * 0.01 then you can pay for anything you can aford with no change and the least fragmentation. Of course after spending the money you have to rebalance your holdings as soon as possible. The best way to do this is not immediately obvious to me. Possibly under certain circumstances it might be advantageous to generate change as long as you could specify how you wanted it split up. Possibly powers of 3 might be best for multiple purchases.\nAnyway, the end effect would be that transactions would have more ins and outs. Probably the average number of ins and outs would be some very small multiple (or large fraction) of the log of the number of bitcoin pennies in the transaction. I estimate that this might increase the average transactions size by over 10 times.   \n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20570#msg20570"},{"f":"Gavin Andresen","d":1289260657,"b":[["q","Prioritizing larger value transactions doesn't really solve the problem because it's perfectly possible to spam by sending large amounts of bitcoin from one of your addresses to another ad infinitum.","Quote from: ByteCoin on November 08, 2010, 02:31:22 AM"],["t","No, you can't, because every time you send them they become \"new\", and the priority is age multiplied by amount:"],["c","// Priority is sum(valuein * age) / txsize"],["t","  (valuein is the size of the bitcoin input, age is # of blocks deep, and txsize is the number of bytes the transaction takes up)"],["q","If you prioritize older transactions, people would be incentivised to split their bitcoin holdings in such a fashion as to ensure that they do not generate significant amounts of change when they buy things with bitcoins. If you hold your bitcoins in powers of 2 * 0.01 then you can pay for anything you can aford with no change and the least fragmentation. Of course after spending the money you have to rebalance your holdings as soon as possible. The best way to do this is not immediately obvious to me. Possibly under certain circumstances it might be advantageous to generate change as long as you could specify how you wanted it split up. Possibly powers of 3 might be best for multiple purchases.\nAnyway, the end effect would be that transactions would have more ins and outs. Probably the average number of ins and outs would be some very small multiple (or large fraction) of the log of the number of bitcoin pennies in the transaction. I estimate that this might increase the average transactions size by over 10 times.  ","Quote"],["t","Ummm... the more you mess around with the coins in your wallet, the newer they are, and the lower their priority (relative to everybody else who might want to get their transactions into the next block).  I haven't thought deeply about it, but I bet simply leaving your coins as they are and making change as necessary will work out best.  But please, create your own client and try to break things on the test network!"]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20778#msg20778"},{"f":"ByteCoin","d":1289262632,"b":[["t","The priority calculation you suggest would be a considerable improvement over the current system of first-come-first-served. If it were implemented then I think it's likely that the incentives outlined in my post would cease to operate and that average transaction sizes would not increase significantly.\n\nThere may be some incentive to break up large change if it is believe that spending it is not likely to be required in the near future, in order to ensure that coin holdings of adequate power always exist. It's hard to do this correctly as it requires the forcasting of both priority and spending far in advance.\n\nIf there were many contending transactions there would be a tendancy (all else being equal) to retard blocks with multiple ins because scriptSigs are so much larger than scriptPubKeys. I haven't an opinion whether this is bad or not.\n\nI think there may be some small distortions to the value of older transactions on the grounds that they are so powerful. People might be motivated to \"exchange\" the private key instead of performing a transaction in order to maintain the power of these old transactions while still \"spending\" them without actually spending them. This would be nothing but advantage to bitcoin as these key exchages don't show up in the block chain.\n\nAlso unfortunately, there would be the incentive for the following undesirable behaviour:\nSuppose someone has just been paid a large sum of bitcoin (1000BTC)  and needs to make some small payments(1BTC). They also have recently been paid some smaller amouts of bitcoin(0.5BTC). If they try to pay the 1BTC debts using their 0.5BTC credits then their transactions have very low priority. This transaction can be represented as 2 * 0.5 BTC = 1BTC\nIf however they include the 1000BTC then the transaction has a much higher priority and it's not really wasting any significant accumulated age-derived power of the recently received 1000BTC. This transaction can be represented as 1000BTC + 2 *  0.5BTC = 1BTC + 1000BTC. This would approximately double the size of this sort of transaction.  "],["q","But please, create your own client and try to break things on the test network!","Quote from: gavinandresen on November 08, 2010, 11:57:37 PM"],["t","No incentive to do so thanks!\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1668.msg20793#msg20793"},{"f":"Gavin Andresen","d":1289331398,"b":[["t","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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg21057#msg21057"},{"f":"satoshi","d":1289690726,"b":[["t","Thank you for limiting flood tests to the testnet.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896","s":1,"n":501,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/501/"},{"f":"ByteCoin","d":1289692511,"b":[["q","In 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.","Quote from: satoshi on November 13, 2010, 11:25:26 PM"],["t","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.\n\nUnless I misunderstand, it looks to me like the current logic is more likely to spend the accumulated priority of older transactions. It's a minor point however.\n\nGaming 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!\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899"},{"f":"satoshi","d":1289753599,"b":[["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.","Quote from: ByteCoin on November 13, 2010, 11:55:11 PM"],["t","You should use at least some priority in case a flood comes along before the next block.\n\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."],["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!","Quote"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959","s":1,"n":503,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/503/"}]},{"id":"p241","k":"p","s":"bitcointalk","t":"Wikileaks contact info?","u":"https://bitcointalk.org/index.php?topic=1735","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/241/","m":[{"f":"genjix","d":1289393356,"b":[["t","Hey,\n\nI wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.\nhttp://wikileaks.org/media/support.html\n\nAnyone know where to send a message to them?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21271#msg21271"},{"f":"caveden","d":1289394942,"b":[["t","Bitcoins could be really useful to them. Good idea.\nI don't know the answer to your question though, sorry."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21279#msg21279"},{"f":"caveden","d":1289395444,"b":[["t","Well, you know, if you don't find a proper contact, you can always send an ancient letter, made from paper. Cheesy\n\nThey have a postal address on this page you linked."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21281#msg21281"},{"f":"ShadowOfHarbringer","d":1289395680,"b":[["t","Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.\n\nThis may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, holding back mainstream adoption.\n\nOf course i know that they (governments) will start fighting bitcoin at some point, but the later, the better. If we go mainstream first, then such efforts will be probably futile, and BTC will probably be unstoppable without shutting down whole internet."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21283#msg21283"},{"f":"Macho","d":1289396234,"b":[["t","I have their e-mail saved from when it was published ... it's wl-supporters@sunshinepress.org <mailto:wl-supporters@sunshinepress.org>\n\nTry it Wink It should work ..."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21285#msg21285"},{"f":"sturle","d":1289398362,"b":[["q","Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.","Quote from: ShadowOfHarbringer on November 10, 2010, 01:28:00 PM"],["t","By your logic the USA should forbid money.  At least on paper and metal, a lot of currencies, and money transfers to uncontrollable countries like Bermuda and Switzerland.  Perhaps go completely communist.  On a worldwide basis porn and gambling is a lot more controversial than Wikileaks.  Only China and Thailand censor Wikileaks.  A lot more countries censor porn and gambling sites.  I don't think this will make the US government blink."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21292#msg21292"},{"f":"Anonymous","d":1289398702,"b":[["t","Contrary to popular opinion it is not illegal to create your own currency. If they try to claim there is something illegal in the mere act of transferring value or bits of data they will look ridiculous. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21293#msg21293"},{"f":"ShadowOfHarbringer","d":1289398849,"b":[["q","> Quote from: ShadowOfHarbringer on November 10, 2010, 01:28:00 PM\n> Yeah this may be good for wikileaks, but not nocessarily good for Bitcoin. If bitcoin becomes publicly associated with wikileaks before going semi-mainstream, then it will be viewed by the \"ruling class\" (read: US government) as a tool for doing money laundering and another \"gray\" buisnesses.\nBy your logic the USA should forbid money.  At least on paper and metal, a lot of currencies, and money transfers to uncontrollable countries like Bermuda and Switzerland.  Perhaps go completely communist.  On a worldwide basis porn and gambling is a lot more controversial than Wikileaks.  Only China and Thailand censor Wikileaks.  A lot more countries censor porn and gambling sites.  I don't think this will make the US government blink.","Quote from: sturle on November 10, 2010, 02:12:42 PM"],["t","I hope you're right."],["q","Contrary to popular opinion it is not illegal to create your own currency. If they try to claim there is something illegal in the mere act of transferring value or bits of data they will look ridiculous.","Quote from: Anonymous on November 10, 2010, 02:18:22 PM"],["t","Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21295#msg21295"},{"f":"ribuck","d":1289402344,"b":[["q","You can send a paper letter to an address?","Quote from: davidonpda on November 10, 2010, 02:39:01 PM"],["t","Apparently so. See \"How do I send a letter? <http://quezi.com/3336>\""]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21306#msg21306"},{"f":"sturle","d":1289403671,"b":[["q","Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.","Quote from: ShadowOfHarbringer on November 10, 2010, 02:20:49 PM"],["t","Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed.  It's very much the same with any goods."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21310#msg21310"},{"f":"JohnDoe","d":1289406501,"b":[["q","This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, holding back mainstream adoption.\n\nOf course i know that they (governments) will start fighting bitcoin at some point, but the later, the better. If we go mainstream first, then such efforts will be probably futile, and BTC will probably be unstoppable without shutting down whole internet.","Quote from: ShadowOfHarbringer on November 10, 2010, 01:28:00 PM"],["t","I think that governments trying to fight Bitcoin would actually help in adoption because of the Streisand effect <http://en.wikipedia.org/wiki/Streisand_effect>."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21322#msg21322"},{"f":"Anonymous","d":1289426057,"b":[["t","Bitcoin makes it possible to secede from government. They dont like it when the slaves do that. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21378#msg21378"},{"f":"Anonymous","d":1289426761,"b":[["q","> Quote from: davidonpda on November 10, 2010, 02:39:01 PM\n> You can send a paper letter to an address?\n\nApparently so. See \"How do I send a letter? <http://quezi.com/3336>\"","Quote from: ribuck on November 10, 2010, 03:19:04 PM"],["t","Hahaha"],["q","5. Via Postal Mail\n\nYou can post a donation via good old fashion postal mail to:\n\nWikiLeaks\n(or any suitable name likely to avoid interception in your country)\nBOX 4080\nAustralia Post Office - University of Melbourne Branch\nVictoria 3052\nAustralia ","Quote"],["t","Thats about 2 hours away from me. I can post something for $0.50c so if you like write up something and link to it here and I will print it out.\n\nAn idea might be to set up a mybitcoin account and send them the login info with the letter.They would be more likely to accept if there is a few dollars already awaiting collection. Julian Assange is a fellow Aussie. Grin"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21384#msg21384"},{"f":"ShadowOfHarbringer","d":1289430488,"b":[["q","> Quote from: ShadowOfHarbringer on November 10, 2010, 02:20:49 PM\n> Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.\nExchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed.  It's very much the same with any goods.","Quote from: sturle on November 10, 2010, 03:41:11 PM"],["t","Actually, if i tell you that \"there is money in the safe of bank XXX\", that is information about whereabouts too.\nThe same if I tell you that there is some heroin (which is itself illegal) in the police storage facitilities.\n\nAnd all that informations are legal, the same as bittorrent should be legal, because it is only information about whereabouts of other information, which logically should be NEVER illegal.\nBut the governments together with media industry are trying hard to make BitTorrent (and all P2P in gerneral) illegal, in spite of obvious idiocy of such doing."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21404#msg21404"},{"f":"ShadowOfHarbringer","d":1289430670,"b":[["q","Bitcoin makes it possible to secede from government. They dont like it when the slaves do that. Cheesy","Quote from: Anonymous on November 10, 2010, 09:54:17 PM"],["t","Why do i feel more and more convinced that the internet era will end governments in the form we know them ? Tongue"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21405#msg21405"},{"f":"BitLex","d":1289430951,"b":[["q","This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, ...","Quote from: ShadowOfHarbringer on November 10, 2010, 01:28:00 PM"],["t","if they gonna fight it anyway, isn't it better the sooner they do?\nor do you want to invest (time/money/effort) into it first and have them fight it later?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21406#msg21406"},{"f":"da2ce7","d":1289433034,"b":[["t","I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it… scratch my back and I’ll scratch yours.\nI don’t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21412#msg21412"},{"f":"MoonShadow","d":1289433820,"b":[["q","> Quote from: ShadowOfHarbringer on November 10, 2010, 01:28:00 PM\n> This may make bitcoin be considered by governments as a serious threat, and they will start fighting it too soon, ...\nif they gonna fight it anyway, isn't it better the sooner they do?\nor do you want to invest (time/money/effort) into it first and have them fight it later?","Quote from: BitLex on November 10, 2010, 11:15:51 PM"],["t","The later the better.  The longer that governments wait to act, the stronger the bitcoin network grows, and the harder it becomes to harm it."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21415#msg21415"},{"f":"Anonymous","d":1289434365,"b":[["q","> Quote from: sturle on November 10, 2010, 03:41:11 PM\n> > Quote from: ShadowOfHarbringer on November 10, 2010, 02:20:49 PM\n> > Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.\n> Exchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed.  It's very much the same with any goods.\n\nActually, if i tell you that \"there is money in the safe of bank XXX\", that is information about whereabouts too.\nThe same if I tell you that there is some heroin (which is itself illegal) in the police storage facitilities.\n\nAnd all that informations are legal, the same as bittorrent should be legal, because it is only information about whereabouts of other information, which logically should be NEVER illegal.\nBut the governments together with media industry are trying hard to make BitTorrent (and all P2P in gerneral) illegal, in spite of obvious idiocy of such doing.","Quote from: ShadowOfHarbringer on November 10, 2010, 11:08:08 PM"],["t","Well,they can try. The problem for people who control things through having bigger guns is that you cant shoot bittorrent."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21416#msg21416"},{"f":"genjix","d":1289437865,"b":[["q","I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it… scratch my back and I’ll scratch yours.\nI don’t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.","Quote from: da2ce7 on November 10, 2010, 11:50:34 PM"],["t","I love this idea. Know that Julian Assange (the founder and head of Wikileaks) was a former Free Software programmer and wrote lots of cryptographic tools. He is very knowledgeable in this area himself and will understand Bitcoin technically."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21428#msg21428"},{"f":"MoonShadow","d":1289439502,"b":[["q","> Quote from: ShadowOfHarbringer on November 10, 2010, 02:20:49 PM\n> Well, they already claim that something like \"exchanging information about whereabouts of data\" (BitTorrent sites) is illegal, so why not this ? I see no large difference.\nExchanging information about the whereabouts of data is not illegal anywhere, as long as the data is legally acquired and distributed.  It's very much the same with any goods.","Quote from: sturle on November 10, 2010, 03:41:11 PM"],["t","Actually, that's not true.  Strong encryption, regardless of the nature of the information, is (rather rediculously) considered a 'munition' under US export law.  Depending on how a court looks at this law, it's either unconstitutional or the exportation of such encryption methods gets the sender sent to prison for violation of international trade bans on weapons.  So it's a pretty good thing that Bitcoin doesn't actually encrypt anything itself, but I'm not sure that a court would be savvy enough to know the differences."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21431#msg21431"},{"f":"MacRohard","d":1289439880,"b":[["q","Hey,\n\nI wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.\nhttp://wikileaks.org/media/support.html\n\nAnyone know where to send a message to them?","Quote from: genjix on November 10, 2010, 12:49:16 PM"],["t","Eh. Wikileaks is almost certainly run by the CIA anyway. I doubt they'll be interested."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21433#msg21433"},{"f":"Anonymous","d":1289443734,"b":[["q","> Quote from: genjix on November 10, 2010, 12:49:16 PM\n> Hey,\n>\n> I wanted to send a letter to Wikileaks about Bitcoin since unfortunately they've had several incidents where their funds have been seized in the past.\n> http://wikileaks.org/media/support.html\n>\n> Anyone know where to send a message to them?\n\nEh. Wikileaks is almost certainly run by the CIA anyway. I doubt they'll be interested.","Quote from: MacRohard on November 11, 2010, 01:44:40 AM"],["t","Thanks Adam Curry.  Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21444#msg21444"},{"f":"ShadowOfHarbringer","d":1289492698,"b":[["q","Well,they can try. The problem for people who control things through having bigger guns is that you cant shoot bittorrent.","Quote from: Anonymous on November 11, 2010, 12:12:45 AM"],["t","They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.\nThey (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg21527#msg21527"},{"f":"em3rgentOrdr","d":1290974053,"b":[["t","I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak.  Should we pool some money together to include with a letter?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25177#msg25177"},{"f":"farmer_boy","d":1290988096,"b":[["q","I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it… scratch my back and I’ll scratch yours.\nI don’t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.","Quote from: da2ce7 on November 10, 2010, 11:50:34 PM"],["t","There is nothing to be audited as far as an academic cryptographer would be concerned. For that to happen, the specification of Bitcoin would have to be of better quality. That needs to happen first and only when that is done, there is a chance someone will want to take a serious look.\n\nOnly the author or a volunteer could publish a specification of sufficient quality. It's not acceptable as a Master thesis subject on a respectable university, because there is no research involved, it's just \"work\". The \"coolness\" factor is of no interest there. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25237#msg25237"},{"f":"bober182","d":1290992602,"b":[["t","I'm going to go online tonight and talk to some Wikileaks staff see if they can start the ball rolling on the insides."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25251#msg25251"},{"f":"wumpus","d":1291035028,"b":[["q","> Quote from: da2ce7 on November 10, 2010, 11:50:34 PM\n> I was thinking about this overnight, Wikileaks has in-house cryptology and security experts; they could do an audit on the Bitcoin security and we could donate bitcon to pay for it… scratch my back and I’ll scratch yours.\n> I don’t know about the feasibility, but on the surface it sounds like it would be beneficial to both wikileaks and bitcoin.\nThere is nothing to be audited as far as an academic cryptographer would be concerned. For that to happen, the specification of Bitcoin would have to be of better quality. That needs to happen first and only when that is done, there is a chance someone will want to take a serious look.","Quote from: farmer_boy on November 28, 2010, 11:48:16 PM"],["t","Satoshi's paper is a good introduction I'd think.\n\nAnd another thing, I'm not sure about academic cryptographers, but in the 'real world' security auditing is regularly done on source code, or sometimes even without source code (either by reverse engineering or black box testing)."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25353#msg25353"},{"f":"mikegogulski","d":1291035713,"b":[["q","They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.\nThey (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.","Quote from: ShadowOfHarbringer on November 11, 2010, 04:24:58 PM"],["t","Screw big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.\n\nMy task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.\n\nBurn, Hollywod, burn."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25358#msg25358"},{"f":"bitcoinex","d":1291037372,"b":[["q","I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak.  Should we pool some money together to include with a letter?","Quote from: em3rgentOrdr on November 28, 2010, 07:54:13 PM"],["t","Currently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.\n\nAs the cables were published, the White House released a statement condemning their release. \"Such disclosures put at risk our diplomats, intelligence professionals, and people around the world who come to the US for assistance in promoting democracy and open government. By releasing stolen and classified documents, WikiLeaks has put at risk not only the cause of human rights but also the lives and work of these individuals.\"\n\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25360#msg25360"},{"f":"ShadowOfHarbringer","d":1291039020,"b":[["q","> Quote from: ShadowOfHarbringer on November 11, 2010, 04:24:58 PM\n> They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.\n> They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.\n\nScrew big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.\n\nMy task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.\n\nBurn, Hollywod, burn.","Quote from: mikegogulski on November 29, 2010, 01:01:53 PM"],["t","I'm only saying that it may be difficult for bitcoin to go mainstream, but i seriously doubt they can stop adoption in general.\nThey would have to shut down the internet entirely, which is not easy (possible breaking ICANN is not enough, we can always use alternative DNS roots)."],["q","> Quote from: em3rgentOrdr on November 28, 2010, 07:54:13 PM\n> I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak.  Should we pool some money together to include with a letter?\n\nCurrently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.","Quote from: bitcoinex on November 29, 2010, 01:29:32 PM"],["t","So far they have failed. I hope it stays that way."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25365#msg25365"},{"f":"Anonymous","d":1291039040,"b":[["t","Apparently someone did a massive ddos against wikileaks today.\n\nIn more inspiring news operation payback took down the warner bros website for a few hours and ifpi.org is currently unreachable.  Cheesy\n\nThe cable leak has been turned into a torrent file and is currently being mirrored on thousands of servers all over the world. The pirate bay's entire torrent database is available as a torrent you could fit on a 32gb flash drive.\n\nAll in all what has the government accomplished except to tread on an ants nest.  Lips sealed"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25366#msg25366"},{"f":"ShadowOfHarbringer","d":1291039125,"b":[["q","Apparently someone did a massive ddos against wikileaks today.","Quote from: Anonymous on November 29, 2010, 01:57:20 PM"],["t","Really is that so ? http://cablegate.wikileaks.org/ worked perfectly for me for the last 12 or 18 hours."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25367#msg25367"},{"f":"mikegogulski","d":1291040688,"b":[["q","> Quote from: mikegogulski on November 29, 2010, 01:01:53 PM\n> > Quote from: ShadowOfHarbringer on November 11, 2010, 04:24:58 PM\n> > They can't shoot bitcoin or bittorrent itself, but they can discourage big buisnesses from accepting bitcoin. And that can easily hold mainstream adoption even for tens of years.\n> > They (governments) are very good in this particularly. Large companies such as Google, Microsoft, Wal-mart etc are very susceptible to government regulations.\n>\n> Screw big business. Google, Microsoft and Wal-Mart can all eat flaming death as far as I'm concerned, creatures of state privilege as they are.\n>\n> My task, and where systems like Bitcoin can be helpful, is in making both government and big business irrelevant and obsolete.\n\nI'm only saying that it may be difficult for bitcoin to go mainstream, but i seriously doubt they can stop adoption in general.\nThey would have to shut down the internet entirely, which is not easy (possible breaking ICANN is not enough, we can always use alternative DNS roots).","Quote from: ShadowOfHarbringer on November 29, 2010, 01:57:00 PM"],["t","Gotcha. It's just a difference of emphasis, really.\n\nI believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.\n\nIf you're reading this, you're part of the vanguard building the new economy and the new world. Mainstream acceptance will come by weight of numbers and via network effects. Who ever heard of Wikileaks or Twitter four years ago? And today we've got Admiral Chairman-of-the-Joint-Fucking-Chiefs Mullen tweeting his dismay over Wikileaks -- no doubt via the intermediation of an office full of PR analysts and bureaucrats, at extremely low relative impact.\n\nBTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25371#msg25371"},{"f":"bitcoinex","d":1291041822,"b":[["q","> Quote from: bitcoinex on November 29, 2010, 01:29:32 PM\n> > Quote from: em3rgentOrdr on November 28, 2010, 07:54:13 PM\n> > I think we should try again to get WikiLeaks to accept bitcoin donation, as a thanks for their latest leak.  Should we pool some money together to include with a letter?\n>\n> Currently all intelligence services are working to smash wikileaks. I would not want to suddenly posthumously come into Al-Qaeda.\n\nSo far they have failed. I hope it stays that way.","Quote"],["t","As I understand the problem of state right now is that if wikileaks crew a long time does not appear in the network automation will send the AES key to wikileaks insurance file.\n\nBut damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25373#msg25373"},{"f":"ShadowOfHarbringer","d":1291042442,"b":[["q","I believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.","Quote from: mikegogulski on November 29, 2010, 02:24:48 PM"],["t","I like that idea of Yours, however what i don't like about it is the amount of time it needs to become reality.\nHowever i guess we don't have any choice, as the \"old economy\" will never adapt - I concede with you there. Bankers & other people who gain from the current system will never resign of their false fraudulent dream world, unless it totally collapses itself first."],["q","BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help? Smiley","Quote from: mikegogulski on November 29, 2010, 02:24:48 PM"],["t","No need for that, they cannot really \"shut down the internet\". They would have to take all the physical equipment away from people - Linux servers, routers, switches, wires, cables etc. And that is not possible at all without some major disaster (nuclear war or something).\n\nThey cannot take our equipment from us, and with the equipment geeks will quickly build a new internet from the scratch. It's just a matter of little rewiring & changing configuration. Not so difficult as one would think."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25374#msg25374"},{"f":"ShadowOfHarbringer","d":1291042716,"b":[["q","But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.","Quote from: bitcoinex on November 29, 2010, 02:43:42 PM"],["t","That's probably because USA is not Soviet Russia (yet).\nThey started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.\n\nIf they torture or murder somebody from wikileaks, they really risk getting their asses kicked on the international arena."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25376#msg25376"},{"f":"bitcoinex","d":1291044519,"b":[["q","> Quote from: bitcoinex on November 29, 2010, 02:43:42 PM\n> But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.\n\nThat's probably because USA is not Soviet Russia (yet).\nThey started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.","Quote from: ShadowOfHarbringer on November 29, 2010, 02:58:36 PM"],["t","Come on, kill a few people to save tens or hundreds? Trifling matter, since all countries do."],["q","If they torture or murder somebody from wikileaks, they really risk getting their asses kicked on the international arena.","Quote"],["t","Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.\n\nSad but true."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25380#msg25380"},{"f":"ShadowOfHarbringer","d":1291045039,"b":[["q","Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.\n\nSad but true.","Quote from: bitcoinex on November 29, 2010, 03:28:39 PM"],["t","If that was so easy as You said, they would have done so long ago. Wikileaks is not here since yesterday.\n\nAlso, wikileaks has the encrypted insurance file already distrubuted among people long ago (God knows what it may contain ? perhaps 9/11 inside job proof ?). USA may be also afraid of that."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25382#msg25382"},{"f":"bitcoinex","d":1291045436,"b":[["q","> Quote from: bitcoinex on November 29, 2010, 03:28:39 PM\n> Again, remember the tortures at Guantanamo? The end justifies the means. Nobody stops reckon with the U.S. due to a couple of dead geeks.\n>\n> Sad but true.\n\nIf that was so easy as You said, they would have done so long ago. Wikileaks is not here since yesterday.","Quote from: ShadowOfHarbringer on November 29, 2010, 03:37:19 PM"],["t","But the pain in the ass it inflicts with the exponential progression."],["q","Also, wikileaks has the encrypted insurance file already distrubuted among people long ago (God knows what it may contain ? perhaps 9/11 inside job proof ?). USA may be also afraid of that.","Quote"],["t","File without the key is garbage. State can find out who have the key and find out what conditions it will be published."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25384#msg25384"},{"f":"mikegogulski","d":1291046645,"b":[["q","I like that idea of Yours, however what i don't like about it is the amount of time it needs to become reality.\nHowever i guess we don't have any choice, as the \"old economy\" will never adapt - I concede with you there. Bankers & other people who gain from the current system will never resign of their false fraudulent dream world, unless it totally collapses itself first.","Quote from: ShadowOfHarbringer on November 29, 2010, 02:54:02 PM"],["t","I don't like that aspect either. I want freedom by next Tuesday, damnit! This is an urgent problem!\n[/quote]"],["q","> Quote from: mikegogulski on November 29, 2010, 02:24:48 PM\n> BTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help? Smiley\n\nNo need for that, they cannot really \"shut down the internet\". They would have to take all the physical equipment away from people - Linux servers, routers, switches, wires, cables etc. And that is not possible at all without some major disaster (nuclear war or something).\n\nThey cannot take our equipment from us, and with the equipment geeks will quickly build a new internet from the scratch. It's just a matter of little rewiring & changing configuration. Not so difficult as one would think.","Quote from: ShadowOfHarbringer on November 29, 2010, 02:54:02 PM"],["t","It's a veeerry long shot, but US fiat could dictate all non-governmental telecom landings in the US and its territories shut down, and enforce it. A hundred soldiers at each of the two or three dozen major US traffic-switching nodes and the US internet implodes. A tactical nuke on MAE-West? YES WE CAN!\n\nOn top of that, the US military has the resources and intelligence necessary to sever the undersea fiber that carries almost all transcontinental internet traffic, plus the assets in place to accomplish immense comms disruption in all of the 100+ countries in which it maintains military bases.\n\nMind you, this is a doomsday scenario, and not likely. Destroying the internet would be suicide for the US government, as doing so would destroy Wall Street along with the remnant shreds of its reputation.\n\nAnyway, if it ever comes to it, you and I will build a new internet. End-to-end crypto will be mandatory everywhere. All links, all nodes, all sessions. And DNS will be distributed. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25385#msg25385"},{"f":"bitcoinex","d":1291047558,"b":[["t","Humane russian offer to torture a few people. Angry american are ready to unleash a nuclear war.\n\nWell, who is the devil? Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25387#msg25387"},{"f":"wumpus","d":1291047799,"b":[["q","> Quote from: ShadowOfHarbringer on November 29, 2010, 02:58:36 PM\n> > Quote from: bitcoinex on November 29, 2010, 02:43:42 PM\n> > But damaging torture can not be withstand. I'm curious why they is still free and may be freely interviewed.\n>\n> That's probably because USA is not Soviet Russia (yet).\n> They started censorship, but there is still long way from that to becoming a true totalitarian country like Russia.\n\nCome on, kill a few people to save tens or hundreds? Trifling matter, since all countries do.","Quote from: bitcoinex on November 29, 2010, 03:28:39 PM"],["t","Killing them will make martyrs of them... And will make the thing much and much worse than it is now. Currently, wikileaks gets a lot of flak from people that don't completely agree with what they are doing. As long as the US stays reasonable, it is fairly easy to ignore the whole thing. No matter what information wikileaks reveals, people will forget about it.\n\nBut if it happens that a Wikileaks member disappears or is killed, there will be books, movies, conspiracy stories, political movements etc... the whole thing will be very hard to contain, and the last thing the USA wants is to tilt the global opinion even more against them."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25388#msg25388"},{"f":"bitcoinex","d":1291048137,"b":[["t","No, I brought the murder as an example. In this case, nobody should be killed.\n\nThey need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25390#msg25390"},{"f":"wumpus","d":1291049030,"b":[["q","They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.","Quote from: bitcoinex on November 29, 2010, 04:28:57 PM"],["t","Yes but if they are tortured and they live to tell about it, it will have the same effect. Especially if they are abducted from some foreign European country. It's not like wikileaks is based in the US, it's an international organization with members everywhere. Also, wikileaks is a non-violent organisation, so using violence against them will be quite shocking (at least to European people), even more shocking than the leaks. It would be a media circus!"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25396#msg25396"},{"f":"kiba","d":1291049366,"b":[["t","Maybe somebody should sell robots that record activities of government agents for bitcoins.\n\nWe could have...\n\n\"YOUR LITTLE BROTHERS ARE WATCHING YOU!\"\n\nPlus, camera tend to prevent abuse of authority by policemen."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25398#msg25398"},{"f":"mikegogulski","d":1291050402,"b":[["q","Maybe somebody should sell robots that record activities of government agents for bitcoins.\n\n[...]\n\nPlus, camera tend to prevent abuse of authority by policemen.","Quote from: kiba on November 29, 2010, 04:49:26 PM"],["t","I've long believed that if we are to have government officials, they should be tailed 24/7 by public sensor robots. Or ridiculously hot young Asian boys. Either one."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25404#msg25404"},{"f":"ShadowOfHarbringer","d":1291052096,"b":[["q","File without the key is garbage. State can find out who have the key and find out what conditions it will be published.","Quote from: bitcoinex on November 29, 2010, 03:43:56 PM"],["t","Surely a lot of people have the key.\n\nGood luck finding them on TOR or freenet.\n(FYI: TOR is completely untrackable when connecting from one TOR node, to another TOR node, contrary to connecting to/from \"normal internet\" from/to TOR)."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25418#msg25418"},{"f":"ShadowOfHarbringer","d":1291052529,"b":[["q","No, I brought the murder as an example. In this case, nobody should be killed.\n\nThey need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.","Quote from: bitcoinex on November 29, 2010, 04:28:57 PM"],["t","As witchspace already pointed out, things that are easy in Soviet Russia are not necessarily so easy in \"normal\" semi-democratic world.\n\nThere are many problems:\n1. The matryr thing - as explained by witchspace\n2. Streissand Effect <http://\"http://en.wikipedia.org/wiki/Streisand_effect> (similiar to creating martyrs). The more You want to censor something , the more people will download it.\n3. The wikileaks insurance (random people around the world may have the key and they will release it when time comes\n4. Bad PR for USA if they start shooting people from wikileaks. I mean what would be the difference between them and Russia/China if they do this ? None. This could further break diplomatic relations with (semi)democratic countries."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25423#msg25423"},{"f":"mikegogulski","d":1291057478,"b":[["q","... Soviet Russia ...","Quote from: bitcoinex on November 29, 2010, 04:28:57 PM"],["t","In Soviet Russia, coin bit you!\n\n(sorry)"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25436#msg25436"},{"f":"Anonymous","d":1291067541,"b":[["q","> Quote from: kiba on November 29, 2010, 04:49:26 PM\n> Maybe somebody should sell robots that record activities of government agents for bitcoins.\n>\n> [...]\n>\n> Plus, camera tend to prevent abuse of authority by policemen.\n\nI've long believed that if we are to have government officials, they should be tailed 24/7 by public sensor robots. Or ridiculously hot young Asian boys. Either one.","Quote from: mikegogulski on November 29, 2010, 05:06:42 PM"],["t","haha that is a great idea.\n\nThese people think they can hide amongst the beauracracy and claim \"im just doing my job\". Ive got news for them. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25480#msg25480"},{"f":"Anonymous","d":1291070167,"b":[["t","They forget that they can be tortured too.\n\n Wink"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25501#msg25501"},{"f":"Anonymous","d":1291073511,"b":[["q","> Quote from: Anonymous on November 29, 2010, 01:57:20 PM\n> Apparently someone did a massive ddos against wikileaks today.\n\nReally is that so ? http://cablegate.wikileaks.org/ worked perfectly for me for the last 12 or 18 hours.","Quote from: ShadowOfHarbringer on November 29, 2010, 01:58:45 PM"],["t","http://www.wired.com/threatlevel/2010/11/wikileaks-attack/"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25520#msg25520"},{"f":"Bruce Wagner","d":1291074847,"b":[["q","Anyone know where to send a message to them?","Quote from: genjix on November 10, 2010, 12:49:16 PM"],["t","Sorry.   Did we ever find any contact information for Wikileaks, other than their postal mailbox....?\n\nI've added Wikileaks to our \"target list\" on BitcoinPromote.com <http://BitcoinPromote.com>"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25525#msg25525"},{"f":"bober182","d":1291084020,"b":[["t","I have some of the staff on IRC."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25592#msg25592"},{"f":"kiba","d":1291084287,"b":[["q","I have some of the staff on IRC.","Quote from: bober182 on November 30, 2010, 02:27:00 AM"],["t","Where? Freenode?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25593#msg25593"},{"f":"jgarzik","d":1291084816,"b":[["t","This does not seem like the best time to be creating some sort of wikileaks-bitcoin connection."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25595#msg25595"},{"f":"bober182","d":1291085450,"b":[["t","They run there own anonymous IRC server.\nchat.wikileaks.org port 9999 i think or the secure one."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25597#msg25597"},{"f":"bitcoinex","d":1291092729,"b":[["q","> Quote from: bitcoinex on November 29, 2010, 04:28:57 PM\n> No, I brought the murder as an example. In this case, nobody should be killed.\n>\n> They need just threat of torture. Then the confiscation of computers, information, check sources, searches and arrests. And it's over.\n\nAs witchspace already pointed out, things that are easy in Soviet Russia are not necessarily so easy in \"normal\" semi-democratic world.\n\nThere are many problems:\n1. The matryr thing - as explained by witchspace\n2. Streissand Effect <http://\"http://en.wikipedia.org/wiki/Streisand_effect> (similiar to creating martyrs). The more You want to censor something , the more people will download it.\n3. The wikileaks insurance (random people around the world may have the key and they will release it when time comes\n4. Bad PR for USA if they start shooting people from wikileaks. I mean what would be the difference between them and Russia/China if they do this ? None. This could further break diplomatic relations with (semi)democratic countries.","Quote from: ShadowOfHarbringer on November 29, 2010, 05:42:09 PM"],["t","http://en.wikipedia.org/wiki/Guantanamo_Bay_detention_camp (grep torture)\n\nYou joined to protest on the streets or spent at home with your computer?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25639#msg25639"},{"f":"farmer_boy","d":1291094886,"b":[["q","You joined to protest on streets or spent at home with your computer?","Quote from: bitcoinex on November 30, 2010, 04:52:09 AM"],["t","Can you explain the purpose of going into the streets? A minority will only go into the streets. Even if a majority would go into the streets (which has never happened before, AFAIK), the government will simply state that it was a minority.\n\nBefore the government had good riot control weapons demonstrations had the option of escalating and actually overthrowing the government in the worst case. That simply is not the case anymore. People have no weapons and are literally without power.\n\nThe same money they pay in taxes will get them killed if they oppose the government too much. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25645#msg25645"},{"f":"bober182","d":1291095853,"b":[["t","Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25649#msg25649"},{"f":"em3rgentOrdr","d":1291098656,"b":[["q","Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real.","Quote from: bober182 on November 30, 2010, 05:44:13 AM"],["t","When will all these tuition strikers learn about Wikiversity <http://en.wikiversity.org/wiki/Wikiversity:Main_Page>?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25662#msg25662"},{"f":"farmer_boy","d":1291098840,"b":[["q","Err Huge protest in Greece in 2008. Huge protest now in UK over the student cuts. I think they know its a majority and also the France strikes were pretty popular. Your minority government cover up idea is not real.","Quote from: bober182 on November 30, 2010, 05:44:13 AM"],["t"," The truck drivers in Greece got fucked over in the end. The people in France lost. Don't think it will go different in the UK. As far as I am concerned you are only supporting my point. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25663#msg25663"},{"f":"MoonShadow","d":1291099369,"b":[["q","The same money they pay in taxes will get them killed if they oppose the government too much.","Quote from: farmer_boy on November 30, 2010, 05:28:06 AM"],["t","Young man, you seriously overestimate the power of an unpopular government.  The greatest tool of control available to any government is the meme that the government represents the will of the people, followed closely by the meme that the government's collective force exceeds that of those who would oppose it.  Vary rarely has either of those conditions actually been proven true once put to the test."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25668#msg25668"},{"f":"kiba","d":1291099625,"b":[["t","Protests are weak and least likely to do anything.\n\nAll you do is put up signs and gather in a large rally.....that does nothing."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25669#msg25669"},{"f":"MoonShadow","d":1291100223,"b":[["q","Protests are weak and least likely to do anything.\n\nAll you do is put up signs and gather in a large rally.....that does nothing.","Quote from: kiba on November 30, 2010, 06:47:05 AM"],["t","Mostly, but not quite.  Rallies also help to combat the first meme that I mentioned above by dispelling the belief that those who quietly oppose the ruling class are part of a impotently small minority.  "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25673#msg25673"},{"f":"bober182","d":1291102800,"b":[["t","Fine\nSpanish Civil War."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25676#msg25676"},{"f":"farmer_boy","d":1291142616,"b":[["q","Fine\nSpanish Civil War.","Quote from: bober182 on November 30, 2010, 07:40:00 AM"],["t","I already said that there was a time in which demonstrations could have consequences for those in power. That time is over.\n\nAnother example: look at the nuclear waste transports through Germany. It took 75 hours to travel a distance which should be more like 10 hours or so. The only thing which was displayed is that there are a lot of people that don't like nuclear waste, but the objective of the government was still achieved."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25792#msg25792"},{"f":"bitcoinex","d":1291143217,"b":[["q","> Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> You joined to protest on streets or spent at home with your computer?\nCan you explain the purpose of going into the streets?","Quote from: farmer_boy on November 30, 2010, 05:28:06 AM"],["t","The aim is to show that you have a lot people and you are committed.\n\nSo. You're not going to deny human rights violations on the Guantanamo base ? And nothing happened!\n\nI think if something happens with wikileaks crew nothing to happens too. The more that citizens are also no consensus on the good they do or not and it is also advantageous to the government."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25796#msg25796"},{"f":"wumpus","d":1291144089,"b":[["q","http://en.wikipedia.org/wiki/Guantanamo_Bay_detention_camp (grep torture)\n\nYou joined to protest on the streets or spent at home with your computer?","Quote from: bitcoinex on November 30, 2010, 04:52:09 AM"],["t","Well, those are prisoners taken in Afghanistan and Iraq.  It would be different with a citizen of our own country."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25804#msg25804"},{"f":"bitcoinex","d":1291145196,"b":[["q","> Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> http://en.wikipedia.org/wiki/Guantanamo_Bay_detention_camp (grep torture)\n>\n> You joined to protest on the streets or spent at home with your computer?\nWell, those are prisoners taken in Afghanistan and Iraq.  It would be different with a citizen of our own country.","Quote from: witchspace on November 30, 2010, 07:08:09 PM"],["t","Assange are also not citizen of the U.S.!"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25809#msg25809"},{"f":"wumpus","d":1291145539,"b":[["q","> Quote from: witchspace on November 30, 2010, 07:08:09 PM\n> > Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> > http://en.wikipedia.org/wiki/Guantanamo_Bay_detention_camp (grep torture)\n> >\n> > You joined to protest on the streets or spent at home with your computer?\n> Well, those are prisoners taken in Afghanistan and Iraq.  It would be different with a citizen of our own country.\n\nAssange are also not citizen of the U.S.!","Quote from: bitcoinex on November 30, 2010, 07:26:36 PM"],["t","I know Smiley I'm neither. But if the U.S. went kidnapping people here and then torturing them, we'd be very shocked."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25811#msg25811"},{"f":"farmer_boy","d":1291145655,"b":[["q","> Quote from: farmer_boy on November 30, 2010, 05:28:06 AM\n> > Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> > You joined to protest on streets or spent at home with your computer?\n> Can you explain the purpose of going into the streets?\n\nThe aim is to show that you have a lot people and you are committed.","Quote from: bitcoinex on November 30, 2010, 06:53:37 PM"],["t","Committed to do what? If you cannot touch the leaders in a meaningful way, it is pointless.\n\nLet's take a look at Iran. A large part of the world does not agree with their actions of developing the exact same technology they already have. The CIA could demonstrate, but they can also just blow up a few nuclear scientists (which is likely what they have done). The credo \"might is right\" of the Nazi's is spot on. No might, no right."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25813#msg25813"},{"f":"bitcoinex","d":1291146230,"b":[["q","> Quote from: bitcoinex on November 30, 2010, 07:26:36 PM\n> > Quote from: witchspace on November 30, 2010, 07:08:09 PM\n> > > Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> > > http://en.wikipedia.org/wiki/Guantanamo_Bay_detention_camp (grep torture)\n> > >\n> > > You joined to protest on the streets or spent at home with your computer?\n> > Well, those are prisoners taken in Afghanistan and Iraq.  It would be different with a citizen of our own country.\n>\n> Assange are also not citizen of the U.S.!\nI know Smiley I'm neither. But if the U.S. went kidnapping people here and then torturing them, we'd be very shocked.","Quote from: witchspace on November 30, 2010, 07:32:19 PM"],["t","Ok, I agree: torturing of dirty afghans is ok, but australians is savagery."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25815#msg25815"},{"f":"bitcoinex","d":1291146479,"b":[["q","> Quote from: bitcoinex on November 30, 2010, 06:53:37 PM\n> > Quote from: farmer_boy on November 30, 2010, 05:28:06 AM\n> > > Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> > > You joined to protest on streets or spent at home with your computer?\n> > Can you explain the purpose of going into the streets?\n>\n> The aim is to show that you have a lot people and you are committed.\nCommitted to do what? If you cannot touch the leaders in a meaningful way, it is pointless.","Quote from: farmer_boy on November 30, 2010, 07:34:15 PM"],["t","To starting an armed struggle against the authorities. In this case, blood is spilled.\n\nThe street protests means that."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25818#msg25818"},{"f":"kiba","d":1291146878,"b":[["q","To starting an armed struggle against the authorities. In this case, blood is spilled.\n\nThe street protests means that.","Quote from: bitcoinex on November 30, 2010, 07:47:59 PM"],["t","If you want to die against military trained killers, good luck with that.\n\nWhat you need to do is:\n\n1. Undermine their credibility.\n2. Reduce dependence on the state.\n3. Increase your credibility.\n\nRebellions will likely be crushed. Even if you succeed, a power-hungry demagogue will rise to power and make your life even worser. Don't count on it."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25820#msg25820"},{"f":"farmer_boy","d":1291147798,"b":[["q","> Quote from: farmer_boy on November 30, 2010, 07:34:15 PM\n> > Quote from: bitcoinex on November 30, 2010, 06:53:37 PM\n> > > Quote from: farmer_boy on November 30, 2010, 05:28:06 AM\n> > > > Quote from: bitcoinex on November 30, 2010, 04:52:09 AM\n> > > > You joined to protest on streets or spent at home with your computer?\n> > > Can you explain the purpose of going into the streets?\n> >\n> > The aim is to show that you have a lot people and you are committed.\n> Committed to do what? If you cannot touch the leaders in a meaningful way, it is pointless.\n\nTo starting an armed struggle against the authorities. In this case, blood is spilled.\n\nThe street protests means that.","Quote from: bitcoinex on November 30, 2010, 07:47:59 PM"],["t","Oh, I imagine the government must be really scared of trying to attack its population with the most modern weapons money can buy. An armed struggle will just destabilize the country, but will not have any effect on the government if they want (look at dictatorships), unless the military decides to stop supporting the government (which is why unmanned vehicles are getting so popular).\n\nWe are going to a society in which the president can select all the demonstrators from a database (automatically based on camera data, of course), press one button and kill all of them. This might be done by sending missiles, but it could also be done by analysing the DNA, finding a biochemical agent which mysteriously kills a particular part of the population of just one specific individual (they can create flying machines the size of a musquito already that no doubt could also be equipped with some untraceable poison). You can do it slowly enough, and the people will never notice what hit them. You also don't have to completely kill them, you just have to weaken them. For an example of that look at the presidential candidate of some Eastern-Europe country that was poisoned.\n\nThis might sound radical, but I am not the one who invented the every increasing more efficient weaponry on which the US (and other nations) spend about a trillion dollars a year. Everything in the previous paragraph is technically already possible, and 80% is probably already implemented or could be operational in a year after the system is desired. Systems of control like that simply have never existed before in history.\n\nIn a country in which there exists an asymmetric power balance between large parts of the population and the government, you get tyranny. I am not suggesting that everyone should have access to their own nuclear bomb, but owning a gun or even a tank (if lots of people in the community vouch for you for example) should be perfectly reasonable and perhaps even mandatory. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25825#msg25825"},{"f":"bitcoinex","d":1291219990,"b":[["q","> Quote from: bitcoinex on November 30, 2010, 07:47:59 PM\n> To starting an armed struggle against the authorities. In this case, blood is spilled.\n>\n> The street protests means that.\n\nIf you want to die against military trained killers, good luck with that.","Quote from: kiba on November 30, 2010, 07:54:38 PM"],["t","Willingness to die is not the same thing that die."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25926#msg25926"},{"f":"kiba","d":1291221320,"b":[["q","> Quote from: kiba on November 30, 2010, 07:54:38 PM\n> > Quote from: bitcoinex on November 30, 2010, 07:47:59 PM\n> > To starting an armed struggle against the authorities. In this case, blood is spilled.\n> >\n> > The street protests means that.\n>\n> If you want to die against military trained killers, good luck with that.\n\nWillingness to die is not the same thing that die.","Quote from: bitcoinex on December 01, 2010, 04:13:10 PM"],["t","A million thing can go wrong..."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25933#msg25933"},{"f":"ShadowOfHarbringer","d":1291233272,"b":[["t","I feel a disturbance in the force...\n\nIs it a revolution coming ?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg25979#msg25979"},{"f":"farmer_boy","d":1291239837,"b":[["q","I feel a disturbance in the force...\n\nIs it a revolution coming ?","Quote from: ShadowOfHarbringer on December 01, 2010, 07:54:32 PM"],["t","I think you need to check your Feel-Oh-Meter.  Wink"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26027#msg26027"},{"f":"bober182","d":1291267316,"b":[["t","Talk to one of the members on the board of directors who has met with Julian he said he likes the idea and will pass it around."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26142#msg26142"},{"f":"Anonymous","d":1291268836,"b":[["q","Talk to one of the members on the board of directors who has met with Julian he said he likes the idea and will pass it around.","Quote from: bober182 on December 02, 2010, 05:21:56 AM"],["t","Thats great!. Did you see the asshats added him to the interpol most wanted list? Some stupid politician even asked for his execution for treason. The idiotic part is that hes not even American  Undecided   Stupid populism is stupid.\n\nIve heard the next leak will embarrass a major bank in the US .  It would be ironic if they started accepting bitcoin before that happens. Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26148#msg26148"},{"f":"bober182","d":1291270291,"b":[["t","It would be awesome."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26156#msg26156"},{"f":"em3rgentOrdr","d":1291381751,"b":[["t","Fortunately, bitcoin is a distributed system, so it doesn't matter if they take out   Undecided"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26399#msg26399"},{"f":"wumpus","d":1291452479,"b":[["t","Paypal just blocked them, and they're trying to get other US banks do the same. This would be a great moment to open bitcoin donations."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26737#msg26737"},{"f":"S3052","d":1291453061,"b":[["t","as much as what's going on with wikileaks is not right,\ndo we really think it makes sense to push bitcoins into wikileaks is making sense in the current environment?\ni am scared that this poses a big risk for bitcoins to consciously go against too many and too big enemies\n\nIt would potentially be much better to first make bitcoinbe far more widespread and accepted in a safe way vs going against the big ones already now"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26738#msg26738"},{"f":"kiba","d":1291453424,"b":[["q","as much as what's going on with wikileaks is not right,\ndo we really think it makes sense to push bitcoins into wikileaks is making sense in the current environment?\ni am scared that this poses a big risk for bitcoins to consciously go against too many and too big enemies\n\nIt would potentially be much better to first make bitcoinbe far more widespread and accepted in a safe way vs going against the big ones already now","Quote from: S3052 on December 04, 2010, 08:57:41 AM"],["t","One thing I have learned in this community:\n\nYou can't prevent bitcoiners from doing whatever they want. They throw caution to the wind."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26740#msg26740"},{"f":"S3052","d":1291454578,"b":[["t","exactly this is both, a great benefit and also a great danger .\nin the wikileaks case its a great danger.\n\nAs this is an open and free forum, I can at least voice my concerns"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26746#msg26746"},{"f":"m0mchil","d":1291454841,"b":[["t","Great danger? But wait, isn't bitcoin invincible?! (Well, perhaps if it adopts random ports, protocol obfuscation, DHT bootstrapping...)"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26747#msg26747"},{"f":"kiba","d":1291455034,"b":[["t","Lot of little Davids versus a few Goliaths. What can the worst happen?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26748#msg26748"},{"f":"jgarzik","d":1291456767,"b":[["q","in the wikileaks case its a great danger.","Quote from: S3052 on December 04, 2010, 09:22:58 AM"],["t","+1, I agree completely\n\nWe know <http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/> that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.\n\nDoes it make sense to actively give multiple world governments incentive to shut down bitcoin?\n\nNo matter how symathetic wikileaks' cause...  if you care about bitcoin's success, the answer is no."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26749#msg26749"},{"f":"S3052","d":1291456847,"b":[["t","worst case for me would be that bitcoin businesses would be forbidden .\nEven if this would be wrong this would be the end of making bitcoins what most of us want.\nthen there will only be a handful of davids left but overall bitcoins would be forgotten soon"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26750#msg26750"},{"f":"S3052","d":1291457284,"b":[["q","> Quote from: S3052 on December 04, 2010, 09:22:58 AM\n> in the wikileaks case its a great danger.\n\n+1, I agree completely\n\nWe know <http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/> that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.\n\nDoes it make sense to actively give multiple world governments incentive to shut down bitcoin?\n\nIf you care about bitcoin's success, the answer is no.","Quote from: jgarzik on December 04, 2010, 09:59:27 AM"],["t","That is exactly the issue.\n\nI am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.\nthose who want to play this aggressive game against governments can do it, but i dont want to be connected to that."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26753#msg26753"},{"f":"sturle","d":1291457914,"b":[["q","I am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.","Quote from: S3052 on December 04, 2010, 10:08:04 AM"],["t","That's just stupid.  I don't want to have any drug money in my wallet, but that is hard.  99% of all bank notes are tainted with cocaine, according to a british study.  http://news.bbc.co.uk/2/hi/uk_news/464200.stm\n\nDon't donate to Wikileaks if you don't want to.  Wikileaks is perfectly legal in most countries.  Only The US government, China and a few arab states takes measures to sensor Wikileaks."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26754#msg26754"},{"f":"S3052","d":1291459761,"b":[["t","There is nothing wrong with revealing the truth (i.e. from Wikileaks. In this respect, I like a lot the concept behind Wikileaks).\n\nAll I am saying is that it is suicide for bitcoins to connect with Wikileaks today, where many big powers are against.\n\nThe time is not ripe yet.\n\nIt's like a runner who wants to run a marathon. He better trains a bit before trying."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26756#msg26756"},{"f":"bitcoinex","d":1291461389,"b":[["t","I also think that they try to ban bitcoin business. But I also remember that monitoring of financial flows for combat with organized crime came only 50 years ago and it is unnatural. And that monitoring works worse and worse every year."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26760#msg26760"},{"f":"bitcoinex","d":1291461695,"b":[["t","In any case, I think this is the happiest opportunity that happens in any very successful project"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26761#msg26761"},{"f":"Bruce Wagner","d":1291481303,"b":[["t","This is very well-written, and he is very well spoken..."],["q","I believe very strongly that a successful effort to supplant state money is going to be a ground-up effort. The big players in today's pink economy are going to be the last to adapt, kicking and screaming, to the new economic reality. For years before that happens, though, individuals, sole traders and small enterprises are going to be taking more and more of their income away as, simultaneously, a) the new monetary system's benefits impact more and more people, b) the inevitable institutional dumbness of big organizations makes them stumble and lag, and, c) continually eroding confidence in the state, its institutions and the entities that rely upon them drives more and more people into the new economy.\n\nIf you're reading this, you're part of the vanguard building the new economy and the new world. Mainstream acceptance will come by weight of numbers and via network effects. Who ever heard of Wikileaks or Twitter four years ago? And today we've got Admiral Chairman-of-the-Joint-Fucking-Chiefs Mullen tweeting his dismay over Wikileaks -- no doubt via the intermediation of an office full of PR analysts and bureaucrats, at extremely low relative impact.\n\nBTW, Shadow, when they shut down the internet, I know how to build a new one. Want to help? Smiley","Quote from: mikegogulski on November 29, 2010, 02:24:48 PM"],["t","I agree 100%."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26805#msg26805"},{"f":"Bruce Wagner","d":1291483280,"b":[["q","> Quote from: S3052 on December 04, 2010, 09:22:58 AM\n> in the wikileaks case its a great danger.\n\n+1, I agree completely\n\nWe know <http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/> that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.\n\nDoes it make sense to actively give multiple world governments incentive to shut down bitcoin?\n\nNo matter how symathetic wikileaks' cause...  if you care about bitcoin's success, the answer is no.","Quote from: jgarzik on December 04, 2010, 09:59:27 AM"],["t","This is a very good point.\n\n\"PayPal Freezes WikiLeaks Account\"   http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/\n\nWe must weigh...\n\n---> the potential financial benefit bitcoin would give to wikileaks at This moment\n\nvs.\n\n---> the potential demise of bitcoin itself (or at least the impact of bitcoin being mortally wounded at this very early stage of its existence.)\n\nI think that -- no matter how righteous anyone may feel about the work wikileaks does...\n\n1.  They don't need that much money to do what they do.\n2.  What they could potentially get via bitcoin at the moment wouldn't be a drop in the bucket of what they're receiving via other private means.\n3.  Nothing wikileaks is doing is WORTH the potential demise of Bitcoin.\n\nWe don't need to make Bitcoin, or each of US for that matter, into targets of world governments.   Especially not so early in Bitcoin's life.\n\nWikileaks is probably being funded, at least partially, by other governments with interests in leaking damaging information.\n\nBut in any case, Wikileaks probably has a bankroll larger than the ENTIRE bitcoin economy at this point in time.\n\nAlso, when you create a new Iron Man suit in your lab, you don't take on all the militaries of the world on your first trip out on the \"test track\".   Bitcoin is still in \"beta\", remember.  Smiley\n\nI say, we MUST get Bitcoin accepted at Starbucks and the local grocery store....  BEFORE it gets accepted at Wikileaks.\n\nThen, we'll have a chance.\n\nStarbucks.   Anyone have contact info for them?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26814#msg26814"},{"f":"S3052","d":1291484407,"b":[["t","very well explained\n+1"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26816#msg26816"},{"f":"bitcoinex","d":1291488815,"b":[["t","Your torment understandable but really nothing does depend from us. For WikiLeaks crew does not cost anything to setup the client, to generate the address and publish it.\n\nSo we must just pray to our gods that they may take our point of view."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26829#msg26829"},{"f":"Bruce Wagner","d":1291489657,"b":[["t","By the way, the greatest benefit Bitcoin could give to Wikileaks...  MIGHT be in them using Bitcoin PRIVATELY.... not PUBLICLY.\n\nThey could ( / can / will / are / ? ) use Bitcoin to transmit their funds easily across all borders, exchange them into all currencies as needed, and even Back Them Up electronically (as long as their wallet.dat file is encrypted too).   There's no need for them to advertise publicly that they are using Bitcoin.... for them to benefit from all the advantages of using Bitcoin privately/secretly/anonymously.\n\nIt would be Much Better for Everyone Involved if they do NOT express their support for Bitcoin publicly...  and they just go about using it very privately.    (And who's to say that they aren't already...?)"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26832#msg26832"},{"f":"wumpus","d":1291489703,"b":[["t","Yes, there are arguments for not pushing bitcoins as a solution for orgs such as wikileaks.\n\nOn the other hand, the same crowd that is attracted to sites such as wikileaks will be attracted to a distributed currency, it would also be a way to gain popularity, coders, crypto people auditing the protocol, and so on. That way, the project can grow.\n\nEverything is a compromise..."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26833#msg26833"},{"f":"Hal","d":1291490113,"b":[["t","I suspect the first targets if Bitcoin got associated with Wikileaks would not be miners or participants, but the money changers. People buying and selling Bitcoins for dollars and other currencies would be natural targets for shutting down. Without them, Bitcoin is back to being play money."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26835#msg26835"},{"f":"Bruce Wagner","d":1291490166,"b":[["q","Yes, there are arguments for not pushing bitcoins as a solution for orgs such as wikileaks.\n\nOn the other hand, the same crowd that is attracted to sites such as wikileaks will be attracted to a distributed currency, it would also be a way to gain popularity, coders, crypto people auditing the protocol, and so on. That way, the project can grow.\n\nEverything is a compromise...","Quote from: witchspace on December 04, 2010, 07:08:23 PM"],["t","Problem is...  It would attract 9 world governments, along with their Intelligence Services (thier CIA's), trying to shut down Bitcoin.... for every one new crypto coder supporter.\n\nLet's achieve this result through POSITIVE publicity....    not NEGATIVE publicity.\n\nDo we want Bitcoin to be known forever in slang as, \"Wilileaks Money\"?    No.\n\nLet's get Whole Foods, and McDonalds, and Startbucks, and Cocacola vending machines....  to accept Bitcoin.\n\nIn fact, the BEST POSITIVE publicity is not even businesses....  It is famous charities!\n\nRed Cross, UNICEF, United Way, etc.    Would you rather Bitcoin be known as \"wikileaks money\"....   or \"the money large charites use for donations\"....?\n\nThink of all these ideas from a PR perspective.   Bitcoin needs SUPPORTERS.    It needs to make no enemies....  not yet.   It's too weak to take on enemies right now."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26836#msg26836"},{"f":"sturle","d":1291490328,"b":[["q","\"PayPal Freezes WikiLeaks Account\"   http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/","Quote from: brucewagner on December 04, 2010, 05:21:20 PM"],["t","It wasn't exactly frozen.  It was restricted, and Wikileaks can't take donations directly via PayPal anymore.  Hardly a problem, since several other organizations take donations to Wikileaks.  No funds are confiscated in any country or bank, as far as public information goes anyway.  None of the newspapers publishing the leaks in full have gotten their bank accounts frozen either.  Their operation is perfectly legal in every country with free speech.  This is nothing but a publicity stunt for PayPal, and it would be a better publicity stunt for the Bitcoin community to to the opposite.\n\n-1.  I think you are overreacting."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26837#msg26837"},{"f":"Bruce Wagner","d":1291490631,"b":[["q","> Quote from: brucewagner on December 04, 2010, 05:21:20 PM\n> \"PayPal Freezes WikiLeaks Account\"   http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/\nIt wasn't exactly frozen.  It was restricted, and Wikileaks can't take donations directly via PayPal anymore.  Hardly a problem, since several other organizations take donations to Wikileaks.  No funds are confiscated in any country or bank, as far as public information goes anyway.  None of the newspapers publishing the leaks in full have gotten their bank accounts frozen either.  Their operation is perfectly legal in every country with free speech.  This is nothing but a publicity stunt for PayPal, and it would be a better publicity stunt for the Bitcoin community to to the opposite.\n\n-1.  I think you are overreacting.","Quote from: sturle on December 04, 2010, 07:18:48 PM"],["t","This is not true.  When PayPal shuts down your account, they TAKE and KEEP all of the money in it.   There is no refund.   Never.   Never.    Their email tells you that \"there is no process to appeal\".   PayPay is owned by eBay.   ....and the \"e\" in eBay stands for \"evil\".   Google \"PayPay\" it if you don't believe me.\n\nAlso, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26838#msg26838"},{"f":"wumpus","d":1291491172,"b":[["q","Also, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits.","Quote from: brucewagner on December 04, 2010, 07:23:51 PM"],["t","Yes -- the leaker can be considered a traitor.\n\nWikileaks are not the people that leaked the information though. They are simply a press organization that likes transparency and does not take sides with any government or big corporation. They got sent the information and they do what any media would do, they publish. Which is, in my opinion, very refreshing and good for democracy.\n\nIgnore all the fuss about traitors, terrorists, and other distorting comments. Those people don't understand it, don't repeat them."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26842#msg26842"},{"f":"kiba","d":1291491281,"b":[["q","Ignore all the fuss about traitors, terrorists, and other distorting comments. Those people don't understand it, don't repeat them.","Quote from: witchspace on December 04, 2010, 07:32:52 PM"],["t","Security is not made by invading foreign nation and inadvertently increasing heroin production in the process, inadvertently killing more Americans through heroin overdose..."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26843#msg26843"},{"f":"em3rgentOrdr","d":1291492420,"b":[["q","Fortunately, bitcoin is a distributed system, so it doesn't matter if they take out   Undecided","Quote from: em3rgentOrdr on December 03, 2010, 01:09:11 PM"],["t","I meant to write: \"Fortunately, Wikileaks is a distributed organization, so it doesn't matter if they take out the current \"leader\", Assange.\""]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26849#msg26849"},{"f":"Hal","d":1291495387,"b":[["t","Looking on the bright side, if Bitcoin did get known as the Wikileaks currency, attacked by governments all over the world, at least we'd get our Wikipedia page back!"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26860#msg26860"},{"f":"sturle","d":1291498709,"b":[["q","> Quote from: sturle on December 04, 2010, 07:18:48 PM\n> > Quote from: brucewagner on December 04, 2010, 05:21:20 PM\n> > \"PayPal Freezes WikiLeaks Account\"   http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/\n> It wasn't exactly frozen.  It was restricted, [...]\n> -1.  I think you are overreacting.\nThis is not true.  When PayPal shuts down your account, they TAKE and KEEP all of the money in it.","Quote from: brucewagner on December 04, 2010, 07:23:51 PM"],["t","True, but according to the PayPal blog <http://www.thepaypalblog.com/>, it wasn't closed.  It was restricted.  It cannot receive donations, but it doesn't say anywhere it was closed, shut down or confiscated."],["q","Also, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits.","Quote"],["t","Wikileaks have not stolen any secrets or signed any confidentiality agreements.  They are just printing documents given to them by other people.  The people who gave the secret documents to Wikileaks were probably doing something illegal.  Not Wikileaks, or the newspapers which printed the leaked documents before they were available from Wikileaks.  So, why aren't the editors of the newspapers arrested, threatened to be murdered, getting their servers and DNS shut down., accounts closed, etc?  Because what they are doing is perfectly legal, and so is Wikileaks.  Just unpopular among some who believes the press should write what the government tells them to write."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26867#msg26867"},{"f":"RHorning","d":1291501064,"b":[["q","Looking on the bright side, if Bitcoin did get known as the Wikileaks currency, attacked by governments all over the world, at least we'd get our Wikipedia page back!","Quote from: Hal on December 04, 2010, 08:43:07 PM"],["t","This is so true.  There certainly wouldn't be a shortage of \"reliable sources\" about Bitcoins at that point.  I think it would likely show up on the front page of most newspapers and be talked about extensively on both radio talk shows and the other broadcast networks too.\n\nFor myself, I'm getting to the point to say \"bring it on\" in regards to Wikileaks.  Note that I'm using my real name here instead of a psuedonym and I'm willing to personally say \"bring it on\" in terms of being associated with Bitcoins as a project.  I've had police come into my house without my permission already and do all kind of stupid stuff, so for me that line being crossed has already happened.  I am also connected to enough people politically that if something was to happen to me that it would be noted and things would happen too.\n\nIt is the morally correct thing to be supporting Wikileaks, and if they'll take a few of my bitcoins, I not only want to donate but to let the world know that they can donate to Wikileaks through Bitcoins as well.\n\nI can't speak for everybody here in the Bitcoins community but I am speaking for myself on this matter, and I'm not afraid of anything that the U.S. government might do to me if I was associated with backing Wikileaks financially.  If anything, it would show that I no longer live under a constitutional government any more.  If the U.S. government wants to tip their hand to expose themselves in that way, so be it.  If the U.S. government kills me or puts me in jail, I'll certainly set a way for this community to find out.  I really don't think it would come to that either, but I don't care if it did.\n\nIf I have to \"vote\" on this matter, I would encourage the Bitcoin community to take up the plate like we did with the EFF and encourage Wikileaks to put up a Bitcoin address on their website for donations.  It would bring in some new blood into the Bitcoin community regardless, and it might be beneficial to Wikileaks as well.  Leave it to Wikileaks to see if they want to use Bitcoins or not.  In terms of governmental review of Bitcoins, we know that is going to happen sooner or later, so why are we fighting that inevitable result?  Anything other than a low-key investigation is only going to make more people interested in Bitcoins, which is only going to help the project even more.  It can't be killed as a project, only slowed down a little bit in its growth at this point and more likely its adoption would be accelerated by any kind of publicity that would happen.\n\nThe only possible concern I would have is over how sound the protocol itself is right now.  If anything, a major flux of new people into Bitcoins would help there too, and the worst that could happen is that Bitcoins itself would be broken in some way where a new cryptocurrency would have to be created fixing the problems of Bitcoins.  It is the idea of cryptocurrency that would then persist, and it is incredibly hard to censor an idea.\n\nBasically, bring it on.  Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.\n\n-- Robert S. Horning\nLogan, Utah"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26876#msg26876"},{"f":"em3rgentOrdr","d":1291501084,"b":[["q","> Quote from: em3rgentOrdr on December 04, 2010, 07:53:40 PM\n> \"Fortunately, Wikileaks is a distributed organization, so it doesn't matter if they take out the current \"leader\", Assange.\"\n\nWell, it does matter a bit if you happen to be Assange.","Quote from: ribuck on December 04, 2010, 08:30:21 PM"],["t","Interestingly, it turns out there is some Wikileaks infighting <http://www.wired.com/threatlevel/2010/09/wikileaks-revolt/>, probably upset at Assange's leadership:"],["q","Assange: That is a procedural issue. Don’t play games with me.\n\nDomscheit-Berg: stop shooting at messengers\n\nAssange: I’ve had it.\n\nDomscheit-Berg: likewise, and that doesnt go just for me\n\nAssange: If you do not answer the question, you will be removed.\n\nDomscheit-Berg: you are not anyones king or god\n\nDomscheit-Berg: and you’re not even fulfilling your role as a leader right now\n\nDomscheit-Berg: a leader communicates and cultivates trust in himself\n\nDomscheit-Berg: you are doing the exact opposite\n\nDomscheit-Berg: you behave like some kind of emporer or slave trader\n\nAssange: You are suspended for one month, effective immediately.\n\nDomscheit-Berg: haha\n\nDomscheit-Berg: right\n\nDomscheit-Berg: because of what?\n\nDomscheit-Berg: and who even says that?\n\nDomscheit-Berg: you? another adhoc decision?\n\nAssange: If you wish to appeal, you will be heard on Tuesday.","Quote"],["t","So maybe a leaderless organization is the better direction for WikiLeaks to go?  Opinions?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26877#msg26877"},{"f":"em3rgentOrdr","d":1291501460,"b":[["q","...\n\nI can't speak for everybody here in the Bitcoins community but I am speaking for myself on this matter, and I'm not afraid of anything that the U.S. government might do to me if I was associated with backing Wikileaks financially.  If anything, it would show that I no longer live under a constitutional government any more.  If the U.S. government wants to tip their hand to expose themselves in that way, so be it.  If the U.S. government kills me or puts me in jail, I'll certainly set a way for this community to find out.  I really don't think it would come to that either, but I don't care if it did.\n\n...\n\nBasically, bring it on.  Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.","Quote from: RHorning on December 04, 2010, 10:17:44 PM"],["t","Amen, RHorning!  As The Voluntaryists <http://voluntaryist.com/> argue, Governments must cloak their actions in an aura of moral legitimacy in order to sustain their power.  If the U.S. government wants to tip their hand to expose themselves in that way, so be it.  Without an aura of moral legitimacy, they will be seen as the gang that they truly are."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26879#msg26879"},{"f":"kiba","d":1291501541,"b":[["q","So maybe a leaderless organization is the better direction for WikiLeaks to go?  Opinions?","Quote from: em3rgentOrdr on December 04, 2010, 10:18:04 PM"],["t","There's alway a leader of some kind. It might be a person with a high reputation."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26881#msg26881"},{"f":"jgarzik","d":1291501545,"b":[["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.","Quote from: RHorning on December 04, 2010, 10:17:44 PM"],["t","Thanks for being willing to helpfully impose risk upon others.  For people who are just starting to build businesses on bitcoin, this could be devastating to their new business.\n\nAnd it could permanently marginalize bitcoin, keeping it out of the mainstream for good.  Is that really the end result the bitcoin community most desires?\n\nSome of us are working hard to build tools and programs that encourage businesses to invest their time, money and energy into bitcoin.  It would be very sad to see all that go down the drain."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26882#msg26882"},{"f":"kiba","d":1291501703,"b":[["t","Success is not guaranteed; access risk; act wisely; remember knowledge gaps.\n\nIt's funny to see a miniarchist libertarian say \"Bring it on\" when anarchists like me are advising cautions.\n\nIt look like I am right, people throw cautions to the wind."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26884#msg26884"},{"f":"RHorning","d":1291504563,"b":[["q","> Quote from: RHorning on December 04, 2010, 10:17:44 PM\n> Basically, bring it on.  Let's encourage Wikileaks to use Bitcoins and I'm willing to face any risk or fallout from that act.\n\nThanks for being willing to helpfully impose risk upon others.  For people who are just starting to build businesses on bitcoin, this could be devastating to their new business.\n\nAnd it could permanently marginalize bitcoin, keeping it out of the mainstream for good.  Is that really the end result the bitcoin community most desires?\n\nSome of us are working hard to build tools and programs that encourage businesses to invest their time, money and energy into bitcoin.  It would be very sad to see all that go down the drain.","Quote from: jgarzik on December 04, 2010, 10:25:45 PM"],["t","What would go down the drain?  Really, I think this is making a mountain out of a molehill and if you want to stay anonymous I'm not necessarily stopping you from doing that either.  Some are willing to stand up and others want to hide in the background.  I choose to stand in front if that is necessary.  Many are participating on this project using a pseudonym, and if they are very paranoid through a Proxy IP address and using https for communications to this forum and perhaps taking other precautions.  I am not, because I'm not afraid.  I'm not necessarily against anonymity and even would encourage it for those who find it necessary for whatever reason they have.\n\nIn short, I don't wish to impose this risk upon others but I am willing to take this risk for myself.\n\nI also fail to see how this would marginalize Bitcoin as a software project either.  The best thing, from a political perspective, would be to completely ignore that Bitcoin even exists at all.  If that is marginalizing Bitcion, how is that different from what is going on right now?\n\nI suppose the hope here is that Bitcoin will be used by a bunch of people first (it already is) and that perhaps Bitcoin can be known for doing other things than financing Wikileaks.  I am not encouraging that the main page of bitcoin.org have a huge banner across the top \"the official fundraising method for Wikileaks\".  We don't have to tie ourselves that closely, and anybody who checks out Bitcoin will discover what it is.... an alternative to PayPal and other on-line financial transaction systems with perhaps some other interesting benefits as well.  Is that necessarily a bad thing?  Is there anything new that hasn't been said repeatedly elsewhere?  If you were trying to stay off people's radar, publicity should be avoided altogether.\n\nThis is also about doing what is right, and this is the right thing to do.  I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too.  There is a down side, and talking about concerns over that perhaps is useful."],["q","Success is not guaranteed; access risk; act wisely; remember knowledge gaps.\n\nIt's funny to see a miniarchist libertarian say \"Bring it on\" when anarchists like me are advising cautions.\n\nIt look like I am right, people throw cautions to the wind.","Quote from: kiba on December 04, 2010, 10:28:23 PM"],["t","I agree, success is not guaranteed.  Sometimes you have to take some risks and sometimes do so with imperfect knowledge.  It is a golden opportunity right now for the Bitcoin community, however, to encourage Wikileaks to accept Bitcoin donations and I personally don't think the extra publicity that we may or may not get from having a link on the Wikileaks website would necessarily be a bad thing.  There isn't even any sort of guarantee that Wikileaks will even take Bitcoins if they are being offered.\n\nBut seriously, what are the downsides anyway?  Do you really think the \"Men in Black\" are going to shut down Bitcoin?  Really?  If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26898#msg26898"},{"f":"jgarzik","d":1291505325,"b":[["q","This is also about doing what is right, and this is the right thing to do.  I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too.  There is a down side, and talking about concerns over that perhaps is useful.","Quote from: RHorning on December 04, 2010, 11:16:03 PM"],["t","Your stand could impact my money, and everyone else's.  Don't pretend your actions could impact only you."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26900#msg26900"},{"f":"em3rgentOrdr","d":1291505894,"b":[["q","If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?","Quote from: RHorning on December 04, 2010, 11:16:03 PM"],["t","Exactly.  I feel the same way.  Survival of the fittest.  If bitcoin has some fundamental flaw, it will not be able to survive a government attack.  Then it is better to weed it out now, so we aren't wasting our time promoting something that will not work, and can instead devote our resources and time to other efforts that hopefully will work and to other currencies to build up the alternative economy.  "],["q","> Quote from: RHorning on December 04, 2010, 11:16:03 PM\n> This is also about doing what is right, and this is the right thing to do.  I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too.  There is a down side, and talking about concerns over that perhaps is useful.\n\nYour stand could impact my money, and everyone else's.  Don't pretend your actions could impact only you.","Quote from: jgarzik on December 04, 2010, 11:28:45 PM"],["t","I have spent many hours reading through the bitcoin forums about its robustness and resiliency to attacks...asking so many questions \"What if the government does X?\", and I have come to the conclusion that basically, bitcoin can't be shut down absent shutting down the internet.  But the government wouldn't likely not shut down the internet, since they depend on tax revenue for their operations.  If bitcoin has some flaw, then we need to resolve it now."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26902#msg26902"},{"f":"kiba","d":1291507890,"b":[["q","If bitcoin has some flaw, then we need to resolve it now.","Quote from: em3rgentOrdr on December 04, 2010, 11:38:14 PM"],["t","I suggest assembling a tiger team or make security bounties or do both.\n\nBut, you have to remember that the security of the network also come from the strength of people running it. So, wikileaks might add more legit computing power rather than cheating nodes, or not. It's hard to know.\n\nBrute-force attacks are least likely. We probably have some bugs lurking in the system."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26905#msg26905"},{"f":"farmer_boy","d":1291508156,"b":[["q","> Quote from: RHorning on December 04, 2010, 11:16:03 PM\n> If Bitcoin is that fragile and vulnerable to attack, what are we doing anyway and why is it so consistently being defended?\n\nExactly.  I feel the same way.  Survival of the fittest.  If bitcoin has some fundamental flaw, it will not be able to survive a government attack.  Then it is better to weed it out now, so we aren't wasting our time promoting something that will not work, and can instead devote our resources and time to other efforts that hopefully will work and to other currencies to build up the alternative economy.  \n\n> Quote from: jgarzik on December 04, 2010, 11:28:45 PM\n> > Quote from: RHorning on December 04, 2010, 11:16:03 PM\n> > This is also about doing what is right, and this is the right thing to do.  I get the arguments advocating caution, but sometimes you also have to take a stand on an issue too.  There is a down side, and talking about concerns over that perhaps is useful.\n>\n> Your stand could impact my money, and everyone else's.  Don't pretend your actions could impact only you.\n\nI have spent many hours reading through the bitcoin forums about its robustness and resiliency to attacks...asking so many questions \"What if the government does X?\", and I have come to the conclusion that basically, bitcoin can't be shut down absent shutting down the internet.  But the government wouldn't likely not shut down the internet, since they depend on tax revenue for their operations.  If bitcoin has some flaw, then we need to resolve it now.","Quote from: em3rgentOrdr on December 04, 2010, 11:38:14 PM"],["t","I approve of this message. If Bitcoin blows up, a new system can be build without this flaw. The probability of Bitcoin _not_ containing some fatal flaw is pretty small (as almost all software has flaws).\n\nAll Wikileaks needs to do is say \"Following the PayPal incident we have decided to accept a new kind of payment, Bitcoins. You can find more information on donating via Bitcoins on URL <some suitable URL hosted by Wikileaks>.  \"\n\nThey could post it in their news section or something like that. It is possible that main stream media would pick it up if they would contrast Bitcoin with PayPal like that. "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26906#msg26906"},{"f":"MoonShadow","d":1291510918,"b":[["q","> Quote from: brucewagner on December 04, 2010, 07:23:51 PM\n> Also, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits.\nYes -- the leaker can be considered a traitor.","Quote from: witchspace on December 04, 2010, 07:32:52 PM"],["t","One that note, I smell a rat.  I've worked for the beast, and there is no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.\n\nThere is no way this kid did this."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26912#msg26912"},{"f":"ShadowOfHarbringer","d":1291512544,"b":[["q","> Quote from: jgarzik on December 04, 2010, 09:59:27 AM\n> > Quote from: S3052 on December 04, 2010, 09:22:58 AM\n> > in the wikileaks case its a great danger.\n>\n> +1, I agree completely\n>\n> We know <http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/> that private and government forces are actively tracing, and trying to shut down, sources of wikileaks funding through all available means of pressure.\n>\n> Does it make sense to actively give multiple world governments incentive to shut down bitcoin?\n>\n> If you care about bitcoin's success, the answer is no.\n\nThat is exactly the issue.\n\nI am so worried about the intent behind this wikileaks thread that, if i could, would only want to have \"legallysafe\" bitcoins in my wallet that are not connected to wikileaks or any other illegal matter.\nthose who want to play this aggressive game against governments can do it, but i dont want to be connected to that.","Quote from: S3052 on December 04, 2010, 10:08:04 AM"],["t","Agreed, i have already spoken about this in some other wikileaks-related topic (or perhaps this one ?).\n\nEngaging in wikileaks before Bitcoin has a chance to unfold its wings may kill it."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26916#msg26916"},{"f":"kiba","d":1291512907,"b":[["q","Engaging in wikileaks before Bitcoin has a chance to unfold its wings may kill it.","Quote from: ShadowOfHarbringer on December 05, 2010, 01:29:04 AM"],["t","It may allows us to unfold our wings.\n\nBeside, what is done, done. Bob182 already talked to a person within the wikileak organization.\n\nBut there are much safer route to unfolding our wings."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26920#msg26920"},{"f":"Anonymous","d":1291515646,"b":[["t","We should be doing something to get a full security audit done on bitcoins. Something we can point to that is third party and not connected to bitcoin in any way. Now who do we contact to get this done?\n\nThis should be our first priority rather than engaging in political statements.  Smiley\n\nEdit: Bradley Manning supposedly leaked the documents NOT Julian Assange.\n\nthe US government cant even beat a few  fighters in the afghanistan dessert... Cheesy\n\nThe bigger concern is the international banking mafia.  Angry  They are the real scary ones."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26929#msg26929"},{"f":"kiba","d":1291516838,"b":[["q","We should be doing something to get a full security audit done on bitcoins. Something we can point to that is third party and not connected to bitcoin in any way. Now who do we contact to get this done?","Quote from: Anonymous on December 05, 2010, 02:20:46 AM"],["t","I don't have money but I think we should set up a bitcoin bounty for security, like I been suggesting everywhere. It will be a start."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26934#msg26934"},{"f":"em3rgentOrdr","d":1291517613,"b":[["q","> Quote from: witchspace on December 04, 2010, 07:32:52 PM\n> > Quote from: brucewagner on December 04, 2010, 07:23:51 PM\n> > Also, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits.\n> Yes -- the leaker can be considered a traitor.\n\nOne that note, I smell a rat.  I've worked for the beast, and there is no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.\n\nThere is no way this kid did this.","Quote from: creighto on December 05, 2010, 01:01:58 AM"],["t","I'm glad that you have left the dark side, creighto.  You make an interesting point that a private could not have gotten access to all this (but then again, some of these gubbamint bureacracies are extremely inefficient).  Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught.  Anyway, it's all speculation.  "]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26935#msg26935"},{"f":"kiba","d":1291518003,"b":[["q"," Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught.  Anyway, it's all speculation. ","Quote from: em3rgentOrdr on December 05, 2010, 02:53:33 AM"],["t","A top secret anarchist cabal penetrated the US government. It's simple really."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26936#msg26936"},{"f":"em3rgentOrdr","d":1291519134,"b":[["q","> Quote from: em3rgentOrdr on December 05, 2010, 02:53:33 AM\n>  Bradley Manning may simple just be a fall guy, scapegoat, or framed by the real leaker...who may never be caught.  Anyway, it's all speculation. \n\nA top secret anarchist cabal penetrated the US government. It's simple really.","Quote from: kiba on December 05, 2010, 03:00:03 AM"],["t","It is entirely possible.  Some government agent may have converted to anarchism after climbing up the ranks and then accidentally reading Rothbard or some other anti-statist philosopher or website.  Or maybe just saw the crap going around him and decided he is an anarchist."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26940#msg26940"},{"f":"kiba","d":1291519408,"b":[["q"," Or maybe just saw the crap going around him and decided he is an anarchist.","Quote from: em3rgentOrdr on December 05, 2010, 03:18:54 AM"],["t","Using that guy as a sacrificial lamb isn't exactly what I called, anarchistic. Unless, he agreed to cover for the real leaker."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26942#msg26942"},{"f":"em3rgentOrdr","d":1291520127,"b":[["q","> Quote from: em3rgentOrdr on December 05, 2010, 03:18:54 AM\n>  Or maybe just saw the crap going around him and decided he is an anarchist.\n\nUsing that guy as a sacrificial lamb isn't exactly what I called, anarchistic. Unless, he agreed to cover for the real leaker.","Quote from: kiba on December 05, 2010, 03:23:28 AM"],["t","Of course.  And yeah, it could have been a voluntary decision.  Also, it could be possible that the secret upper-level anarchist did not intend for Manning to be blamed...but then once Manning got arrested, he realized it would be better if he kept quiet, so that only one person is in jail."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26944#msg26944"},{"f":"MoonShadow","d":1291525050,"b":[["q","> Quote from: creighto on December 05, 2010, 01:01:58 AM\n> > Quote from: witchspace on December 04, 2010, 07:32:52 PM\n> > > Quote from: brucewagner on December 04, 2010, 07:23:51 PM\n> > > Also, leaking military secrets can be considered treason and is a very serious crime in most countries.   Free Speech always has legal limits.\n> > Yes -- the leaker can be considered a traitor.\n>\n> One that note, I smell a rat.  I've worked for the beast, and there is no way whatever that a private is going to have access 1) to top-secret communications 2) unmonitored 3) on a secure computer 4) with a cd-rom drive 5) that has access to secrets not in his own section.\n>\n> There is no way this kid did this.\n\nI'm glad that you have left the dark side, creighto.","Quote from: em3rgentOrdr on December 05, 2010, 02:53:33 AM"],["t","Perhaps you assume too much."],["q","  You make an interesting point that a private could not have gotten access to all this (but then again, some of these gubbamint bureacracies are extremely inefficient).","Quote"],["t","Inefficient yes, but ineffective?  Paranoia is what the government is good at.  No way this kid did this, not even a small part of it.  He is either a gov'ment patsy, or a martyr for some other group.\n\nThe government is no less likely to form internal factions over ideology or self-interest than any other collective agency.  This smells like an inside job, and from what I've seen so far, it seems to make the Bush admin seem less stupid|evil, even if only by comparison."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26960#msg26960"},{"f":"Anonymous","d":1291527062,"b":[["t","Seems that the main politician this embarrassed was Hillary Clinton.\n\nEither the pentagon or the cia leaked these papers.\n\n*Points finger at Robert Gates . Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26970#msg26970"},{"f":"em3rgentOrdr","d":1291531733,"b":[["q","Seems that the main politician this embarrassed was Hillary Clinton.\n\nEither the pentagon or the cia leaked these papers.\n\n*Points finger at Robert Gates . Cheesy","Quote from: Anonymous on December 05, 2010, 05:31:02 AM"],["t","I'm sorry...I'm not totally following you...could you elaborate?  Why would Robert Gates want to release videos of US Troops murdering Iraqi civilians?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26977#msg26977"},{"f":"bober182","d":1291535917,"b":[["t","With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26987#msg26987"},{"f":"kiba","d":1291536178,"b":[["q","With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up.","Quote from: bober182 on December 05, 2010, 07:58:37 AM"],["t","So you decide to ignore the long discussion and just do it?\n\nListen to people's argument, make a decision, give a reasoned case for what you're going to do, and then do it.\n\nAlso, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26988#msg26988"},{"f":"em3rgentOrdr","d":1291536697,"b":[["q","> Quote from: bober182 on December 05, 2010, 07:58:37 AM\n> With paypal down I'm increasing my pressure upon their board of directors to get a bitcoin address up.\n\nSo you decide to ignore the long discussion and just do it?\n\nListen to reasons, and then decide if you're going to keep doing what you do.","Quote from: kiba on December 05, 2010, 08:02:58 AM"],["t","Kiba makes some good points here...let's not be too hasty in communicating with WikiLeaks.  Patience is key.  There is no need to repeatedly pressure WikiLeaks in producing a bitcon donate address.  Since you have already communicated with them once, they may either he considering it or more likely have decided that it does nor suit their needs currently.  Don't get me wrong...I am all for wikileaks to use bitcoin, but let's not push this too hard."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26989#msg26989"},{"f":"bober182","d":1291536890,"b":[["t","Its seems all you want is your business to not be taxed that we will be free if we have competition and all that.\nThis is not an issue of rightwing vs leftwing.\nIts an issue of freedom of press and the fact they need a anonymous network of donations.\nI bet you don't ever see the oppression around society and decide to go out and do some direct action. Like in the case of the ashvi11e eleven or oscar grant. Instead you want to have more money and create the perfect economy. For revolution we need social change before economic. Wikileaks can be the first step to achieving this against the government. That's why I'm deciding to contact and explain to them the benefits of bitcoin.\n\nem3rgent order\nI'm just checking up getting the userbase on board with the idea. Trying to see if anyone else thinks its a possible good way to get donations on there site without having things shut down, same as the bitDNS project if we code it and wikileaks uses it will we all pussy out as they are deemed a terrorist organization?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26990#msg26990"},{"f":"jgarzik","d":1291536921,"b":[["q","Also, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf.","Quote from: kiba on December 05, 2010, 08:02:58 AM"],["t","bob182 is certainly not acting on my behalf, nor several others, as these threads seem to indicate.\n\nAnd for Pete's sake, bob182, please don't misrepresent yourself as some sort of official Bitcoin representative.\n\nWikileaks is the enemy of major world powers right now, with many influential elites feeling that Assange committed an act of war against the United States, or, at a minimum, irrevocably disrupted world affairs.  This is not some mailing list discussion or theoretical exercise; there are very real, very powerful organizations actively targetting wikileaks' network infrastructure, organizational infrastructure, and most importantly, financial infrastructure.\n\nIt is extraordinarily unwise to make bitcoin such a highly visible target, at such an early stage in this project.  There could be a lot of \"collateral damage\" in the bitcoin community while you make your principled stand."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26991#msg26991"},{"f":"kiba","d":1291537037,"b":[["q","Its seems all you want is your business to not be taxed that we will be free if we have competition and all that.\nThis is not an issue of rightwing vs leftwing.\nIts an issue of freedom of press and the fact they need a anonymous network of donations.\nI bet you don't ever see the oppression around society and decide to go out and do some direct action. Like in the case of the ashvi11e eleven or oscar grant. Instead you want to have more money and create the perfect economy. For revolution we need social change before economic. Wikileaks can be the first step to achieving this against the government. That's why I'm deciding to contact and explain to them the benefits of bitcoin.","Quote from: bober182 on December 05, 2010, 08:14:50 AM"],["t","This is god awful reasoning that didn't address any of my concerns, or jgarzik, or any others.\n\nWe also have no ideas what the heck you're saying to these people."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26993#msg26993"},{"f":"farmer_boy","d":1291537395,"b":[["q","> Quote from: kiba on December 05, 2010, 08:02:58 AM\n> Also, it would be nice if you explain what kind of \"pressure\" you're doing. You represent the rest of the bitcoiners here, so it's nice to know how bob182 is acting on our behalf.\n\nbob182 is certainly not acting on my behalf, nor several others, as these threads seem to indicate.\n\nAnd for Pete's sake, bob182, please don't misrepresent yourself as some sort of official Bitcoin representative.","Quote from: jgarzik on December 05, 2010, 08:15:21 AM"],["t","bober182 doesn't need to have anybody's permission to do anything. Even if he were to present himself as being 'official', the Wikileaks people are probably smarter than the average visitor of this forum, so they would be able to figure that out in less than a minute.\n\nDoes anyone have an idea of how large the Wikileaks group is? I know one guy who is in it, but two guys don't make a group Wink I suppose the actual members are a secret, but is the number too?"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26994#msg26994"},{"f":"jgarzik","d":1291537790,"b":[["t","Or, to put in military terms, we know that wikileaks' entire financial infrastructure is being actively targeted, and The Powers That Be have successfully destroyed one target <http://www.wired.com/threatlevel/2010/12/paypal-wikileaks/> in the past 24 hours.\n\nOnly cannon fodder would stand up and wave a red flag that says \"shoot me\" at such a point in time  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26996#msg26996"},{"f":"kiba","d":1291537979,"b":[["q","bober182 doesn't need to have anybody's permission to do anything.","Quote from: farmer_boy on December 05, 2010, 08:23:15 AM"],["t","This isn't about a permission issue.\n\nI just want bober182 to be a responsible member of the community. He's going in there, contacting the organization, when it is clear that members of the community don't think it is the best idea. He didn't address any of our concerns. He didn't give us any details what he is planning to do, except putting additional \"pressure\" which could mean anything from \"being pushy\" or selling \"snake oil\".\n\nThis is akin to somebody just go in there, with no plans and guns blazing, costing half of his squads and then costing us a war in the long run."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26997#msg26997"},{"f":"bober182","d":1291538075,"b":[["t","The wikileaks board of directors has 10 members + JA, then there are about 150~200 staff, and under that are 1400 volunteers."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26998#msg26998"},{"f":"satoshi","d":1291540088,"b":[["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.","Quote from: RHorning on December 04, 2010, 10:17:44 PM"],["t","No, don't \"bring it on\".\n\nThe project needs to grow gradually so the software can be strengthened along the way.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1735.msg26999#msg26999","s":1,"n":523,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/523/","qt":["The project needs to grow gradually so the software can be strengthened along the way. I make this appeal to WikiLeaks not to try to use Bitcoin.  Bitcoin is a small beta community in its infancy."],"qc":["bitcoin-design"]}]},{"id":"p242","k":"p","s":"bitcointalk","t":"Version 0.3.15","u":"https://bitcointalk.org/index.php?topic=1780","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/242/","m":[{"f":"satoshi","d":1289690800,"b":[["t","Version 0.3.15 is now available.\n\nChanges:\n- paytxfee switch is now per KB, so it adds the correct fee for large transactions\n- sending avoids using coins with less than 6 confirmations if it can\n- BitcoinMiner processes transactions in priority order based on age of dependencies\n- make sure generation doesn't start before block 74000 downloaded\n- bugfixes by Dean Gores\n- testnet, keypoololdest and paytxfee added to getinfo"]],"u":"https://bitcointalk.org/index.php?topic=1780.msg21897#msg21897","s":1,"n":502,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/502/"}]},{"id":"p243","k":"p","s":"bitcointalk","t":"Need OP_BLOCKNUMBER to allow \"time\" limited transactions","u":"https://bitcointalk.org/index.php?topic=1786","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/243/","m":[{"f":"ByteCoin","d":1289783823,"b":[["t","At the moment, if you make a payment to someone but they've wiped their wallet then the coins are irretrievably lost.\nSimilarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can't reissue that payment backed by the same coins but with a fee.\n\nIf you could cause the current block number to be pushed on the stack and do some maths with it then you could implement a payment that must be spent by the recipient before a certain block number is reached or else the script would allow it to be spent again by the sender for example.\n\nI suspect that this would be a very popular transaction mechanic.\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1786.msg21998#msg21998"},{"f":"theymos","d":1289785799,"b":[["t","That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network."]],"u":"https://bitcointalk.org/index.php?topic=1786.msg22003#msg22003"},{"f":"ByteCoin","d":1289789250,"b":[["q","That would be useful, but it's probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.","Quote from: theymos on November 15, 2010, 01:49:59 AM"],["t","Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal.\nPlease go into more detail about why this is not good for the network.\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1786.msg22014#msg22014"},{"f":"theymos","d":1289793189,"b":[["q","Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal.\nPlease go into more detail about why this is not good for the network.","Quote from: ByteCoin on November 15, 2010, 02:47:30 AM"],["t","You may be right about this. Bitcoin's segmentation-fixing mechanisms would seem to keep everything in order.\n\nA similar feature seems to already be planned. Every transaction has the currently-unused \"nLockTime\" field, and this bit of code exists for the UI (the text would appear in the same place as \"x confirmations\"):"],["c","    if (!wtx.IsFinal())\n    {\n        if (wtx.nLockTime < 500000000)\n            return strprintf(_(\"Open for %d blocks\"), nBestHeight - wtx.nLockTime);\n        else\n            return strprintf(_(\"Open until %s\"), DateTimeStr(wtx.nLockTime).c_str());\n    }"],["t","Sounds very much like what you're thinking of."]],"u":"https://bitcointalk.org/index.php?topic=1786.msg22021#msg22021"},{"f":"theymos","d":1289794576,"b":[["t","After investigating some more, I found that nLockTime requires in-memory transaction replacement to be re-activated for it to be useful."],["c","if (mapNextTx.count(outpoint))\n        {\n            // Disable replacement feature for now\n            return false;\n\n            // Allow replacing with a newer version of the same transaction\n            if (i != 0)\n                return false;\n            ptxOld = mapNextTx[outpoint].ptx;\n            if (!IsNewerThan(*ptxOld))\n                return false;\n            for (int i = 0; i < vin.size(); i++)\n            {\n                COutPoint outpoint = vin[i].prevout;\n                if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)\n                    return false;\n            }\n            break;"]],"u":"https://bitcointalk.org/index.php?topic=1786.msg22024#msg22024"},{"f":"satoshi","d":1289846264,"b":[["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119","s":1,"n":504,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/504/"}]},{"id":"p244","k":"p","s":"bitcointalk","t":"BitDNS and Generalizing Bitcoin","u":"https://bitcointalk.org/index.php?topic=1790","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/244/","m":[{"f":"appamatto","d":1289790151,"b":[["t","This is based on a discussion on 11/14/2010 on the IRC channel.\n\nBitDNS\n\nAlthough there have been attempts to tackle DNS in a distributed way in the past, I don't think there have been solutions that have fully removed authority from the equation.\n\nIf there was such a solution, it probably would have been able to implement bitcoin directly on top of it, and we all know that didn't happen.\n\nHowever, it seems possible to create a bitcoin clone (bitDNS) that provides a solution to distributed authority-free name allocation and transfer.\n\nBasically, the system is a copy of bitcoin where miners generate 50 new name mappings of their choosing whenever they win a block.  The name mappings change hands in a way similar to btc.\n\nThis system is separate from btc, and it is likely that escrow services will provide a name market in btc, since any such escrow can leverage the two block chains to verify transactions.  Miners can pick names that are already being bid upon with funds in escrow to make sure they are able to sell generated names quickly.\n\nGeneralizing Bitcoin: BitX\n\nThis is all well and good, but now there are two block chains, and any given miner can only generate for one at a time.  This will be really bad when even more clever applications are developed that require bitcoin-like properties but will be susceptible to attack in their early development.  Enter BitX, designed to support any and every such application on a single block chain.\n\nBitX has a block chain like bitcoin's.  However, miners choose to distribute arbitrary application data in the following manner:\n\n1) The payload in a block is a mapping from application names to hashes: [\"bitcoin\": <hash>, \"bitDNS\": <hash>, \"bitHaiku\": <hash>, ...]\n\n2) Any given block is only allowed to create one new application that does not already appear somewhere in the block chain.  This is to prevent spam.\n\n3) Any given block may omit data for any application.  Similarly to the current situation, miners have a choice as to what transactions to include, and this extends to the choice over which applications to choose to send data for.\n\n4) Application data is transfered separately, so for instance a bitcoin client will never have to care about haikus or DNS names, as it can simply ask someone for the bitcoin payload and make sure it matches the hash in the appropriate block.\n\n5) On the client side, blocks are only ever rejected for an error relating to the previous four points.  In other words, blocks aren't rejected for carrying a faulty bitcoin payload, because this might result in rejecting valid DNS transfers.  Instead, bitcoin clients accept the most recent block but ignore the invalid bitcoin transactions.\n\nMiners will engage in activities they feel profitable.  For example, miners may not see a profit motive in haikus, but will want to generate DNS names because they can be sold easily.  I think this system could support a very wide range of useful applications while adding only a minimal overhead to the block chain itself.  Application proliferation is kept in check by the interests of the miners themselves.\n\nThis also seems to make the block chain more modular, as it separates concerns; the block chain is strictly for creating a universal state of the system for everyone in the world, and application data travels out of band but is verified against the block chain.\n\nOne effect of the modularity is that applications can ignore illegal or undesirable application data and only download payloads for the applications they care about.\n\nAs a last thought: BitX poses a significant threat to bitcoin, because money may not be the \"killer app\" for the block chain.  In other words, what happens when bitBeanieBabies becomes bigger than bitcoin?  Suddenly the bitcoin system doesn't seem as secure.  If both were running on top of BitX, they would enhance each other's security, and interfere with one another minimally.\n\nThanks for reading,\nAppamatto"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22019#msg22019"},{"f":"Cdecker","d":1289853632,"b":[["t","Just for reference, the discussion on IRC starts here http://bit.ly/9qjLL5"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22138#msg22138"},{"f":"Gavin Andresen","d":1289864625,"b":[["t","So....\n\nI want to register a new domain name \"gavin.bitdns\" in this hypothetical bitdns system.\n\nHow do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!\n\nOr I want to buy a domain from somebody; what does that look like in the bitdns system?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22171#msg22171"},{"f":"appamatto","d":1289876786,"b":[["q","So....\n\nI want to register a new domain name \"gavin.bitdns\" in this hypothetical bitdns system.\n\nHow do I do it?  Run a BitX miner and hope that I generate a block sometime in the next week or three?  Ummm... yuck!\n\nOr I want to buy a domain from somebody; what does that look like in the bitdns system?","Quote from: gavinandresen on November 15, 2010, 11:43:45 PM"],["t","It's pretty much the same as starting a separate service.  You have to convince a few people to use your system.\n\nBut in this case, there are some incentives for a BitX miner to adopt your new BitX app (in this case, bitDNS).\n\nFor one, it doesn't impact the miner's mining speed.  And he would end up with a possibly valuable resource in the form of a very big head start on bitDNS registrations.\n\nConsider the case in which there are 5 big BitX miners that each control large processing pools.  They each generate 20% of bitcoins (which is now running on the BitX protocol) yet the first one to generate bitDNS names would generate 100% of names until the second adopted bitDNS as well, and this would be at no cost to him.\n\nIn the case of buying a name, you need an escrow that will temporarily hold the btc and the name until they are both confirmed, and then pass them along to the new owners.  I think it's best to keep btc and dns completely separate so that they can succeed or fail independently yet leverage the single block chain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22204#msg22204"},{"f":"appamatto","d":1289878754,"b":[["t","I thought about the BitX block format more today, and (with the help of ByteCoin on irc) decided that block rejection is an important part of the system.  So, the format would work more or less like the following:\n\n<previous block hash>\n<timestamp>\n\n<hash of app name> <hash of app data> <previous app block offset>\n<hash of app name> ....\n\n<nonce>\n\nBasically, there is the BitX block chain which is maintained in the first field.  But there are also \"subchains\" for each app.  The \"previous app block offset\" is the number of blocks to travel backwards in the chain to find the last previous block for this app.\n\nOmitting some details, a Bitcoin fork would appear as follows, inside a non-forked BitX chain:\n\nblock 0:\n<empty, this is the genesis block>\n(bitcoin) datahash... 0\n\nA previous app block offset of zero indicates that this is a genesis block for that app.  Each BitX block is only allowed to specify a genesis block for one app.\n\nblock 1:\n<hash of block 0>\n(bitcoin) datahash... 1\n\nThis is a continuation of the last BitX block and it also claims to be a successor of the previous block's bitcoin chain.\n\nblock 2:\n<hash of block 1>\n<empty>\n\nIt's perfectly legit for any given application to not appear in a block.\n\nblock 3:\n<hash of block 2>\n(bitcoin) datahash... 3\n\nThis is a continuation of the BitX chain, but it has rejected the previous bitcoin block.  Clients will now have to accept one bitcoin app block and reject the other, but there is no reason to reject the BitX block.  The rejected bitcoin app block will stay in the BitX block chain, but it will not be part of the longest valid bitcoin block chain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22212#msg22212"},{"f":"Cdecker","d":1289890395,"b":[["t","Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22235#msg22235"},{"f":"appamatto","d":1289919185,"b":[["q","Since more and more of these ideas to uniquely acquire some virtual resource appear, why not abstract away the entire, domain specific, logic and just create a service that does p2p proof of work all day long, on which the services can be implemented? It might help strengthen the main chain, by basing multiple applications on it, and might reduce the repetitive work for each system, since the basis is already there.","Quote from: Cdecker on November 16, 2010, 06:53:15 AM"],["t","I think that's exactly what I'm suggesting.  BitX is a block chain service (not sure how this differs from 'p2p proof of work') that supports arbitrary applications, such as bitcoin, bitDNS, ..."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22276#msg22276"},{"f":"Cdecker","d":1289929511,"b":[["t","So now the question is what kinds of central authorities can be replaced by this type of quorum?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22293#msg22293"},{"f":"ByteCoin","d":1290057260,"b":[["t","I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.\n\nThere would have to be some incentive to support an app in this way. Some form of payment.... hmmm\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22539#msg22539"},{"f":"appamatto","d":1290061738,"b":[["t","ByteCoin, I think you can just keep a pointer to the last valid block per app in the big block chain.\n\nSo, when you mined, you would produce new app data for each app you cared about and stick the hash of that data as well as pointer to the previous vaild app block (per app you care about) into the big block chain.\n\nIn other words, the big chain has a next pointer to the last valid big block, as well as a next pointer to each last valid app block you care about.  So, if you think there was an invalid app block, you can still add to the longest big block chain and reject the invalid app block by pointing further back in the chain to the last valid (in your view) app block.\n\nYou don't have to know about every app in this case.  This plan still retains the bonus that miners can mine for as many apps as they want."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22545#msg22545"},{"f":"asdf","d":1290062306,"b":[["t","I didn't read the thread, but you might be interested in the Netsukuku solution to distributed dns:\nhttp://en.wikipedia.org/wiki/Netsukuku#A_Netsukuku_Domain_Name_Architecture\n\nNetsukuku:\nhttp://netsukuku.freaknet.org/"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg22546#msg22546"},{"f":"Anonymous","d":1291121681,"b":[["t","http://p2pdns.baywords.com/2010/11/30/hello-world/\n\nI just found this from Peter Sunde who wants to create a decentralized dns system."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg25716#msg25716"},{"f":"gekko","d":1291140062,"b":[["t","A lot of collaboration on a decentralized DNS by the bittorrent community is occurring here:\n\nhttp://dot-p2p.org/index.php?title=Main_Page\n\nThe brainstorming session is here. BitDNS/Bitcoin could provide them with a lot of the source code needed:\n\nhttp://dns-p2p.openpad.me/1"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg25779#msg25779"},{"f":"kiba","d":1291140397,"b":[["t","Quick! Offer a bounty in bitcoin!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg25782#msg25782"},{"f":"sandos","d":1291191974,"b":[["t","If you just allow any number of applications \"on top\" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!\n\nMaybe make it a tad bit hard to add applications?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg25851#msg25851"},{"f":"kiba","d":1291224425,"b":[["q","If you just allow any number of applications \"on top\" of bitcoin, isn't that a bit messy? Suddenly some guy says he invented this bitdns2 where all domains are available!\n\nMaybe make it a tad bit hard to add applications?","Quote from: sandos on December 01, 2010, 08:26:14 AM"],["t","Hmm? I thought we're going to use a separate blockchain than what bitcoin use."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg25944#msg25944"},{"f":"bober182","d":1291249346,"b":[["t","I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.\nhttp://dot-p2p.org/index.php?title=Main_Page\nhttp://wiki.opennicproject.org/dotP2PTLD"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26071#msg26071"},{"f":"kiba","d":1291249525,"b":[["q","I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.\nhttp://dot-p2p.org/index.php?title=Main_Page\nhttp://wiki.opennicproject.org/dotP2PTLD","Quote from: bober182 on December 02, 2010, 12:22:26 AM"],["t","Calling something retard and having no substance to back it up is not a good argument."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26074#msg26074"},{"f":"tyler","d":1291249856,"b":[["q","> Quote from: bober182 on December 02, 2010, 12:22:26 AM\n> I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.\n> http://dot-p2p.org/index.php?title=Main_Page\n> http://wiki.opennicproject.org/dotP2PTLD\n\nCalling something retard and having no substance to back it up is not a good argument.","Quote from: kiba on December 02, 2010, 12:25:25 AM"],["t","retarded means \"slowed\" which ironically is the case here"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26077#msg26077"},{"f":"kiba","d":1291250465,"b":[["q","retarded means \"slowed\" which ironically is the case here","Quote from: tyler on December 02, 2010, 12:30:56 AM"],["t","Huh"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26080#msg26080"},{"f":"tyler","d":1291251113,"b":[["q","> Quote from: tyler on December 02, 2010, 12:30:56 AM\n> retarded means \"slowed\" which ironically is the case here\n\nHuh","Quote from: kiba on December 02, 2010, 12:41:05 AM"],["t","retard - cause to move more slowly or operate at a slower rate; \"This drug will retard your heart rate\"\n\nmeaning... using a bitcoin based dns will be slow to adopt"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26082#msg26082"},{"f":"kiba","d":1291252963,"b":[["q","retard - cause to move more slowly or operate at a slower rate; \"This drug will retard your heart rate\"\n\nmeaning... using a bitcoin based dns will be slow to adopt","Quote from: tyler on December 02, 2010, 12:51:53 AM"],["t","Not really. Since, 144 blocks were generated each day in the bitcoin network, this mean 7200 addresses that can be assigned a domain name. Plenty, if you asked me."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26092#msg26092"},{"f":"RHorning","d":1291258996,"b":[["q","I've been thinking about your scheme appamato and as we discussed, rejecting invalid blocks and only working on the longest chain is a critical part of the security of these schemes. Therefore all hashing clients need to have the logic to tell the good from the bad. Ths could be done by distributing the appropriate logic for each app as java bytecode or .NET stuff. All clients would therefore understand all apps.\n\nThere would have to be some incentive to support an app in this way. Some form of payment.... hmmm\n\nByteCoin","Quote from: ByteCoin on November 18, 2010, 05:14:20 AM"],["t","It is funny how people are thinking about the same issue at the same time.  I have been trying to think of some way that another \"chain\" using Bitcoin principles of hashing might be able to use Bitcoins as a transaction fee:\n\nhttp://bitcointalk.org/index.php?topic=2028.0\n\nThe issue here is that you would need some way for those \"mining\" new blocks into this sort of DNS data block chain (or any other kind of similar data protected by a hash chain with miners) to receive some sort of transaction fee for processing that chain.  In this case, the incentive for processing the DNS entries would be to receive these transactions fees.... which could be quite considerable depending on what people would be willing to pay for a domain name under this system.\n\nI have considered perhaps an alternative, which would have the main Bitcoin miners of the main chain have as \"optional\" transactions to be processing in such a way that could let the miner itself keep these transaction fees.  My main objection to doing that is that it puts far too much processing into miners and makes a bottleneck that I think we would all rather not have.  Bitcoin miners ought to be for bitcoin transactions alone, but it is at least something to consider.\n\nThis thread I mention here goes into the technical details, but it is something that could help with this idea too.  I haven't completely \"solved\" the problem, but I have at least identified what issues need to be solved.\n\nBesides, it would be nice if there were other ways for those interested in using Bitcoins to be able to earn them since the main mining of coins is now being locked up with with stronger computers and GPU miners of various kind including server farms.\n\nThe one advantage here of using a fee is to avoid a tragedy of the commons, where those who want to register a domain or transfer \"ownership\" of that domain would have to put up real money to do so.  The fees don't go to some central processing bureau or organization, but rather to those who are doing the real work, which is processing the actual domain registrations itself."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26114#msg26114"},{"f":"Anonymous","d":1291265400,"b":[["q","I find tieing in bitcoins to DNS retarded. There are already some other p2p DNS systems that need help lifting off the ground why make a new one.\nhttp://dot-p2p.org/index.php?title=Main_Page\nhttp://wiki.opennicproject.org/dotP2PTLD","Quote from: bober182 on December 02, 2010, 12:22:26 AM"],["t","Bitcoin would be more for buying and selling domains I think. Any profits involved could go to the EFF which already accepts bitcoin donations. In a sense this would tie dns and domain names to the health of the EFF.\n\n Smiley  Id like to see the government try and seize domains from those guys ,can you imagine the shitstorm that would create  Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26137#msg26137"},{"f":"kiba","d":1291266050,"b":[["t","How would domain name renewal work?  Huh"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26139#msg26139"},{"f":"RHorning","d":1291268206,"b":[["q","How would domain name renewal work?  Huh","Quote from: kiba on December 02, 2010, 05:00:50 AM"],["t","Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee. "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26145#msg26145"},{"f":"kiba","d":1291271607,"b":[["q","Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee.","Quote from: RHorning on December 02, 2010, 05:36:46 AM"],["t","I see. Then the miners will set the fee for domain renewal."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26162#msg26162"},{"f":"RHorning","d":1291303771,"b":[["q","> Quote from: RHorning on December 02, 2010, 05:36:46 AM\n> Presumably if the protocol requires a renewal transaction, the identity authentication system (likely a public/private hash key) would allow you to create a new \"transaction\" on the network submitting the necessary information along with a transaction fee.\n\nI see. Then the miners will set the fee for domain renewal.","Quote from: kiba on December 02, 2010, 06:33:27 AM"],["t","Exactly!  It would become a marketplace where those people willing to put resources into building this chain would set the fee they think is most appropriate.  I really don't see this happening without fees getting put in at some point.\n\nThis is also something where deflation would be dealt with through the marketplace as well, as there would be increased competition if transaction fees started to get a little high where somebody offering to take on perhaps slightly lower transaction fees would push their way into the block making competition.  So if 0.01 BTC becomes worth $100, there might even be many \"miners\" willing to charge perhaps only 0.001 BTC or an even smaller amount."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26213#msg26213"},{"f":"ribuck","d":1291310183,"b":[["t","I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.\n\nThe fees could come from domain name transfers, and of course the generation of new domain names."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26230#msg26230"},{"f":"kiba","d":1291310475,"b":[["q","I assumed you would have the domain name forever without further fee. After all, we don't pay an annual fee to keep our bitcoins working.\n\nThe fees could come from domain name transfers, and of course the generation of new domain names.","Quote from: ribuck on December 02, 2010, 05:16:23 PM"],["t","If someone lost their wallet, their domain name stay with them forever, with no way to transfer it.\n\nEventually, you get a long string of really good domain name that can't be used forever."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26231#msg26231"},{"f":"ribuck","d":1291311022,"b":[["q","Eventually, you get a long string of really good domain name that can't be used forever.","Quote from: kiba on December 02, 2010, 05:21:15 PM"],["t","It's the same as with bitcoins, it just makes the remaining names more valuable."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26233#msg26233"},{"f":"kiba","d":1291311200,"b":[["q","It's the same as with bitcoins, it just makes the remaining names more valuable.","Quote from: ribuck on December 02, 2010, 05:30:22 PM"],["t","if sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.\n\nIt doesn't necessary make other domain names more valuable. What it does though is make certain resource useless."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26234#msg26234"},{"f":"ribuck","d":1291312175,"b":[["q","...if sex.bitcoin is lost ... It doesn't necessary make other domain names more valuable","Quote from: kiba on December 02, 2010, 05:33:20 PM"],["t","The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.\n\nI don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26236#msg26236"},{"f":"kiba","d":1291312342,"b":[["q","The loss of sex.bitcoin would surely make sexy.bitcoin and xxx.bitcoin more valuable.","Quote from: ribuck on December 02, 2010, 05:49:35 PM"],["t","I concede that one."],["q","I don't argue from a matter of principle, just from a personal preference that I would prefer non-expiring but losable domain names, compared to ones that must be renewed regularly or lost to others.","Quote"],["t","Then this is a matter of competition between various BitDNS system then."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26237#msg26237"},{"f":"RHorning","d":1291312485,"b":[["q","> Quote from: ribuck on December 02, 2010, 05:30:22 PM\n> It's the same as with bitcoins, it just makes the remaining names more valuable.\n\nif sex.bitcoin is lost for example, it can't be used forever. And there is only one sex.bitcoin in the whole universe.\n\nIt doesn't necessary make other domain names more valuable. What it does though is make certain resource useless.","Quote from: kiba on December 02, 2010, 05:33:20 PM"],["t","In theory you could also put a \"lease\" on that domain so that after a certain period of time defined within the network protocol the lease would expire.  In this case, if somebody \"lost\" their wallet the domain could become available after the lease expires.  It wouldn't necessarily make the domain worthless either, as the IP address associated with the domain would still be valid, and the domain would still resolve even after the wallet was lost, but if there was an issue where the person owning the domain switched to another network (and a different IP address) it could be a bit of a problem.\n\nNone of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26238#msg26238"},{"f":"kiba","d":1291312591,"b":[["q","None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain.","Quote from: RHorning on December 02, 2010, 05:54:45 PM"],["t","Can you please explain what you mean by this?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26239#msg26239"},{"f":"RHorning","d":1291313153,"b":[["q","> Quote from: RHorning on December 02, 2010, 05:54:45 PM\n> None of these are intractable problems, and IMHO much of this makes domain addresses much more secure than is the case at the moment with domain addresses you get from GoDaddy, Verisign, or ICANN directly.  Social hacking and some other generally minor hacking by somebody with just some casual knowledge about computers is all that is really necessary at the moment to change most domain registrations or \"steal\" a domain.\n\nCan you please explain what you mean by this?","Quote from: kiba on December 02, 2010, 05:56:31 PM"],["t","What do you need explained?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26242#msg26242"},{"f":"kiba","d":1291313213,"b":[["q","What do you need explained?","Quote from: RHorning on December 02, 2010, 06:05:53 PM"],["t","Why is it so easy? How is it done?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26244#msg26244"},{"f":"RHorning","d":1291315561,"b":[["q","> Quote from: RHorning on December 02, 2010, 06:05:53 PM\n> What do you need explained?\n\nWhy is it so easy? How is it done?","Quote from: kiba on December 02, 2010, 06:06:53 PM"],["t","It depends on the domain registrar and a few other factors.  Back when ICANN ran domain registrations directly, all you needed to do was to simply spoof the e-mail address of the person who made the registration and change the contact information... hoping that the reply from ICANN would get lost in the junk mail with spam and other garbage.  Once you switched the contact information, switching almost everything else was incredibly trivial and a piece of cake.\n\nIt is a bit harder now and the domain registrars do require a bit more identifying information, but nothing that a good private investigator would be unable to provide.  Really, the current domain registration is incredibly insecure and there are even \"legal\" means to \"steal domains\" that merely need a pretty competent attorney to cover your back if you want to do it through the judicial system.  That is how nissan.com was taken from a small business in southern California in spite of the fact that the last name of the guy really was \"Nissan\" running a used car business with the name \"Nissan Motors\" and registered the domain well before the perhaps more famous automobile company got the domain changed.\n\nOn top of that, the DNS system itself is very much open to attack as long as you can somehow get trusted as a \"peer\" by one of the main root servers.  There are various kinds of attacks upon DNS records themselves which can be done, some easier than others and some of them requiring better knowledge about computer networking than others, although there are some \"kiddie scripts\" and \"hackerwarez\" that you can get to do all of this is you really want to.  I'd strongly suggest staying away from those program mainly because they are trojan and virus sources if you try to just Google for them.  In other words a good way to get your system rooted and part of a bot net not under your control if that is your goal.  If you want to go the hacker route, learning about the protocol itself and sticking to discussion groups is a much better route to go.\n\nNone of this is new to somebody who is familiar with the DNS system, and it really is just a house of cards much flimsier than what anybody can possibly believe if you aren't familiar with how it was all set up in the first place.\n\nMy point is that using a simple sort of cryptographic storage for the registration of the information is vastly more secure in terms of making sure the information doesn't get tampered with or manipulated that the current system.  Even DNSSEC, the supposed \"savior\" of the DNS system to keep spoofing from happening (and largely unimplemented by most ISPs unfortunately even for that level of security) is only as good as the domain registrar's security.  Social hacking can still happen.\n\nIt is for this reason that I think a bitcoin-related system would work much better and be insanely simple to operate.  On top of that, there would be no gatekeeper in terms of who gets authority to decide if you get the registration.  You simply apply, throw in the fees for processing the application, and the domain registration gets put into the system.\n\nIn terms of the \"leasing\" option, the only advantage of doing that which I can see is to make sure that the domain itself remains in the \"public domain\" at some point.  Domain registration is a public service and unfortuantely there are people who have taken domain registrations as a sort of \"land grab\" where the earliest get the best stuff first.  By putting a leasing ability into the standard (and the \"lease\" is from all of mankind, not any individual), it forces those who grabbed the domains early on to do some \"work\" or at least pay up to maintain those leases.  Presumably if maintaining those domains is expensive, they'll simply let them expire rather than having to constantly renew the domains.  It also provides a source of revenue for those who are mining blocks as well so it also maintains the integrity of the database... in other words the chain of blocks being used to keep track of all of this information."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26245#msg26245"},{"f":"bober182","d":1291331414,"b":[["t","Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26279#msg26279"},{"f":"RHorning","d":1291355801,"b":[["q","Or all domains expire yearly and will need to be regenerated, but if you send it to yourself before it ends you get to keep it. Like this we fix the issue of lost domains and allow dropping old names for free.","Quote from: bober182 on December 02, 2010, 11:10:14 PM"],["t","I don't have a problem with somebody \"renewing\" their lease in some manner where they have at least \"first try\" at keeping that lease.  The \"public good\" coming from paying the lease fees is maintaining the network.\n\nI don't understand this \"sending it to yourself\" however.  The domain registration would be something confirmed by a network.  If you were mining these blocks, you might get lucky and mine the block you are also using to register a domain, but perhaps you wouldn't be doing that either."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26354#msg26354"},{"f":"bober182","d":1291418739,"b":[["t","Its like bitcoins but time based old domains get freed up after 365 days, if you want to keep it just send it to someone or to yourself."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26614#msg26614"},{"f":"kiba","d":1291453308,"b":[["q","<genjix> dot-p2p: \"We currently believe the best way to create a stable\n    environment for TLDs is to enact a central authority. We know this\n    will cause much argument within the community, but we have made the\n    decision that we believe will be best for the continued development\n    of this project.\"","Quote from: irc"],["t","Knew it. They sucks.\n\nOur opportunity is now, but unfortunately I think we lack the expertise to create a BitDNS."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26739#msg26739"},{"f":"kiba","d":1291454012,"b":[["t","http://bitcointalk.org/index.php?topic=2072.0\n\nStarted a pledge drive. Go. Go. Go."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26743#msg26743"},{"f":"Hal","d":1291492071,"b":[["t","Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.\n\nA domain name entry in this system has 3 parts:\n\n - the name itself (e.g. example.bitdns)\n - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)\n - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)\n\nWhen you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.\n\nSubsequently a name might have two things happen to it:\n - the IP address of the DNS server might change\n - it might be transferred to a new owner\n\nBoth of these might be handled the same way, via a BitDNS transaction. The transaction would contain:\n - the domain name\n - the new owner key hash\n - the new IP address of the DNS server\nAnd it would be signed by the old owner private key.\n\nAs with Bitcoin, transactions would be broadcast and incorporated into the next block by miners.\n\nIs this what people have in mind?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26846#msg26846"},{"f":"ribuck","d":1291494134,"b":[["t","That's very clearly expressed, thank you Hal.\n\nWhat you describe is almost exactly what I have in mind. Additionally, I would allow the domain name itself to be subsequently changed to any other untaken name:"],["q","Subsequently a registration might have three things happen to it:\n - the IP address of the DNS server might change\n - it might be transferred to a new owner\n - the domain name might be changed","Quote"],["t","The advantage of allowing domain name changes is that it makes the initial registration easier. Registrars can generate arbitrary registrations, then change the name when they sell them to their customers."],["q","When you generate a block you get to create 50 of these entries","Quote"],["t","Exactly. The \"50\" is arbitrary, but that doesn't matter. The initial scarcity will be reflected in a high price, which will encourage people to generate, which will raise the difficulty and ensure the security of the system.\n\nWith 7200 registrations being generated daily, there will soon be plenty to meet the demand. The price will then drop, with transaction fees maintaining the incentive to generate."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26857#msg26857"},{"f":"RHorning","d":1291495451,"b":[["q","Let me clarify how I understand the BitDNS idea. First, I think it is somewhat misnamed, as we would not propose to replace the entire decentralized DNS infrastructure of A records, CNAMEs, TTL values, etc. What we want to change is the registrar function, which keeps track of who owns each name.\n\nA domain name entry in this system has 3 parts:\n\n - the name itself (e.g. example.bitdns)\n - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)\n - the IP address of the authoritative DNS server for the name (e.g. 1.2.3.4)\n\nWhen you generate a block you get to create 50 of these entries, and you then own those 50 names. Of course they have to be new names that were not in earlier blocks.","Quote from: Hal on December 04, 2010, 07:47:51 PM"],["t","I hope we aren't at cross purposes here as there are multiple ideas.  My idea was more that you would throw in a \"transaction\" that would have a few bitcoins attached (as the transaction fee) so that any potential miner would be encouraged to put that particular \"registration\" into a block chain like the Bitcoin mining blocks.  The \"owner\" is merely the person who paid the fee and is identified by a private/public hash like the Bitcoin addresses are being used right now.  In fact, I would propose that the \"owner\" of a particular domain might as well be a Bitcoin address unless we can think of a more secure way of claiming such ownership.... which would be of value to the Bitcoin project if you can show it would be unsecure.  It is tying the domain ownership to your wallet.dat file making your wallet even more valuable if you got one of these domains.  The actual hash is irrelevant other than it should be defined in the protocol.\n\nA block would have a limited number of \"transactions\" in it... perhaps just 1 but it could be 50 or slightly more.  I don't mind putting a limit at 50 per block in the sense that it might drive up the value of an individual domain and set up some interesting economic theories so far as supply and demand are concerned.  That is a network rule to define in this case.  Obviously a miner could create one of these \"domains records\" for \"free\", but then again they are contributing to defending the integrity of the database through CPU proof of work.\n\nSo really a domain entry would be:\n\n - the name itself (e.g. example.bitdns)\n - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)\n - an optional key which could identify a \"new\" owner in the case of somebody transferring control of the domain\n - the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)\n - transaction fee paid in BTC\n\nA block entry would also have a timestamp that could be rejected if it was for some time in the future\n\nAs a network rule any name collisions that can't be resolved as from the same person making a request for changes would be rejected.  The cost to run this network would be through the transaction fees, where a \"miner\" may be as inclusive or selective as they care based upon the transaction fees involved.  Miners might have a different fee schedule for \"new\" domains as opposed to existing domains and could discriminate on that basis... or simply only select to process one kind or another.  All of this would be essentially a marketplace where those trying to \"register\" domains are playing chicken with those making the blocks, presumably with the miners wanting higher fees and those registering domains wanting lower fees.  My bet is that domain registration fees would be considerably lower than what GoDaddy charges or for that matter any other domain registrar other than those who simply do it for free.  Maintaining the DNS records does have a cost, which is the purpose of the transaction fee as well.\n\nThe only glitch here that I can see is trying to get those transaction fees to the miner.  The miner needs to be able to demonstrate proof of work before they get paid, and presumably that the proof involved has generally been accepted into the network before they get paid as well.  Otherwise, all I can see is that people are being altruistic and simply mining as a free public good.... which has problems related to a tragedy of the commons as well.  I personally think that you should \"pay your own freight\" for things like this.  Besides, it provides another way for people to earn bitcoins simply by leaving their computer running if you can get the transaction fees for running such a DNS mining application processing these records.\n\nBTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:\n\nhttp://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1\n\nI'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this.  It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try.  Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26861#msg26861"},{"f":"kiba","d":1291495800,"b":[["q","ames. Of course they have to be new names that were not in earlier blocks.\n\nBTW, I created a stub of a document on the wiki for this concept if anybody is interested in filling out some more details of this idea in terms of a formal spec:\n\nhttp://www.bitcoin.org/wiki/doku.php?id=bitdns_draft_0_1\n\nI'll see what I can contribute to filling this out, and I'm thinking of bumping this idea up on my own priority schedule for perhaps writing an application to do this.  It sounds like something to really get my teeth into even though I got a couple of other good ideas I'd like to try.  Besides, it sounds like there is some real interest to get this going sooner rather than later among many in the Bitcoins community.","Quote from: RHorning on December 04, 2010, 08:44:11 PM"],["t","I am using this document as the BitDNS bounty's protocol document."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26862#msg26862"},{"f":"Hal","d":1291501501,"b":[["q","So really a domain entry would be:\n\n - the name itself (e.g. example.bitdns)\n - a hash of the owning public key (e.g. djiusjfkrhffhdehyormavtrr...)\n - an optional key which could identify a \"new\" owner in the case of somebody transferring control of the domain\n - the IP address(es) of the authoritative DNS server for the name (e.g. 1.2.3.4)\n - transaction fee paid in BTC\n\nA block entry would also have a timestamp that could be rejected if it was for some time in the future.","Quote from: RHorning on December 04, 2010, 08:44:11 PM"],["t","I see, that makes sense. I have an idea about the transaction fee. What if this were integrated with Bitcoin itself? This would be a different kind of transaction that would be mixed with regular Bitcoin transactions and included in regular Bitcoin blocks. Then the block creator would automatically receive the transaction fee just like all the other tx fees in the block.\n\nIf that sounds good, I see a way this could be implemented into the current Bitcoin system compatibly with current clients. We could use the mysterious and extravagant \"scripting\" system to add additional data to regular Bitcoin transactions. These would look like NOPs to current clients and be ignored, but BitDNS aware clients would look inside this NOP block and see the extra DNS data, and interpret it as BitDNS transfers.\n\nSpecifically i could imagine using OP_NOP1 to mean BitDNS, then OP_PUSHDATA to push the DNS info, then OP_DROP to drop it from the stack, followed by the regular tx opcodes. This will have no effect on regular clients and look like a regular transaction (can be a dummy tx, 0.01 to yourself) but BitDNS aware code sees a BitDNS transaction. This is actually a powerful general technique for adding overlay protocols to Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26880#msg26880"},{"f":"ShadowOfHarbringer","d":1291512691,"b":[["t","Sorry for being too lazy to read all previous posts...\n\nBut has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26917#msg26917"},{"f":"kiba","d":1291512969,"b":[["q","Sorry for being too lazy to read all previous posts...\n\nBut has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?","Quote from: ShadowOfHarbringer on December 05, 2010, 01:31:31 AM"],["t","People already put up links about BitDNS."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26921#msg26921"},{"f":"Anonymous","d":1291525927,"b":[["q","Sorry for being too lazy to read all previous posts...\n\nBut has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?","Quote from: ShadowOfHarbringer on December 05, 2010, 01:31:31 AM"],["t","Several bitcoiners have been in the p2p-dns irc chat and have spoken about it.\n\nIts also been written about on their wiki.\n\nhttp://dot-p2p.org/index.php?title=Draft_Discussion_Paper  they have a discussion paper out but looks like they have opted for using open nic for now plus a .key domain for a decentralized dns.\n\nAs far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.\n\nHow does bitdns get around that?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26962#msg26962"},{"f":"kiba","d":1291526076,"b":[["q","As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.\n\nHow does bitdns get around that?","Quote from: Anonymous on December 05, 2010, 05:12:07 AM"],["t","A domain name key should be so important that people will backing it up, automatically."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26963#msg26963"},{"f":"Anonymous","d":1291526630,"b":[["q","> Quote from: ShadowOfHarbringer on December 05, 2010, 01:31:31 AM\n> Sorry for being too lazy to read all previous posts...\n>\n> But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?\n\nPeople already put up links about BitDNS.","Quote from: kiba on December 05, 2010, 01:36:09 AM"],["t","I added bitdns to the ideas page here\nhttp://dot-p2p.org/index.php?title=Ideas#BITDNS"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26965#msg26965"},{"f":"kiba","d":1291534397,"b":[["q","I added bitdns to the ideas page here\nhttp://dot-p2p.org/index.php?title=Ideas#BITDNS","Quote from: Anonymous on December 05, 2010, 05:23:50 AM"],["t","The likelyhood of the idea getting implemented is likely slim to none."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg26985#msg26985"},{"f":"RHorning","d":1291547266,"b":[["q","> Quote from: ShadowOfHarbringer on December 05, 2010, 01:31:31 AM\n> Sorry for being too lazy to read all previous posts...\n>\n> But has anybody actually proposed using bitcoin algorithms to create decentralized DNS to Peter Sunde yet ?\n\nAs far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.\n\nHow does bitdns get around that?","Quote from: Anonymous on December 05, 2010, 05:12:07 AM"],["t","I think this is a good argument against almost any peer-to-peer distributed database of any kind.  This isn't something unique to just Bitcoin.\n\nAll of this is sort of strange, as I thought the whole point of the exercise was to try and decentralize the DNS database.  Instead, there is going to be a central point of control for the whole thing and an official \"authority\" who is going to be acting as a gatekeeper.  Really, this seems to be a betrayal of whatever it is that they were trying to accomplish and they are now becoming an alternate to ICANN, not something which is really a genuine distributed domain repository.  There may be some differences as it may become a sort of Napster of domain registration, but it still has that point of attack, whatever that attack may be from either a digital, legal, or physical kind of attack.\n\nIt is too bad that they aren't rethinking the entire issue down to its roots, which is an attempt to create a \"directory\" of the internet.  They are also getting IMHO hyper-paranoid about trademarks, as if coca-cola.com isn't sufficient to identify a particular corporation that most people know anyway.  So what if somebody creates coca-cola.p2p?  Or for that matter wikipedia.p2p?\n\nThere also seems to be a mindset that it must follow the convention of:\n\n<computer> <dot> <domain> <dot> <top level domain>\n\nThere was an historical reason for the original divisions for .com, .mil, and .edu.  They represented three distinct and separate networks originally called \"COM-NET\", \"MIL-NET\", and \"EDU-NET\".  It is sort of like how telephone systems used to be completely separated between business exchanges and residential exchanges.  When the three networks were finally linked, they had to use some way to identify how to access computers on one network to another, so the \"TLD\" system was originally set up and some other side \"TLDs\" were made for \"miscellaneous organizations\" (.org), \"international organizations\" (.int), and generic \"network resources\" (.net).  When people outside of America were participating in adding their networks to the internet, they were identified by their country code , now the various \"country code top level domains\".\n\nMind you, when the codes were handed out, there was the .us domain which seemed redundant (it was) but those already having .com didn't want to go to a longer .com.us.\n\nAnyway, I contend that the whole notion here of a top level domain is something that completely unnecessary, and that viewpoint has been long advocated by Karl Auerbach <http://www.cavebear.com/>.  If you've never heard of this guy, it should be important that he was the one and unfortunately only official elected representative of North America to ICANN, and sort of a major rebel.  He was one of the \"at-large\" directors that had to get a California court to force ICANN to actually show him their books (he was one of the members of their board of directors and supposedly recognized as such by the organization) and because of his efforts his position was dissolved by the appointed board members made up of people hand-picked by major corporations.  The whole experiment of democratically elected representatives to ICANN was killed by the U.S. Department of Commerce... isn't that something?\n\nAnyway, if anybody knows DNS backward and forward, it is Karl Auerbach, and one of his positions when he was on the ICANN board was that there was no need to even have a top-level domain system at all, and certainly the number of top level domains could certainly number in the millions or more.  It is simply a directory.\n\nThis history paper <http://www.cavebear.com/archive/nsf-dns/> about DNS goes into the gritty details of how it finally got started.  This really is a seminal paper on the history of DNS in terms of how we got to where we are today.\n\nAnother paper by Karl Auerbach <http://www.cavebear.com/archive/nsf-dns/ntia-comments.html> is certainly worth reading so far as to see what a very well thought out objection to the current DNS system as implemented by ICANN was and how when the whole system was created had people proposing some significant alternatives.  Since supposedly we are talking about alternatives to the centralized DNS, I think this ought to be at least one of the key papers worth reading.  It shouldn't be surprising that the problems he identified over twenty years ago are still present in the current system, and it is important to note that there was opposition back then even to the current system.  If you read between the lines, he was even upset over how IP addresses were allocated... which is a completely different beast altogether.\n\nI don't think that those working with this new \"dot P2P\" effort are really reading stuff of this nature.  I find it too bad as well, as it shows the immoral and arguably illegal actions taken by those who set up the current system almost as if it was a sort of Jekyll Island episode of the Internet.  There are a whole bunch of common parallel themes between the formation of ICANN and the Federal Reserve.  In this sense, perhaps Bitcoin really is a good fit as it sort of is a merger of the two systems that have been corrupted by aristocrats in a supposedly egalitarian and \"officially\" classless society.\n\nIn short, I think that the \"dot P2P\" effort is doomed to failure if the continue down the path they are going and not addressing the real problems facing the current system.  Many of those problems are being addressed by BitDNS, even if it is a bit marginalized at the moment.  And I also think that the argument about lost keys is not something nearly as significant either compared to the major issues about what is wrong with the current DNS system."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27008#msg27008"},{"f":"balboah","d":1291548478,"b":[["t","There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.\n\nCheck out http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/\nand http://dot-p2p.org/"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27013#msg27013"},{"f":"Anonymous","d":1291552618,"b":[["q","There are others into the subject of a P2P dns as well, Peter Sunde (former spokesman of the pirate bay) was also talking about this a couple of days ago.\n\nCheck out http://techcrunch.com/2010/11/29/peter-sunde-seconds-the-idea-of-an-alternative-root-dns/\nand http://dot-p2p.org/","Quote from: balboah on December 05, 2010, 11:27:58 AM"],["t","Yes that is what we are discussing. I was in the irc chatroom while all of it was being discussed. I brought up bitcoin several times but was scoffed at,as did someone else. As usual people dont learn from the mistakes of the past and are bent on creating a mirror of ICANN. All I can say is WTF?\n\nI even saw one guy mention how he worked on an email system for the NSA ! and no one even asked the obvious question about someone from  the NSA steering the discussions towards a centralised system.\n\nI say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27018#msg27018"},{"f":"ribuck","d":1291557727,"b":[["q","As far as I know the argument against using bitcoin is that if you lost your keys to access the domain you would not be able to recover them.\n\nHow does bitdns get around that?","Quote from: Anonymous on December 05, 2010, 05:12:07 AM"],["t","If you lose the keys, you can no longer sell the domain name or change the IP address of its DNS, but the domain name itself doesn't immediately stop working. So you have plenty of time to choose a new domain name, set it up, and install redirects from your existing site.\n\nYou can protect against this by leaving a copy of your keys with a couple of trusted people. That's a much better solution than leaving your domain name hostage to an untrusted registrar.\n\nIn the 1990s, Turkmenistan was selling .tm domain names and I registered one. After a couple of years, the Turkmenistan government decided there were .tm websites they didn't like and they removed access to the domain name. But there was plenty of time to get a new domain and install redirects. It worked just fine.\n\nUltimately, a name is just a name and it's not the end of the world if one is lost. Even cocacola.com could switch to cocacola2.com and it wouldn't be the end of the world."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27033#msg27033"},{"f":"kiba","d":1291568279,"b":[["q","I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.","Quote from: Anonymous on December 05, 2010, 12:36:58 PM"],["t","Yes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.\n\nWhy it is only 40 BTC at this stage is beyond me."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27053#msg27053"},{"f":"em3rgentOrdr","d":1291572540,"b":[["q","> Quote from: Anonymous on December 05, 2010, 12:36:58 PM\n> I say we prove everyone wrong and do our own thing. Centralisation is a big steaming bag of FAIL.\n\nYes, yes. This is why I offered a bounty. I encourage everyone to pledge some bitcoins if they aren't capable of doing this project.\n\nWhy it is only 40 BTC at this stage is beyond me.","Quote from: kiba on December 05, 2010, 04:57:59 PM"],["t","Where do I pledge?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27072#msg27072"},{"f":"RHorning","d":1291573104,"b":[["q","Where do I pledge?","Quote from: em3rgentOrdr on December 05, 2010, 06:09:00 PM"],["t","http://bitcointalk.org/index.php?topic=2072.0"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27077#msg27077"},{"f":"kiba","d":1291581793,"b":[["t","Best way to get the BitDNS system running off the ground?\n\nAdapt the bitcoin source code?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27114#msg27114"},{"f":"ribuck","d":1291583894,"b":[["q","> Quote from: irc\n> <genjix> dot-p2p: \"We currently believe the best way to create a stable environment for TLDs is to enact a central authority...\n\nKnew it. They sucks.","Quote from: kiba on December 04, 2010, 09:01:48 AM"],["t","They are responding to a problem caused by a central authority by enacting ... another central authority. But I don't think it's because \"they sucks\". I think it's because they haven't been exposed to such a beautiful decentralised design as bitcoin."],["q","Best way to get the BitDNS system running off the ground?\n\nAdapt the bitcoin source code?","Quote from: kiba"],["t","Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27124#msg27124"},{"f":"kiba","d":1291584682,"b":[["q","Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.","Quote from: ribuck on December 05, 2010, 09:18:14 PM"],["t","Ribuck, If only I have the necessary knowledge to adapt it, I would have dropped it and just implement it."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27131#msg27131"},{"f":"RHorning","d":1291587147,"b":[["q","Adapting the bitcoin source code is probably the only practical way for us to get this running. But first I would like to see us produce a brief white paper setting out the design principles, and a non-technical FAQ.","Quote from: ribuck on December 05, 2010, 09:18:14 PM"],["t","What kind of time-frame are we talking about here in terms of getting at least a \"proof of concept\" project going?\n\nIf it took a year, it seems like something else would be taking its place, but if we got some software up and going in the next month or two it seems like the \"distributed DNS\" supporters might really pay attention to BitDNS.  Indeed, with the philosophies of Bitcoin already established, I don't think there is nearly as much \"debugging\" to get this going as it may seem.  Some, yes. But it isn't the end of the world.  Getting something done by tomorrow may be a bit more difficult.\n\nThe time frame of this idea is something that I believe has a short time span to at least get something to the table, even if there might be some competing ideas.  The strengths of using Bitcoins and a Bitcoin-like system are things that solve many of the problems being proposed from what I've seen.\n\nWriting up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27143#msg27143"},{"f":"kiba","d":1291587434,"b":[["t","Speed is of the essence if we're going to show .p2p how to really do distributed DNS."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27146#msg27146"},{"f":"ribuck","d":1291588410,"b":[["q","What kind of time-frame are we talking about here in terms of getting at least a \"proof of concept\" project going?","Quote from: RHorning on December 05, 2010, 10:12:27 PM"],["t","I think this schedule may be possible:\n\n1. Two weeks: Prepare, agree and release three documents: an overview in non-technical language, a FAQ, and a technical but informal white paper which expounds the motivation and the design principles.\n\n2. Three months: Demonstrate a \"proof of concept\" on a test network.\n\n3. Six months: Release a basic but usable version 0.1.\n\n(4. Generate some names while the difficulty is low.\n5. Profit!)"],["q","Writing up a white paper?  It would be nice and if you want to start that I would be willing to contribute to the content, but I would rather be programming right now at least to come up with a rough mock-up of the idea.","Quote from: RHorning on December 05, 2010, 10:12:27 PM"],["t","I will start on the documents. I would rather be programming too, but as kiba says: time is of the essence. This is an idea whose time has come. We can't get this done with just RHorning, kiba and me. We have to build a team. And a set of basic documents serves two important purposes: it attracts newcomers to the team, and it helps to keep the whole team working towards the same goal.\n\nHere are some early tasks that fall on the \"non-documentation\" side, in case you or anyone else is interested.\n\n* Set up the development environment. Are we going to use SourceForge? GitHub?\n* Choose a project name. We've been using \"BitDNS\", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the \".org\" domain.\n* Set up a build process so that we can distribute for Windows, Linux and OS/X.\n* Read, learn and understand the Bitcoin source code and its underlying principles."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27156#msg27156"},{"f":"kiba","d":1291588835,"b":[["q","* Set up the development environment. Are we going to use SourceForge? GitHub?","Quote from: ribuck on December 05, 2010, 10:33:30 PM"],["t","Github and git. I like. It's distributed version control system. Any developer can fork the project and continue on their own implementation and they can request pulls as necessary.\n\nAlso remember, everything is in version control. If you messed up the code, it's not a big deal. Just revert to the last state. Remember to commit as well push often too."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27157#msg27157"},{"f":"chaord","d":1291589038,"b":[["t","I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic \"use value\" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that \"problem.\"  This is exciting!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27158#msg27158"},{"f":"kiba","d":1291589121,"b":[["q","I would like to be looped into this project.","Quote from: chaord on December 05, 2010, 10:43:58 PM"],["t","By all means, pledge some bitcoins if you can't code, or do anything. I can't do any of the real important stuff, but I can show that I am serious."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27159#msg27159"},{"f":"RHorning","d":1291591023,"b":[["q","Here are some early tasks that fall on the \"non-documentation\" side, in case you or anyone else is interested.\n\n* Set up the development environment. Are we going to use SourceForge? GitHub?\n* Choose a project name. We've been using \"BitDNS\", but it's not really an accurate name because we're not reimplementing DNS, just domain name registration. Then register the \".org\" domain.\n* Set up a build process so that we can distribute for Windows, Linux and OS/X.\n* Read, learn and understand the Bitcoin source code and its underlying principles.","Quote from: ribuck on December 05, 2010, 10:33:30 PM"],["t","For the source repository, I am agnostic toward that as long as I can get the source files in and out.  SourceForge has been pretty good to me in the past and it has worked out with other projects I've been involved with, so I sort of lean that way although it appears Kiba love Git.  I'm fine with that too.\n\nAs for a project name, how about DomainCoins?  Otherwise I love more obscure ancient dieties/demigods as names and there are a few out there.  I guess the choice here is one that is more functional or one that can be memorable.  Does anybody know a name of some ancient diety of finance or accounting?  Babylonian and Aztec gods would be especially interesting.  Either that or simply a whimsical name that may not mean anything at all.\n\nFor a build process, I'm not really particular either but I do insist upon \"free\" or \"open source\" tool chains.  I personally am not a big fan of C++ (sort of antagonist about the language) but I'll contribute however anybody else wants to go.  I agree that it should be built on all of those platforms and be capable of going to more.  I have a stronger preference to C# on Mono if that matters any where MonoDevelop is a pretty good environment.\n\nIn term of reading up and understanding the Bitcoin source code.... I'm way ahead of you there.  I've been pounding my head against that for awhile now.  There still is more to pour through, but I'm finally starting to get a good grasp of the base network layer now even if some of the details like the block rejection rules aren't quite so firm yet.  Expanding the documentation would be still beneficial."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27166#msg27166"},{"f":"RHorning","d":1291593295,"b":[["q","I would like to be looped into this project.  I think that something like BitDNS can provide the intrinsic \"use value\" for bitcoin.  I'm a firm believe that bitcoin in its current state is a solution looking for a specific problem.  Perhaps a distributed dns is that \"problem.\"  This is exciting!","Quote from: chaord on December 05, 2010, 10:43:58 PM"],["t","There still are some technical challenges here that I am not completely sure how to solve.  In this regard, all of the help we can get will be appreciated and there will certainly be some \"heavy lifting\" where I think there can be some good division of labor in terms of separate parts that can be worked on.\n\nMajor areas will include:\n\n* GUI design - coming up with the visual appearance and organization for the project.  Most GUI design is simply awful, and it is something I've struggled with over the course of decades and still don't get done very well.\n* Networking communication - How the client will communicate with other nodes?  Even that is something which can be sub-divided after a fashion, but it will be a crucial piece.\n* Database organization and communication - Even choosing a database route isn't going to be easy, either from a \"roll your own\" to something like MySQL or BerkleyDB.  Potentially this is something which could get into the terabyte range for storage requirements, so we do need to be careful on some of the decisions we make here.\n* DNS communication - ideally what should happen is that the client would become a source of domain information that could be referenced with other DNS records.  For a home office/small business this could be on the same computer but for some businesses or schools they could even put this in their server room as a part of the main domain resolver path for their network.\n* Interfacing with the Bitcoin network - How will the usage of this software connect to the Bitcoin network, transfer payments from \"registrants\" to \"registrars\" (aka \"miners\"), and what is a \"fair\" way to make sure that the people receiving money are going to be paid?\n* Thin client design - How can you set up something that would retrieve the \"database\" yet not be a miner?  Is this even an issue?\n\nNon technical issues include:\n\n* Establishing Problem Domain - just what is it that this software needs to accomplish?  Who would use it and why?  What is it that they need?\n* Potential Social Conflicts - What sort of \"legal\" requirements might there be for \"domain registrations\" and what do we do about them?  Do we care?  Even if we ignore the law in this case, what would most network users expect from a domain registration?\n* Marketing - How do we sell this software so far as to get people to use it?  How can publicity be spread about it once it becomes available.  What sort of outlets are there which might be interested in using this.  If we told a business they could run a domain server and make money (by \"mining\" registration applications) simply by having it in their server room, would that be something they might adopt?\n* Finding \"customers\" for domain registration - This is more to the marketing, but with a concentration on just those who might want to use domain registration.  Some of this is also going to be an issue in terms of breadth of the adoption of the concept, but what groups might be interested in using this as registration?  Obviously bitcoin users would be an early adopter, but anybody else?\n\nSome of these have some \"milestones\" that must be met before other things can happen, but at the same time there are things which can be done simultaneously.  Any other ideas for things that might be facing this in terms of a breakdown of tasks?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27177#msg27177"},{"f":"kiba","d":1291593639,"b":[["q","* Potential Social Conflicts - What sort of \"legal\" requirements might there be for \"domain registrations\" and what do we do about them?  Do we care?","Quote from: RHorning on December 05, 2010, 11:54:55 PM"],["t","When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27179#msg27179"},{"f":"ribuck","d":1291635943,"b":[["q","When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.","Quote from: kiba on December 06, 2010, 12:00:39 AM"],["t","Kiba is wise."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27312#msg27312"},{"f":"Anonymous","d":1291636417,"b":[["t","I suggest tahoe lafs if you are looking for a database for storage."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27315#msg27315"},{"f":"kiba","d":1291641153,"b":[["q","I suggest tahoe lafs if you are looking for a database for storage.","Quote from: Anonymous on December 06, 2010, 11:53:37 AM"],["t","Remember, speed is of the essence. We can alway replace the database with something else, but not time.\n\nAll non-essential features should be blocked from implementation focus.\n\nThat mean the core developers don't work on a fancy GUI. They will focus on:\n\n1. The mechanism to mine, register, and change a domain name.\n\n2. The mechanism to distribute or output the DNS database."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27343#msg27343"},{"f":"RHorning","d":1291652258,"b":[["q","> Quote from: Anonymous on December 06, 2010, 11:53:37 AM\n> I suggest tahoe lafs if you are looking for a database for storage.\n\nRemember, speed is of the essence. We can alway replace the database with something else, but not time.\n\nAll non-essential features should be blocked from implementation focus.\n\nThat mean the core developers don't work on a fancy GUI. They will focus on:\n\n1. The mechanism to mine, register, and change a domain name.\n\n2. The mechanism to distribute or output the DNS database.","Quote from: kiba on December 06, 2010, 01:12:33 PM"],["t","GUI design is important, but it is also something that non-techies can help with even if all you do is make a mock-up in something like MS-Paint or GIMP.  Getting the buttons to work is a bit harder, but not really so much.  The tough part about GUI design is that it is an art skill, something that techies often lack.  There is much more about artistic balance, the golden mean, and selecting colors or icons that aren't offensive to certain cultures (yellow buttons are a bad idea in Chinese culture, for instance, or showing a swastika to a bunch of germans).\n\nI agree that there are priorities in terms of getting the network layer put together first, but if we can get more people involved I don't think it should be dead last in priority either and certainly can be worked on concurrently with other projects."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27381#msg27381"},{"f":"kiba","d":1291652714,"b":[["t","Yes, the core developers should be focused on the network and the protocol.\n\nI am making it my project to write a BitDNS client. I don't need the bitcoins. I just want to help so that the core developers can focus on the important stuff."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27382#msg27382"},{"f":"ribuck","d":1291655041,"b":[["q","I am making it my project to write a BitDNS client.","Quote from: kiba on December 06, 2010, 04:25:14 PM"],["t","Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27396#msg27396"},{"f":"kiba","d":1291655948,"b":[["q","Before we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?","Quote from: ribuck on December 06, 2010, 05:04:01 PM"],["t","It's easy for me to change the name of the git project, whatever you decide. Still BitDNS is catchy."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27403#msg27403"},{"f":"RHorning","d":1291657235,"b":[["q","> Quote from: kiba on December 06, 2010, 04:25:14 PM\n> I am making it my project to write a BitDNS client.\n\nBefore we go too far down the track, can we agree on a project name? I'm uneasy about BitDNS, because we aren't writing a Domain Name Server. How about BitDomains, or DomainChain?","Quote from: ribuck on December 06, 2010, 05:04:01 PM"],["t","In a way, we are writing a Domain Name Server.  The hope here is that eventually the data we throw into this database is going to be extracted and used with the current DNS architecture as used on the internet, where computers would have the DNS resolution pointing to this database as a \"fall back\" position if it can't be resolved through the regular DNS channels.  That is how OpenDNS is currently working right now.\n\nThe only differences here is that we aren't relying upon a central server to act as a gatekeeper of this information, and it would be something that you could simply put into the search path through the network configurations of your own.\n\nGetting the DNS protocol hooks working is to me a much more trivial thing than getting the domain registration itself going, however.  Once you can demonstrate that the domain registration is working and that the domain name can be resolved cleanly, getting the DNS portion working is simply plugging through the RFC protocol documents to make sure you get that side working.  The revolutionary thing isn't the DNS server software (which can already be downloaded for free as in beer and speech) but rather the decentralized database keeping track of this stuff and securing the data from getting tampered with."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27412#msg27412"},{"f":"ribuck","d":1291658022,"b":[["q","The revolutionary thing is ... the decentralized database keeping track of this stuff and securing the data from getting tampered with.","Quote from: RHorning on December 06, 2010, 05:40:35 PM"],["t","Exactly. The domain name block chain.\n\nAnyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27417#msg27417"},{"f":"kiba","d":1291663022,"b":[["q","Exactly. The domain name block chain.\n\nAnyway, I have registered domainchain.org, in case people like it. I think DomainChain better-explains what's going on than BitDNS. But I won't object if people prefer another name.","Quote from: ribuck on December 06, 2010, 05:53:42 PM"],["t","What software are you using for the site?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27439#msg27439"},{"f":"chaord","d":1291663720,"b":[["t","+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27442#msg27442"},{"f":"kiba","d":1291663853,"b":[["q","+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )","Quote from: chaord on December 06, 2010, 07:28:40 PM"],["t","Bleg. All I need to do is change the name.\n\nIn any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27443#msg27443"},{"f":"RHorning","d":1291665755,"b":[["q","+1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )","Quote from: chaord on December 06, 2010, 07:28:40 PM"],["t","Ooooooo...  I like BitRegister.  DomainChain works out pretty good too and is very descriptive.  I'm so used to BitDNS that I am still somewhat partial to that, but it doesn't exactly explain in a single word what this is going to be other than a shortened form of \"Bitcoin DNS\".\n\nI'd like to get back to the topic of the scope of the domain naming system itself.  I would like to propose the following specification for actual name of the domain itself:\n\nA domain can include combination of unicode (UTF8) characters with the exception of the period character (U+002E).  We may want to look at some other restricted characters mainly for conformance with normal URL schema as defined in RFCs and avoiding control codes, but I say that right off the start we permit non-latin characters into this scheme.  Other \"excluded\" characters may include the \"/\" character (U+002F) or the other non-alphabetic characters common found in the original ASCII specification.  The period character here is something more special, however.\n\nSome possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\", or any of the standard country codes as currently under the purview of ICANN.  If ICANN wants to get into this game and claim those few domains, I don't mind giving these domains directly to ICANN, but the issue here is mainly to avoid naming collisions with other network resources.  If/when that becomes an issue, a technical solution can be found and it is irrelevant.\n\n\"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name.  For example a certain oil company could create a domain called \"bp\" and then create a sub-domain like \"usa.bp\".  When a registration of this nature happens, some sort of signed public/private hash key confirming permission to create the sub-domain is confirmed (similar to transferring ownership of a domain) before the sub-domain record is kept.  It may be possible to create a domain that is simply a \"free-for-all\" of sub-domains and defined as such when the domain is created.  An example of this would be a domain named, \"bitcoin\" and \"btc\" which would permit the creation of a domain like \"mtgox.btc\" or \"mtgox.bitcoin\".  On the other hand somebody creating \"this.sucks.coca-cola\" may have to negotiate with the domain holder of \"coca-cola\" in order to create those sub-domains.\n\nSince the sub-domains have their own record, they can also point to separate resources including separate IP addresses.\n\nEssentially, this is also allowing anybody and everybody to create their own top-level domain and charge whatever they want to use that \"top level\" domain, but it also makes such TLDs essentially worthless for the most part too.\n\nI'll be nice and give \"p2p\" to perhaps the \"dot p2p\" folks as well if they want it.  I'm sure somebody would be willing to donate 0.01 BTC to get that record into the database.\n\nAre there any flaws with this idea, or should it \"go official\"?  "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27451#msg27451"},{"f":"kiba","d":1291666496,"b":[["t","I have no complaint."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27455#msg27455"},{"f":"ribuck","d":1291666562,"b":[["q","I would like to propose the following specification for actual name of the domain itself...","Quote from: RHorning on December 06, 2010, 08:02:35 PM"],["t","OK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system (\"punycode\") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense."],["q","Some possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\"","Quote"],["t","Hmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?"],["q","\"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name","Quote"],["t","If you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27456#msg27456"},{"f":"bencoder","d":1291667407,"b":[["t","I like DomainChain as well.\n\nI would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.\n\nDo we have a wiki yet?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27461#msg27461"},{"f":"kiba","d":1291667625,"b":[["q","I like DomainChain as well.\n\nI would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.\n\nDo we have a wiki yet?","Quote from: bencoder on December 06, 2010, 08:30:07 PM"],["t","Where the incentive for generators to get paid?\n\nOn the other hand, it won't be limited right? It will be a unique name of some kind."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27464#msg27464"},{"f":"RHorning","d":1291668141,"b":[["q","> Quote from: chaord on December 06, 2010, 07:28:40 PM\n> +1 on DomainChain or BitRegister over BitDNS (no offense kiba Wink )\n\nBleg. All I need to do is change the name.\n\nIn any case, do ribuck and RHorning have any inkling on what you guys agree on and how to implement the protocol? The faster some things that are agreed on, the more code we can do.","Quote from: kiba on December 06, 2010, 07:30:53 PM"],["t","The only thing I am banging my head against right now is the issue of how to get the block miners of the DNS blocks to get the transaction fees.  I don't know if that is going to require a change in the Bitcoin protocol or if it can be adapted into the existing protocol.  This idea <http://bitcointalk.org/index.php?topic=2077.0> shows some promise as one way to implement the idea, however I really don't like putting this data into the main Bitcoin transaction database and turning that into one huge monster generic database of home cooking recipes, porn, mp3s, Wikileaks documents, Heroin traffic routing instructions, and other miscellaneous junk.  If you thought Bitcoins faced problems before in terms of governments wanting to shut it down because it is a competing currency, I think that puts it completely over the top without any of the protections that Freenet has put into the message routing protocol.\n\nWhere I'm having the problem is mainly that I don't think a \"DomainChain\" miner should get paid until the block they made is accepted deep into the chain, like at least 10 or so blocks deep (perhaps adjustable on that length with some formula too?)  For the most part I don't think most miners are going to care as long as they eventually get paid for the work they did, but those who are attacking the network may want to suck up the bitcoins for themselves and not really doing any work in terms of generating the blocks necessary to keep this whole thing going.\n\nBy banging my head on this problem, I really mean that every possible option I've considered has a fatal flaw in it.  I think the registration fees are an important part of this whole concept, however, as it makes the difference between a public commons free good and something where the consumer \"pays the freight\" for the network.  I also think it will make the difference between limited vs. widespread acceptance of this system too.\n\nIf you want me to go over some of the ideas I've had, I'll gladly put those dead ends into another thread, as I've come up with at least a dozen different ways to solve this problem in detail... including ideas I even started to type up in various replies to posts on this forum and then simply hit the \"x\" on the tab in Firefox before I hit the post button because I realized it wouldn't work.  Even the method of putting the data into the Bitcion transactions has a fatal flaw so far as it turns the BTC miners into DNS miners too (they keep the fees for themselves) and it enables some different kind of attacks on the DNS network as well.  I hate to say it though, it may very well be the best route to take shy of some protocol extension to Bitcoin itself that would recognize independent data chains as a source of transactions."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27472#msg27472"},{"f":"RHorning","d":1291669560,"b":[["q","> Quote from: RHorning on December 06, 2010, 08:02:35 PM\n> I would like to propose the following specification for actual name of the domain itself...\n\nOK, but not so fast! Is there an existing standard we can be compatible with? It will save us some time, and probably also save us from making some mistakes. I know the existing domain names use a weird encoding system (\"punycode\") for historic reasons, and I'm not suggesting to replicate that. But working with an existing list of valid unicode characters would make sense.","Quote from: ribuck on December 06, 2010, 08:16:02 PM"],["t","The existing standard is that ICANN is being very stingy on allocating top level domains.  That, for myself, is a major mistake and if you read some of the links above written by Karl Auerbach he points out that this is completely artificial and arbitrary.  There is no current reason to exclude any alphanumeric sequence for a domain name of any kind."],["q","> Quote\n> Some possible domain names would be \"excluded\" from this schema and held in common such as excluding domains named \"com\", \"net\", \"edu\"\nHmm, can this work? I had assumed that the DomainChain names would all take some standard suffix so that they can integrate smoothly with the existing domain names. Just like .p2p is being used for the non-decentralized project. Otherwise, what if someone registers (say) foobar and next year InterNIC adds foobar as an official top-level domain?","Quote"],["t","So, who cares if there is a collision?  If somebody registers that domain, somebody at InterNIC can try to find out who owns the domain with DomainChain and negotiate a price to transfer that domain to themselves.  BTW, I think some sort of \"comment\" field could be put in with domain registration so you can attempt to contact the domain owner (completely optional BTW!) if they might be interested in \"selling\" the domain.  That seems like InterNICs problem, not ours.\n\nThey are the competitors to this protocol and this is something they should have done from the beginning.  That they aren't doing these things is more why this is something that should be done in this fashion.  There is no reason a million or a billion TLDs can't exist."],["q","> Quote\n> \"Sub-domains\" can also be established using a \"dot\" structure off of a previously established domain name\nIf you have registered a domain name, you automatically get the ability to create whatever subdomains you want. Subdomains are just records in your domain name server, under your control. The registrar doesn't need to know about them.","Quote"],["t","Yes, I realize that the current DNS structure allows you to use a \"dot\" off of the previously established domain.  The only reason for sub-domains is to create a system where \"ownership\" of a sub-domain can be transferred and have that ownership be kept track of through the DomainChain rather than as something arbitrary which can be revoked by the domain owner.  In other words, once \"mtgox.btc\" is registered as a sub-domain, it in effect becomes a full-fledged domain in its own right with the protections and controls that would go with a proper domain and would be recognized with a separate domain server for any of its sub-domains.  Basically this is a way to create the notion of a \"TLD\" registration system too if you wanted to stick with the convention of <server> <dot> <TLD>.  In practice I think such notions would eventually be dispensed with entirely, but perhaps there might be a reason to keep it going.  This system also meshes in a bit better with the current DNS system where collisions would be avoided as a natural part of the protocol rather than a hard arbitrary exclusion of certain words and names... thus simplifying the overall protocol.  Those TLDs currently operated by InterNIC and ICANN can be held in \"escrow\" by a member of the development community until such time as ICANN decides to pay up or take ownership of those \"domains\".\n\nNote here that you can go to a domain server operator and \"pay\" them some money to create a subdomain off of say \"mmorpg.org\" for a game you made called \"coolgame.mmorpg.org\", but you are still at the mercy of the domain name server in the same way that everybody is at the mercy of ICANN and InterNIC (as well as the other domain registrars) for simply getting into the game.  That sub-domain can be arbitrarily terminated for any reason at all and would force you to go through the judicial system to get the subdomain put back in.  I think that is something the network philosophy is trying to avoid in the first place.  This alternate method would imply that such sub-domains can't be arbitrarily shut off unless the sub-domain owner is willing to relinquish control."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27479#msg27479"},{"f":"chaord","d":1291669834,"b":[["t","I don't know how to do this on IRC, but can someone create a #bitcoin-domainchain chatroom or something so that we can get some real time discussion going?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27481#msg27481"},{"f":"Hal","d":1291670287,"b":[["t","Here is an idea for how miners can get paid.\n\nLet us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.\n\nHowever in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.\n\nBitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.\n\nAnd the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27484#msg27484"},{"f":"em3rgentOrdr","d":1291671581,"b":[["q","Here is an idea for how miners can get paid.\n\nLet us start with a fork of Bitcoin. We will start a new block chain just like Bitcoin did two years ago. There will be coins in this chain, which I will call bitdnscoins. People can pay bitdnscoins to each other via transactions in the BitDNS block chain, just like with Bitcoin. Block miners get 50 bitdnscoins.\n\nHowever in addition to bitdnscoin transactions there would also be domain name transactions. Here is the main idea: at any time a bitdnscoin can be converted into a new domain name registration via a special transaction. This uses up the bitdnscoin and it can't be used again. There would also be 'maintenance' domain name transactions where an existing domain name is transferred to a new owner or has other data fields changed.\n\nBitdnscoins represent the right to register a new domain name. They are valuable for this reason. You would acquire them by mining, or more commonly by buying them, with Bitcoins, dollars, etc. To register a new name you need a bitdnscoin.\n\nAnd the incentive for miners to include transactions? Same as for Bitcoin: transaction fees. Registering a new domain name costs 1 bitdnscoin. But you can pay more, and the excess goes to the miner. Pay 1.2 bitdnscoins for your new domain name, and 0.2 of that goes to any miner who includes your transaction. That's the incentive.","Quote from: Hal on December 06, 2010, 09:18:07 PM"],["t","That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27491#msg27491"},{"f":"RHorning","d":1291672113,"b":[["q","I like DomainChain as well.\n\nI would also argue against any particularly special attachment to bitcoins, what would the purpose of that be except to hopefully promote bitcoin? I prefer to allow it to be a separate market in it's own right. With people able to pay for domains from those who've managed to generate them using whatever payment method they want to agree on.\n\nDo we have a wiki yet?","Quote from: bencoder on December 06, 2010, 08:30:07 PM"],["t","Well, I've proposed that Bitcoins be used as an incentive for mining the chains, which I suppose is a way to promote the use of Bitcoins as well.  If you are talking about the \"miners\" simply creating their own floating currency that could then in turn be put into one of the exchanges.... that may solve the problem of getting miners paid (hmmm.... I've got to think about that one for a little bit) but it does create the problem of what anybody is going to do with that \"floating currency\"?\n\nJust thinking aloud here... if we used a \"floating currency\" in this system instead that was a \"DomainChain coin\" similar to Bitcions but not pegged to Bitcions as all, could that work here?  I'm sure Mt. Gox would certainly be interested in exchanging these coins if they had some value, and the point here is mainly to come up with the formula for creating these coins.  The only real use of these coins would be to pay registration fees for domain names, so I think the drop-off could happen a lot faster than is the case with Bitcoins.  \n\nIn theory we could even set up some sort of link to Mt. Gox or some other trader so that in the interface you could do a \"quick buy\" of these \"DomainChain coins\" in such a way that for an end-user they would be buying them with BTC and then putting those recently purchased coins right into the transaction as a fee for the miner to claim when it gets put into the chain.  If the transaction block is rejected, that miner loses the claim to those coins and they become unconfirmed.... where it is the responsibility for the exchange to worry about the validity of a particular set of \"DomainChain coins\".  A similar kind of \"quick exchange\" could even happen with LR Dollars or any other currency that may be tied to some exchange system, or they could simply get the \"coins\" on a \"manual\" basis from the exchange if they wanted to get a better exchange rate or have somebody \"send\" them some of these \"DomainChain coins\" with a direct hand-over of cash.\n\nI like this a whole lot.  It may \"solve\" this problem I've been thinking of in terms of getting miners paid.  Are there any other hiccups anybody sees with this situation?  The exchange itself isn't even fixed.\n\nThe only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value.  Not overnight, but gradually.  We need somebody with a whole lot more economic theory behind them to figure this one out, because I would vote for a \"weaker\" currency than Bitcions be set up in this situation, however we want to define that.  How would you set up the parameters for a relatively strong currency that the desire would be to trade it in for Bitcions instead when possible?  Would the fact that Bitcions has an absolute limit but these kind of \"DomainChain coins\" would continue to inflate (aka the 50 DCC produced per block would continue to be produced indefinitely creating a mild sort of inflation over time) be sufficient to make Bitcoins stronger?\n\nI need to think overnight on this particular subject as it is starting to make my head ache thinking about it, but it sounds like an interesting idea to seriously consider."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27494#msg27494"},{"f":"Hal","d":1291672393,"b":[["t","I also had an idea last night of how/where to tie this into the existing DNS.\n\nWhen you lookup foo.com, software on your computer called a resolver is responsible. It has some caching and local data, but mostly it just asks a DNS server for the answer. You have one or more DNS servers configured as part of your network setup, and these servers respond to domain name lookup queries either directly, or by initiating their own search of the domain name system.\n\nObviously we want existing name lookups still to work. Broadly speaking, then, we would change the software to first check if a name is registered in the BitDNS system, and if not, to fall back to the regular handling.\n\nMy idea is that the best place to add the BitDNS lookup code is in a DNS server rather than in the resolver. Resolvers are different for every OS, so there's more work. I don't even know if the resolver logic can be changed on Windows. Plus this code is going to need to be tracking the BitDNS block chain, and not every end user should have to do this.\n\nOther 'alternative' DNS systems do it like this, with one or more special DNS servers that know about their extra domains.\n\nWe would choose some open source DNS server as a base, fork it and add the code to lookup BitDNS names. Whether these names all have a distinguishing TLD \".bit\" or whether we are more aggressive and take over more namespace, either way it could be done.\n\nAs I understand it, when a DNS server looks up foo.com, it finds the (or a) name server authoritative for .com, and asks it for what is called a SOA record for foo.com. This tells what name servers are authoritative for foo.com, and the DNS server then tries them to get details on foo.com.\n\nWe would intercept this first step, and use the BitDNS code to find the authoritative name servers. Maybe we could create a dummy SOA record to hold the data, to simplify falling back into the regular DNS code.\n\nPeople who want to use BitDNS would just have to select one of the BitDNS aware DNS servers. Paranoids could run their own name servers locally and track the block chain. All the usual optimizations of DNS in terms of caching, distribution, etc. would work, so it would not have much negative impact on the net."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27496#msg27496"},{"f":"RHorning","d":1291672479,"b":[["q","That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.","Quote from: em3rgentOrdr on December 06, 2010, 09:39:41 PM"],["t","I'm fine with that.  It is an easy way to allocate the coins.  The role of the halving of the coins \"mined\" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi.  I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet)."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27497#msg27497"},{"f":"em3rgentOrdr","d":1291672647,"b":[["q","> Quote from: em3rgentOrdr on December 06, 2010, 09:39:41 PM\n> That sounds nice.  However, I was always uncomfortable with how block miners get 50 coins, and slowly halves.  It confuses people and makes them uneasy.  I would just say have a constant 1 block => 1 bitdnscoin.\n\nI'm fine with that.  It is an easy way to allocate the coins.  The role of the halving of the coins \"mined\" every 2-4 years was mainly to strengthen the currency from an economic perspective, and something which many of those involved with the development of Bitcoin feel is necessary including Satoshi.  I don't think it is nearly as critical in this situation, and as Bitcoin itself has proven there are people who will find value in the currency even if it doesn't half (as it hasn't yet).","Quote from: RHorning on December 06, 2010, 09:54:39 PM"],["t","Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27501#msg27501"},{"f":"ribuck","d":1291673325,"b":[["q","The reason for halving bitcoins over time does not really exist for bitdnscoins.","Quote from: em3rgentOrdr on December 06, 2010, 09:57:27 PM"],["t","Good. Something everyone completely agrees on!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27505#msg27505"},{"f":"RHorning","d":1291673382,"b":[["q","Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.","Quote from: em3rgentOrdr on December 06, 2010, 09:57:27 PM"],["t","Wondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of \"change\" but is there going to be any need for more than about three or four decimal places?\n\nThis is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million \"bitcoins\" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other \"currency\" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.\n\nI don't know of any other currency that uses this sort of allocation system even remotely.  Of course that is why this is so groundbreaking."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27506#msg27506"},{"f":"kiba","d":1291673532,"b":[["q","Good. Something everyone completely agrees on!","Quote from: ribuck on December 06, 2010, 10:08:45 PM"],["t","So the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27509#msg27509"},{"f":"RHorning","d":1291673870,"b":[["q","I also had an idea last night of how/where to tie this into the existing DNS.","Quote from: Hal on December 06, 2010, 09:53:13 PM"],["t","I know this discussion is going like nuts here.  I think this is a very good idea and should be fleshed out much more.  If you have some experience or knowledge about local domain name servers, your expertise here would be invaluable.  I know just enough to get myself into trouble on that matter and to debate the policy questions, not enough to really dig into the guts of them.  I've operated a domain server for a brief period of time and have experimented with OpenNIC myself."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27511#msg27511"},{"f":"bencoder","d":1291673898,"b":[["q","Anyway, I have registered domainchain.org, in case people like it.","Quote from: ribuck on December 06, 2010, 05:53:42 PM"],["t","Care to stick a wiki up on there?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27512#msg27512"},{"f":"RHorning","d":1291673987,"b":[["q","> Quote from: ribuck on December 06, 2010, 10:08:45 PM\n> Good. Something everyone completely agrees on!\n\nSo the formula for creating problems and adjusting difficulty will be the same?(Forgive my ignorance)","Quote from: kiba on December 06, 2010, 10:12:12 PM"],["t","I don't see any reason why we should try something different.  If it breaks for us or for Bitcoins, one or both projects should get the issue fixed with an alternative solution.  There certainly are strong reasons to keep this system, as Satoshi's white paper points out in pretty good detail too."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27514#msg27514"},{"f":"Anonymous","d":1291677746,"b":[["q","The only real problem I see is that it sets up a situation where this kind of currency could supplant the main Bitcoin for intrinsic value.  Not overnight, but gradually.","Quote"],["t","Well people couldnt say domaincoins werent backed by anything.   Cheesy\n\nI like the idea of a constant block rate."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27538#msg27538"},{"f":"Hal","d":1291681778,"b":[["t","On the question of how many domain names to create per day:\n\nhttp://www.domaintools.com/internet-statistics/\n\nThere are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.\n\nIf we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27545#msg27545"},{"f":"kiba","d":1291682397,"b":[["q","If we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.","Quote from: Hal on December 07, 2010, 12:29:38 AM"],["t","100 domains per block is 25 years.\n\n150 domains per block is 18.5 years.\n\n200 domains per block is 12.5 years.\n\nPersonally, I don't feel like I am a rush to do a lot of domain registration fast. 15 years is good enough for me. We don't need to register tons of domain within a few short years, since not everybody will be willing to switch from central to decentralized.\n\nAlso, the population of humanity ain't likely to grow forever... So we can expect that growth at some taper off at some point in the future.\n\nHowever, this generation rate have the potential to spark a long debate..so we need a method that let us decide quickly somehow."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27546#msg27546"},{"f":"RHorning","d":1291684285,"b":[["q","On the question of how many domain names to create per day:\n\nhttp://www.domaintools.com/internet-statistics/\n\nThere are about 100 million active domain names, and 400 million expired ones. About 300,000 changes occur per day, divided equally between creation, expiration, and transfers.\n\nIf we create only 50 domains per block, 6 blocks per hour, that is 7200 domain names per day. At that rate it would take like 50 years to create 100 million domains. So it seems necessary to make names faster.","Quote from: Hal on December 07, 2010, 12:29:38 AM"],["t","The question as to how many domains to include in a block ought to be something dependent upon the miner alone.  This certainly is a useful point to bring up and likely an early \"reference implementation\" limit will be 50 domains per block merely to increase scarcity.  Still, that up to 300k changes might happen eventually with this system, perhaps more considering that the cost is likely going to be considerably less than the current domain registration system.\n\n----\n\nI have a few other thoughts about this now that we are getting to something a little more concrete in terms of the software architecture.  Would it be reasonable to expect the cost of a domain registration to be 1 DCC (Domain Coin Currency)... at least as the \"default\" cost expected by the miner to \"register\" a domain?  I think that would establish at least an initial value to the currency and help to self-regulate those who want to jump in early and grab up a whole bunch of domains early on.  I might even go so far as to say 2 DCC for registration and 1 DCC for information changes.  If you run your own miner, you can \"tweak\" this if you want to be more competitive, but this is the way that you can spend the currency and what it is based upon and a fair benchmark.\n\nIn terms of a social effect that may be negative (depending on your viewpoint) some of the country code TLDs represent a substantial source of income for some of countries involved.  One in particular, the country of Tuvalu, has only a little over 12,000 citizens and is the smallest member-nation of the United Nations in terms of population and pretty close to that in terms of land area.  Only the Vatican has a smaller population in terms of a sovereign state.  Its current TLD (*.tv) is currently run by a company in California but a significant portion of the revenue from that domain goes to the country's government under contract.\n\nOn the topic of small countries and their \"country codes\", it seems like if we could get this software rather stable, we might even want to offer this \"service\" to some of these smaller countries for their domain registrations, where I'm pretty sure that this would be cheaper than whatever contract they currently have with their current service provider.  That goes under \"marketing\", but something else to think about.  I certainly think that it would be awesome if we could get a whole country like Tonga to switch to Bitcoins as their national currency, and is much more likely to happen than the major western countries like America or the EU.  Just dreaming there."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27554#msg27554"},{"f":"chaord","d":1291685342,"b":[["t","I would like to ask for some clarification on exactly what we are proposing here.  From reading this (lengthy) thread, I gather that we are proposing:\n\n• A decentralized domain registrar that maps a friendly human readable name (ie: chaord.btc) to an ip address\n\n• A parallel network bitcoin which will have it's own token currency (represent addresses).  Rather than mining bitcoins, you mine top-level address rights.  Is this correct?\n\nAm I understanding all this correctly? If so, it seems as if in this brave new digital world, bitcoins (BTC) represent a commodity like gold, and domaincoins (DCC) represent real estate.\n\nLastly, I'm sure this has been discussed, but is there any way that the two system can be combined?  Can the domaincoin system accomplish all things bitcoins can, in addition to domain registration, or no?  IMO the best of both worlds would be if, somehow (not sure how), the domain coin system could use bitcoins as its underlying backing (or vice versa).\n\nHonestly, I feel that something like DomainCoins is the \"missing link\" that this community is searching for.  Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27561#msg27561"},{"f":"RHorning","d":1291689095,"b":[["q","Honestly, I feel that something like DomainCoins is the \"missing link\" that this community is searching for.  Because the data behind DomainCoins actually represents something (an IP address mapping), I think this could be the use-value that something like bitcoin needs to propel it to success!","Quote from: chaord on December 07, 2010, 01:29:02 AM"],["t","I think you got the ideas down.  The role that the \"DomainCoins\" (DCC) are playing here is to give a financial incentive to \"miners\" who are creating a cryptographically secure domain registration database.  It is also a work-around due to the fact that we can't seem to figure out a way to accomplish the goals of getting Bitcoins directly to the miners, so instead we are going to be using an alternative currency which can be traded for mining.  To me, the only reason for putting any sort of coin generation into the blocks is simply to \"prime the pump\" to get some DCC put into circulation.  Hopefully what will normally happen is that DCC will be exchanged for Bitcoins in both directions:  Some folks will \"buy\" some DCC with Bitcoins (or LR Dollars or whatever) so they can pay for domain registrations and the miners will \"redeem\" the DCC for Bitcoins as earnings.\n\nTrade between DCC and BTC will be almost insanely easy by design and the exchange mechanisms may even be put right into the GUI interface.  I could even see custom clients that might even combine transactions for both \"currencies\".\n\nThis same system could be used in a number of other similar situations, such as an idea I floated about creating a Bitcoin-based Stock Exchange <http://bitcointalk.org/index.php?topic=2001.0>.  If such a stock exchange is set up, a similar parallel currency may have to be implemented to also pay for mining the transaction blocks.  I can see many other kinds of \"databases\" set up which would require some sort of cryptographic time-stamping.  Something I played with a while back that could be useful here would be \"timestamping\" police evidence (especially digital evidence such as a dashboard camera video feed from a police vehicle) in a chain of custody system.  An engineering company could set up a custom \"bitcoin\" system to keep track of engineering documents to be used as a defense against a patent lawsuit to both show date of creation and prove that the document file hasn't been tampered with since its inclusion into the database.  Seriously, this system is something that has a whole bunch of possibilities that I can't even start to describe the kinds of things that would be useful and we are just scratching the surface."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27579#msg27579"},{"f":"kiba","d":1291689823,"b":[["t","Wait, I am a bit confused. Alternative currency for DomainChain?\n\nOh, these represent addresses?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27580#msg27580"},{"f":"Hal","d":1291690898,"b":[["t","Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27584#msg27584"},{"f":"kiba","d":1291691991,"b":[["q","Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.","Quote from: Hal on December 07, 2010, 03:01:38 AM"],["t","Doesn't seem hard to me. It's a normal trade to me."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27590#msg27590"},{"f":"Anonymous","d":1291692070,"b":[["q","Wait, I am a bit confused. Alternative currency for DomainChain?\n\nOh, these represent addresses?","Quote from: kiba on December 07, 2010, 02:43:43 AM"],["t","A coin would represent a domain. I think that is the proposal.\n\nCould ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines. Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.\n\nDoes .dnc = domain name coins?\n\nWe could co-opt the democratic national convention lmao."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27591#msg27591"},{"f":"Anonymous","d":1291692141,"b":[["q","> Quote from: Hal on December 07, 2010, 03:01:38 AM\n> Actually I am concerned that transactions between BTC and DCC may not be simple. Because both currencies tend to be anonymous, it is hard to make the two transfers in a coordinated way. If Anne wants to sell Beth 1 DCC (allowing 1 domain to be created) for a certain number of Bitcoins, then Beth must send Anne the Bitcoins via the Bitcoin block chain, while Anne sends Beth the DCC on the DomainChain. If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.\n\nDoesn't seem hard to me. It's a normal trade to me.","Quote from: kiba on December 07, 2010, 03:19:51 AM"],["t","So you need two clients running?\n\nedit:never mind..."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27592#msg27592"},{"f":"RHorning","d":1291693925,"b":[["q"," If the two are anonymous to each other, it seems there must be a trusted third party like a reputable exchange. It seems hard to do peer to peer.","Quote from: Hal on December 07, 2010, 03:01:38 AM"],["t","Doing peer to peer currency exchanges is beyond the scope of this project.  If there is going to be some sort of peer to peer currency exchange (I think it might be possible, especially for non-reversible currencies like Bitcoins and Liberty Reserve Dollars), it should be in a completely different project.  All that I'm suggesting is that some sort of API be set up so one or more \"trusted exchanges\" can be selected to facilitate the \"purchase\" or exchange of these \"coins\" for some other currency.  I just don't see too many people going through the hassle of trying to obtain these \"domain coins\" by selling other services in these coins, even though that would in theory be possible.\n\nIf we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.\n\nOn the positive side, the fancy API and GUI exchange methods won't be strictly needed at all at least initially.  We could even use essentially the existing bitcoin software where all we would do is to simply \"tweak\" the low level features so we would be including the domain information into the blocks.  If we did that as a quick bootstrap of the network, websites like Mt. Gox could use the same JSON API system for Bitcoin on this system as well, particularly as the exchanges wouldn't have to play with the domain information but rather just the coin trading mechanisms.  Exchanges would want to get into the act as there certainly are arbitrage opportunities between the DCC and BTC currencies.\n\nOur hard part is to define the \"rules\" of what domain information needs to be present, and when a block can be rejected because of mal-formed domain data.  That is where I think it would be wrong to put this more directly into the Bitcoin block chain, as rejecting Bitcoin blocks because of a malformed domain record seems to be harmful to Bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27598#msg27598"},{"f":"RHorning","d":1291694351,"b":[["q","> Quote from: kiba on December 07, 2010, 02:43:43 AM\n> Wait, I am a bit confused. Alternative currency for DomainChain?\n>\n> Oh, these represent addresses?\n\nA coin would represent a domain. I think that is the proposal.","Quote from: Anonymous on December 07, 2010, 03:21:10 AM"],["t","A coin would represent the work or effort to administer the database.  That is the \"reward\" a miner gets for processing the domain records.  That it might cost 1 DCC to enter a record into the database is just the \"fee\" to play the game, where you are buying the effort from previous record keeping efforts."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27602#msg27602"},{"f":"Anonymous","d":1291695185,"b":[["q","> Quote from: Anonymous on December 07, 2010, 03:21:10 AM\n> > Quote from: kiba on December 07, 2010, 02:43:43 AM\n> > Wait, I am a bit confused. Alternative currency for DomainChain?\n> >\n> > Oh, these represent addresses?\n>\n> A coin would represent a domain. I think that is the proposal.\n\nA coin would represent the work or effort to administer the database.  That is the \"reward\" a miner gets for processing the domain records.  That it might cost 1 DCC to enter a record into the database is just the \"fee\" to play the game, where you are buying the effort from previous record keeping efforts.","Quote from: RHorning on December 07, 2010, 03:59:11 AM"],["t","Thanks for clearing that up.\n\nAnything is better than buying another domain from godaddy . Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27619#msg27619"},{"f":"kiba","d":1291696224,"b":[["t","At any rate, do we have enough information that's agreed so that the core hackers can develop right now?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27629#msg27629"},{"f":"em3rgentOrdr","d":1291697085,"b":[["q","Could ip addresses themselves be managed by this system?  The ipchain would prevent anyone having duplicate addresses. This removes central control of ip address allocation and the ability to track individual machines.","Quote from: Anonymous on December 07, 2010, 03:21:10 AM"],["t","Having ip address themselves be managed by a bitcoin-like system is a very interesting idea...\n\nI never liked how the government and major corporations get to dish out vast swaths of the ip spectrum by dictate and privilege..."],["q","Ipv6 has a privacy issue doesn't it?   They stuffed ipv4 because address allocation became a scarce resource by bad management.","Quote from: Anonymous on December 07, 2010, 03:21:10 AM"],["t","Is this privacy issue because ipv6 address will embed your MAC address <http://www.internetwk.com/columns/frezz100499.htm>?"],["q","IPv6, on the other hand, has 128 bits of address space, enough to provide a billion-billion addresses for each square meter of the earth's surface. How one could ever route that many addresses is an interesting question, but at least IPv6 will never run out.\n\nAs you might expect, the address field is so huge that the IETF didn't know how to assign it. So, in a move to get buy-in from established industry standards bodies, the right-most 64 bits were designated to contain EUI-64 format information. This is used by the IEEE to assign Ethernet addresses, which are normally not transmitted outside a user's LAN.\n\nIncluded in EUI-64 are two interesting pieces of information: the registered manufacturer of your NIC card and your 48-bit Ethernet address. Surprise! Every packet you send out onto the public Internet using IPv6 has your fingerprints on it. And unlike your IP address under IPv4, which you can change, this address is embedded in your hardware. Permanently.","Quote"],["q","Does .dnc = domain name coins?\n\nWe could co-opt the democratic national convention lmao.","Quote from: Anonymous on December 07, 2010, 03:21:10 AM"],["t","LOLFEST!   Cheesy"],["q","> Quote from: em3rgentOrdr on December 06, 2010, 09:57:27 PM\n> Exactly.  My points exactly.  The reason for halving bitcoins over time does not really exist for bitdnscoins.\n\nWondering aloud even more, what need do we have for a fractional bitdnscoin?  I could imagine having a little bit of \"change\" but is there going to be any need for more than about three or four decimal places?","Quote from: RHorning on December 06, 2010, 10:09:42 PM"],["t","I agree...there is not as much reason for fractional bitdnscoins. That just complicates the algorithm and operation.  Making bitdnscoin be simple unitary entities is much simpler and easy to understand, so it will increase the likelihood of widespread adoption.  Simpler is better.  Computer hardware and software like things simple."],["q","This is essentially the same issue just thought through from another perspective.  Right now I think it is about 100 million \"bitcoins\" to the smallest unit as defined in the Bitcoin protocol.   We really don't need that many decimal places even for trade purposes.  I still like the uint64 structure used in the Bitcoin protocol, but with a mild sort of inflation happening to the currency (relative to Bitcions) I don't see any major deflationary pressure pushing the value down like I see for Bitcoins.  Again, I am not an economist and this is going to take some hard economic theory and guessing which way even this currency might go in that perspective.  The only other \"currency\" to make a real comparison about here is the coins on the test network, and the main thing there is that those coins aren't being traded... which makes even that a bad example.","Quote from: RHorning on December 06, 2010, 10:09:42 PM"],["t","Could you clarify?  Are you talking about because bitcoins have a limited number of digits that it can be divided into (according to the algorithm), that therefore 1 bitcoin could be instead thought of a ~million mini nano-bitcoins that are of fundamental unit of trading size?"],["q","Anything is better than buying another domain from godaddy . Smiley","Quote from: Anonymous on December 07, 2010, 04:13:05 AM"],["t","Awesome!  NO need for the middle man!  rent\n\nThis brings up another interesting point: most people will not need to have to pay the yearly ~$10 rent to their domain name provider, if they generate the bitdnscoin themselves.  Of course, this does not abolish rent on domain names, as there will be of course some mega bitdnscoin miners will speculate to purchase domain names they think will be in high demand, and will then rent out the popular domains they own."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27640#msg27640"},{"f":"Hal","d":1291697483,"b":[["q","Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?","Quote from: FreeMoney on December 07, 2010, 04:06:59 AM"],["t","This was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.\n\nIs it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27642#msg27642"},{"f":"em3rgentOrdr","d":1291697811,"b":[["q","At any rate, do we have enough information that's agreed so that the core hackers can develop right now?","Quote from: kiba on December 07, 2010, 04:30:24 AM"],["t","Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27645#msg27645"},{"f":"Anonymous","d":1291698221,"b":[["q","> Quote from: kiba on December 07, 2010, 04:30:24 AM\n> At any rate, do we have enough information that's agreed so that the core hackers can develop right now?\n\nWell before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  And, keep in mind, people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.","Quote from: em3rgentOrdr on December 07, 2010, 04:56:51 AM"],["t","+1 on that."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27649#msg27649"},{"f":"Anonymous","d":1291698386,"b":[["t","http://www.politico.com/news/stories/1210/46003.html\n\nFor motivation  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27652#msg27652"},{"f":"kiba","d":1291698523,"b":[["q","http://www.politico.com/news/stories/1210/46003.html\n\nFor motivation  Smiley","Quote from: Anonymous on December 07, 2010, 05:06:26 AM"],["t","I RAGE. "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27653#msg27653"},{"f":"em3rgentOrdr","d":1291700139,"b":[["q","> Quote from: Anonymous on December 07, 2010, 05:06:26 AM\n> http://www.politico.com/news/stories/1210/46003.html\n>\n> For motivation  Smiley\n\nI RAGE.","Quote from: kiba on December 07, 2010, 05:08:43 AM"],["t","Oh god.  I try not to read the news...it just makes me angry."],["q","White House intellectual property czar Victoria Espinel said Monday that the Internet community should “expect more” pre-emptive action as the administration combats online copyright infringement — especially the illegal copying and sale of pharmaceutical drugs.","Quote"],["t","So now we will all have to pay rent for an artificial government-imposed monopoly on life-saving pharmaceutical drugs, just so that we can live longer.  Intellectual Property => have to pay rent for your body.  IP == slavery.  Just because someone is the first to file a patent on a lifesaving drug, doesn't give him the right to exclude others from reverse engineering or independently discovering and producing that lifesaving drug."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27662#msg27662"},{"f":"Anonymous","d":1291700820,"b":[["t","Those are the stakes on the table people."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27665#msg27665"},{"f":"kiba","d":1291701733,"b":[["t","Remember, we can't let those .p2p dudes beat us to the punch!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27671#msg27671"},{"f":"Hal","d":1291702414,"b":[["q","Well before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.","Quote from: em3rgentOrdr on December 07, 2010, 04:56:51 AM"],["t","I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?\n\nThe reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27673#msg27673"},{"f":"kiba","d":1291702750,"b":[["q","I'm not sure how it would work to only create one coin per block. Would this only buy the creation of one domain name?\n\nThe reason I like the idea of fractional coins is it would give more flexibility in transaction fees. If it costs one coin to register a domain, it might make sense that a good size for the transaction fee would be fractional.","Quote from: Hal on December 07, 2010, 06:13:34 AM"],["t","Umm, each coin stand for one domain.\n\nHowever, I don't think we need transaction fee. This is not bitcoin after all.\n\nThe incentive for 50 coins each block they generate ARE the transaction fee. Maybe?\n\nI am worried about people who spam change to the DNS database?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27675#msg27675"},{"f":"RHorning","d":1291704367,"b":[["q","> Quote from: FreeMoney on December 07, 2010, 04:06:59 AM\n> Whats the general plan here? No reduction in names/block I assume? Won't this make the first blocks incredible valuable and later blocks less valuable as the goodness of remaining names declines? Maybe it should start really low (1?) and move up gradually to a stable amount (100?)?\n\nThis was on another thread but is relevant here. It is true, the first domain name is likely much more valuable than the millionth. So even if we don't reduce the number of DCC per block, the value will decrease much like Bitcoin does by halving the block reward every two years. That means transaction fees might have to rise substantially over time.\n\nIs it worth considering to increase the block creation rate above 6 per hour? If we generate blocks every 5 minutes or even every 2-3 minutes instead of every 10, that would be another way to speed up domain name availability.","Quote from: Hal on December 07, 2010, 04:51:23 AM"],["t","One of the reasons to maintain the 10 minute interval between blocks is because of network latency from distant node in terms of \"hops\" between nodes.  If you shorten the interval you risk more \"collisions\" between nodes that may have simultaneously created a \"successful block\".  In turn that also can make even longer \"chains\" start to compete against each other.\n\nIn other words keeping the 10 minute interval may be a very good idea or even increasing the interval could have benefits.  I know of at least some blocks even with this average that have time stamps which even go \"negative\" where the successive block is timestamped a few seconds before the previous block.  More likely it was created at almost the same time but the other block literally was created a matter of a few seconds earlier.\n\nI would like to put in perhaps a more continuous or shorter interval between difficulty adjustments, but then again there are some network attacks which are thwarted by the two-week readjustment system."],["q","> Quote from: kiba on December 07, 2010, 04:30:24 AM\n> At any rate, do we have enough information that's agreed so that the core hackers can develop right now?\n\nWell before starting coding, let's make sure we have the protocol clearly written out.  For instance, are we going to take my suggestion of using unitary, non-fractional, bitdnscoins where 1 block == 1 bitdnscoin, instead of having the number of bitdnscoins per block start at 50 and half every few years?  Also, there is no need for fractional bitdnscoins since it doesn't make too much sense to own one-tenth of a domain name.  Keep in mind that people can use fiat money or even bitcoins when trading unitary bitdnscoins, incase they need to make a trade of two domain names with unequal subjective valuations.","Quote from: em3rgentOrdr on December 07, 2010, 04:56:51 AM"],["t","The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself.  The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations.  It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too.  Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.  Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27677#msg27677"},{"f":"kiba","d":1291705011,"b":[["q","The exchanges might really appreciate at least some fractional quantities to play with, although that could also be internal to the exchange itself.  The real advantage is for some granularity in terms of competing miners which might want to snag a few additional registrations.  It would also help in terms of setting up a per-kilobyte charge for people throwing stuff into the coin transactions too.  Attacks on the network can also happen through filling up coin transaction information with useless junk, and charging a fee for that can help stop or at least slow down such a flood attack and at least put cost to such an attack that must be borne by the person making the transaction.  Such a charge may require at least some fractional coins, even if it isn't nanocoins necessarily.","Quote from: RHorning on December 07, 2010, 06:46:07 AM"],["t","Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27679#msg27679"},{"f":"chaord","d":1291705200,"b":[["q","If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.","Quote from: RHorning on December 07, 2010, 03:52:05 AM"],["t","I'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27680#msg27680"},{"f":"RHorning","d":1291705338,"b":[["q","Umm, each coin stand for one domain.\n\nHowever, I don't think we need transaction fee. This is not bitcoin after all.\n\nThe incentive for 50 coins each block they generate ARE the transaction fee. Maybe?\n\nI am worried about people who spam change to the DNS database?","Quote from: kiba on December 07, 2010, 06:19:10 AM"],["t","Coin transfer transaction fees are also important here as well.  It allows the cost to be scaled with the size of the network and note that there will be coin transactions in this network as well.  There will be coin transfers independent of domain registrations as there will at least be transfers to and from exchanges and likely from miners to people wanting to make registrations directly.  There may also be other applications that use these coins that haven't been developed yet.\n\nThe \"50 coins\" they may collect are not going to be generated coins but rather fees collected from processing domain records, presuming they are getting 50 domain registrations in a single block.\n\nThe only role that generated coins play is strictly to bootstrap the exchanges.  You have to get the coins from somewhere, and giving them to miners is as good of a way as I can imagine without simply creating them all in the genesis block and then handing them out like the Bitcoin faucet until that feature runs out of coins."],["q","Let me this straight: so we use fractional coins to prevent network spamming? Or is it bitcoin?","Quote from: kiba on December 07, 2010, 06:56:51 AM"],["t","This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27681#msg27681"},{"f":"kiba","d":1291706768,"b":[["q","This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.","Quote from: RHorning on December 07, 2010, 07:02:18 AM"],["t","So if you spent a coin to register a domain, then it stay frozen until the domain expire?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27684#msg27684"},{"f":"RHorning","d":1291706924,"b":[["q","> Quote from: RHorning on December 07, 2010, 03:52:05 AM\n> If we could dump this idea of another currency, I'd be all for it.  I just don't see how to do that though.\n\nI'm going to put my thinking cap on here, because I think ideally if we could do this under one umbrella (either by expanding bitcoin to encompass domainchain or vice versa) it will strengthen both projects.","Quote from: chaord on December 07, 2010, 07:00:00 AM"],["t","It could be put into the Bitcoin protocol itself, but keep in mind that would require changing the miners in a way that would also have to set up the rules for accepting and rejecting the domain registrations.  It also makes this a hack onto Bitcoins to be performing tasks that aren't financial transactions.  Some Bitcoin miners wouldn't be willing to participate and may end up rejecting blocks with the domain information buried in the block.  This gets back to burying the data into the transaction record itself, and then you get problems again trying to decide what blocks get rejected and which ones don't.  On top of all that, it makes this a one-time only change and is not extensible to incorporating other ideas that may be similar.\n\nReally, the only way this is going to work is for a completely separate block chain for the domain data.  That implies a second currency.\n\nIf we could get some hooks into Bitcoin that would open up some additional data types which could be put into the Merkle tree for the blocks and have some way for a miner to bootstrap verification rules for those additional types, perhaps we could put it into the main Bitcoin chain as well.  We would also have to come up with some sort of scripting language that would be used to \"verify\" those extra datablocks sort of like the current scripting language being used to verify coin transactions.  Would that be worth some extra effort to make a \"generic solution\" that could be added to Bitcoin for this and other similar kinds of data types to be added to Bitcoin?\n\nIt would require a major network-wide upgrade regardless.  Coins wouldn't be lost, but older clients would have to be abandoned with an update of that nature.  Miners would receive any transaction fees for simply following those rules.\n\nAnother question here, and this is perhaps the most important:  Would Satoshi be interested in putting in these kind of extra hooks into Bitcoin?  By creating a separate currency that is essentially a fork of Bitcoin for a specific purpose, Satoshi's blessing is irrelevant other than coordinating the effort of the two projects to relay problems identified in the two efforts and to make sure fatal problems get updated in bother projects.  If we decide to put the data (even as a separate data structure) into Bitcoin, Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue."],["q","> Quote from: RHorning on December 07, 2010, 07:02:18 AM\n> This is another currency that is essentially identical to Bitcoin, but with a few tweaks and miners more concentrated on working with domain records.  We could put this into the main Bitcoin protocol, but then we would have to change the Bitcoin miners as well.\n\nSo if you spent a coin to register a domain, then it stay frozen until the domain expire?","Quote from: kiba on December 07, 2010, 07:26:08 AM"],["t","No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27686#msg27686"},{"f":"kiba","d":1291707055,"b":[["q","No, that coin is received by the miner processing the transactions and handled just like coin transaction fees are right now in Bitcoin.","Quote from: RHorning on December 07, 2010, 07:28:44 AM"],["t","So domain name generation are limited by the velocity of miners spending, but then they have to generate a block to get the coin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27687#msg27687"},{"f":"chaord","d":1291707793,"b":[["t","RHorning...thank you for the very detailed responses.  It's been helpful that you are so willing to lay down your logic so that some of us can play \"catch up\" as we wrap our heads around this project."],["q","Satoshi needs to be in the middle of all of this discussion.  Bitcoin, as it currently exists, really doesn't deal with this kind of issue.","Quote"],["t","I completely agree here.  Even though his \"blessing\" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27691#msg27691"},{"f":"RHorning","d":1291709062,"b":[["q","I completely agree here.  Even though his \"blessing\" is not necessary, it could potentially save a lot of time and effort if we can at least get Satoshi involved in the discussion.  Does anyone here have enough of a working relationship with Satoshi? I know he is quite evasive these days.","Quote from: chaord on December 07, 2010, 07:43:13 AM"],["t","We need to get Satoshi's approval if something goes into the main Bitcoin client.  There are other applications involved here besides the DNS system, even if that seems to have high priority at the moment.  We could create a patch that would put hooks into the Bitcoin software to permit these kind of changes, but it could also be for naught if Satoshi rejects that patch.  Since this is also a major architectural change to the software, it seems highly unlikely that it would get accepted unless we can demonstrate a clear need for this idea or show some huge benefits that would help Bitcoin be adopted as a currency.  It is also a whole bunch of software development that depends on just one person accepting that change on essentially a whim.\n\nIn short, if we decide to put this into Bitcoin, Satoshi is the gatekeeper.  We could completely fork Bitcoin, which is essentially what we are proposing here anyway as the alternative with these separate coins.  That is our choice."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27696#msg27696"},{"f":"kiba","d":1291709218,"b":[["t","We need a wiki real bad so Rhorning can write down what he means.\n\nRRRRRRRRRRRRRibuck?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27698#msg27698"},{"f":"Anonymous","d":1291717167,"b":[["t","Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?\n\nAfter all who wants to download a massive block chain just to buy or transfer a domain name?\n\nIs it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?\n\nIt seems this could be a way for bitcoin to have its own \"app\" store of different block chain purposes.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27714#msg27714"},{"f":"RHorning","d":1291731214,"b":[["q","Would introducing extra overhead into the existing chain make this cumbersome and maybe introduce vulnerabilities into the financial system?\n\nAfter all who wants to download a massive block chain just to buy or transfer a domain name?\n\nIs it enough that a parallel domain chain is certified as the way to get a bitdomain? Do we want developers concentrating on other applications rather than the core purpose of bitcoin?\n\nIt seems this could be a way for bitcoin to have its own \"app\" store of different block chain purposes.  Smiley","Quote from: Anonymous on December 07, 2010, 10:19:27 AM"],["t","An interesting thread related to this can be found here: http://bitcointalk.org/index.php?topic=2124.0\n\nTheymos has been discussing how to put miscellaneous data into the transaction blocks themselves, but there are dangers to doing that.  It also shows some incredibly strong resistance to \"tweaking\" Bitcion itself as a software package to permitting this kind of activity, which seems to me as coming from at least a source that would end up killing any attempt to put a patch into Bitcoin to permit data inclusion for something other than the \"stealth\" method with transactions.\n\nWhile the suggestion that Git itself ought to be sufficient for cryptographic timestamping and cryptographic data storage (that is interesting by itself... something I haven't thought about), I don't know enough about Git to say much about it at all in terms of its distributed nature.\n\nI firmly believe you should \"pay your own freight\" so far as anything which costs others to do, which is why I think this proposal is incredibly useful.  There are costs associated with domain name registration and data storage, and they aren't trivial expenses either.  The concept of Bitcions enables those costs to be borne by those who use the service.  I tried to explore this idea further on this thread:  http://bitcointalk.org/index.php?topic=1764.0\n\nThis is indeed a political idea here too, which is where perhaps it is getting some resistance as well.  The idea could be summed up with the concept that \"you get what you pay for\".  Places like Source Forge offer their \"services\" for free, but there are hidden costs including being tied to other outside interests.... mainly the advertisers and those who are paying for the \"service\".  With what we are proposing for BitDNS/Domain Chain is that the service is going to be focused upon those who are paying for the service.... which is those who are making the registrations.  They have the most to lose if this project falls apart.  If the registrants aren't happy with the service, fees are going to go down and the DCC is going to collapse as a currency.  That in turn is going to cause developers to be very strongly focused upon meeting the needs of that community.\n\nThe other aspect which is really interesting here is that the process of becoming a \"registrar\" has a very low barrier to entry.  I'm sure many people would love to have had the chance to do something like being BigDaddy or Verisign in terms of processing domain registrations and receiving the fees for doing that.  Now the chance to perform that sort of \"business\" at least on a part time basis is at least possible.  No single person or even central organization is going to be receiving the fees but rather a \"community\" that is open to newcomers and even people with modest technical skills.\n\nI've also seen complaints that \"open source software\" doesn't pay.  Bitcoin can change that model, including doing things like we are talking about here with the DomainCoin system.  Not only can a bounty system be set up for integrating a specific feature into the system, but the developer can also have a continuing source of income afterward.  BTW, in deference to Kiba, the license itself is immaterial here too and can simply be thrown into the public domain, even though I think that copyleft licenses tend to offer much stronger protections against idiots who would attempt to mess with you in the legal system.  You may want to avoid the judicial system, but sometimes it comes and bites you hard even if you are active in trying to stay out of its reach.  Time is really the one resource that anybody has to sell when you finally get down to the gritty details of economics, and it takes time to be a developer to create projects like this.  Also, even simply maintaining the software afterward takes time and effort, fixing bugs that show up and perhaps putting in tweaks.\n\nAnyway, enough of the issue with the overhead costs.  I am afraid that this is going to effectively split or fork the Bitcoin network, and that isn't a good thing either.  I want to work with the Bitcoin community, but if they won't have us, we may have to move on.  Threats to Bitcoin will still be relevant and I'm not going to leave completely in a huff, but as a separate application it will be essentially a fork of Bitcoin if we proceed with the path I've suggested in terms of a completely separate coin chain and currency.  It might be interesting so far as a social experiment is concerned to see which way is better and which \"coin\" is going to be more accepted in the long run.  I am challenging some of Satoshi's assumptions here too, but not overly so.  Two very similar project with slightly different goals but which also support each other might be beneficial to each other as well, especially as there is going to be a huge amount of common ground to work with."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27746#msg27746"},{"f":"ribuck","d":1291734626,"b":[["q","> Quote from: ribuck on December 06, 2010, 05:53:42 PM\n> Anyway, I have registered domainchain.org, in case people like it.\n\nCare to stick a wiki up on there?","Quote from: bencoder on December 06, 2010, 10:18:18 PM"],["t","Yes I'll do this. Don't panic!\n\nBut first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27758#msg27758"},{"f":"kiba","d":1291735385,"b":[["q","Yes I'll do this. Don't panic!\n\nBut first, I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.","Quote from: ribuck on December 07, 2010, 03:10:26 PM"],["t","We won't make fun of you.\n\nOn my Bitcoiner honor!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27762#msg27762"},{"f":"kiba","d":1291736074,"b":[["q"," Trying to predict the exact numbers required is equal to central economic planning, and pointless.","Quote from: theymos on December 07, 2010, 02:48:01 PM"],["t"," <--- In another thread.\n\nSo there's an economic calculation problem. We...cannot reliably predict how many domain name registration are needed each block.\n\nSo we going to need to price generation of blocks, somehow?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27766#msg27766"},{"f":"RHorning","d":1291737627,"b":[["q","I've thought of a design for DomainChain that is simple, elegant, powerful, and very easily integrated with Bitcoin. I just need to think it through a bit more before I post it here so that I don't make a complete fool of myself.","Quote from: ribuck on December 07, 2010, 03:10:26 PM"],["t","I'm always interested in alternatives.  Take your time though, and I'd like to see how it is different than what we've proposed here."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27771#msg27771"},{"f":"ribuck","d":1291740680,"b":[["t","OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.\n\nHere's a quick summary:\n\n• Bitcoin already allows for a text \"payload\" to be included with a transaction. Any bitcoin transaction that is sent with the right payload becomes a domain name registration.\n\n• To register a domain name, just send any amount of bitcoin to yourself, with a special payload. This payload identifies itself as a DomainChain payload, and contains the desired domain name plus the IP address of the authoritative name server(s). If no-one else already has that name registered, it's yours.\n\n• To transfer a domain name to someone else, just send them the associated bitcoin (actually any part of the associated transaction will do). The GUI will let you do this in terms of \"domain names\" rather than in terms of \"coins\".\n\n• To change the authoritative name server(s), just send the associated bitcoin to yourself with a payload that identifies the new authoritative name server(s)\n\n• Registrations last forever unless you terminate them by sending that bitcoin to yourself with a payload that is a DomainChain \"cancel\" message\n\n• You can register a domain name with the smallest convenient amount of bitcoins (currently 0.01 BTC), so the system imposes no scarcity of domain names. However, miners will impose transaction fees which increase as the block size increases. This provides a disincentive to registration spammers\n\n• To resolve (lookup) a domain name, the block chain is scanned for the most recent valid transaction for that domain name. In principle, anyone can run a DomainChain resolver, but in practice most users will use a DNS service that is DomainChain-aware\n\nAdvantages:\n\n• Provides domain name registration with the same level of pseudonymity as Bitcoin\n\n• Holds registration data in a tamper-resistant distributed manner\n\n• Strengthens Bitcoin by providing additional economic incentive for generators (because they will be able to charge transaction fees for domain name transactions)\n\n• Can be implemented much more quickly than any other scheme that has been proposed so far\n\n• Existing bitcoin clients are unaffected. If they receive coins that are associated with a domain name registration they will see them as coins. do not display domain name registration transactions. No modification is needed.\n\nDisadvantages:\n\n(I'm sure you'll let me know of the disadvantages.)\n\nImplementation:\n\n1. Patch the standard bitcoin client. Run it on the bitcoin test network. The patched client will have a separate panel for domain names that are associated with bitcoins. These bitcoins will not show on the standard panel, nor will they be included in the total balance available to spend. On the DomainChain panel, instead of a \"send coin\" button there will be buttons for \"register a new name\", \"change nameservers\", \"transfer a name\" and \"abandon a name\". There will also be a scrolling list of domain names together with their nameservers.\n\n2. Write a program that scans the block chain to determine the authoritative domain name servers for a given domain name. Patch a standard open source domain name server to consult the output of this program as part of its name resolution.\n\n3. If it works well, persuade Satoshi to allow these transactions in the main network. Of course, it would be technically possible to run it on a new network with a new block chain, but who wants competing currencies?\n\nThere's obviously a lot to be fleshed out, but I think the design is workable and easy to implement."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27787#msg27787"},{"f":"ribuck","d":1291741170,"b":[["t","The DomainChains payloads could look like this:\n\nRegistration (with and without nameservers):"],["c","DomainChains my-domain.tld\nDomainChains my-domain.tld 201.73.213.92 98.252.10.34"],["t","Changes of registration details use the same payloads, but the payloads must be sent with a coin that is already associated with the domain name.\n\nTo drop a registration and turn the bitcoin back into a spendable coin, send this payload with a coin associated with the domain name:"],["c","DomainChains drop"],["t","Obviously this is just to illustrate the idea. The concrete syntax may differ."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27788#msg27788"},{"f":"kiba","d":1291741368,"b":[["t","Ribuck: I believed that is a brilliant hack. We finally have intrinsic value for bitcoin!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27790#msg27790"},{"f":"RHorning","d":1291748984,"b":[["q","OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.","Quote from: ribuck on December 07, 2010, 04:51:20 PM"],["t","The #1 disadvantage:  My complaint about shoving useless and meaningless data into the transaction block.  It would work, but there may be changes to Bitcoin to get rid of this \"feature\" as it may be seen as an attack rather than something useful for the project.  I am not alone with this attitude.  It also opens a pandora's box of problems down the line as domain information is hardly going to be the only thing to put into transaction chains in this fashion.  Expect more resistance if you actually get a client to accomplish this task.  Bitcion is not bittorrent. \n\nTransactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a \"payload\" being used in this fashion.\n\nAnother huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the \"payload\" any sort of in here, but there is no reason for anything or anybody to recognize this data.  Instead you would likely need some other application which is reading all of the transaction and either \"accepting\" or \"rejecting\" the domain registrations.  Such acceptance or rejection would be completely arbitrary and there would not be any sort of clear \"ownership\" of any sort of domain, or any sort of consensus as to which domain record takes precedence in the actual domain usage system (aka the DNS end of this registration system).  Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.\n\nI admit that some of this could be worked out simply by saying that the first \"registration\" takes precedence, including in the same block.  Other systems could be set up (likely as an external app) scanning transactions and pulling out domain records that would \"apply\" the rules which identify a valid transaction.  Competing software could put in different \"rules\" for the same data as well and put different domains as valid.\n\nIt was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:\n\nGeneration Block -- > Alice  -- > Bob -- > Charlie\n\nSince all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:\n\nGeneration Block --> Charlie\n\nAnd all of the previous transactions are ignored and \"forgotten\".  If your registration record is in one of those other transaction blocks, it is then lost.\n\nThis could work.  It would be real nice to see what Satoshi thinks of an \"abuse\" of the transaction scripts in this fashion.  My own preference is to permit additional kinds of blocks as a separate payload that is linked into Bitcoins, where some clients may only read them to verify the block hash and then dump the data and other clients could keep the data for their own purpose.\n\nBTW, one advantage to going this route is that it would not require any reboot of the network\n\nI do have my reservations about the direction this is going, but I'm willing to have an open mind about it."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27831#msg27831"},{"f":"theymos","d":1291749814,"b":[["q","OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.","Quote from: ribuck on December 07, 2010, 04:51:20 PM"],["t","Nanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.\n\nhttp://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal\n\nSome sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:\n- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.\n- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system."],["q","If they receive coins that are associated with a domain name registration they will see them as coins.","Quote"],["t","You can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27834#msg27834"},{"f":"ribuck","d":1291750756,"b":[["t","RHorning,\n\nThe one objection of yours that I can't address is the one about \"shoving useless data into the transaction block\". This is something for others to decide, and at this time I would respect whatever Satoshi said. But we should not be concerned about \"opening the pandora's box\" because the box is already open and lots of people are going to look inside in the future. That \"problem\" (if it is a problem) is for the owners of Pandora's Block Chain to decide.\n\nWhat I suggest we do is to try out DomainChain on the test network, and see what bitcoiners think of it when it's able to be experimented with. I'm sure we'll get feedback on whether or not it's welcome in the live block chain."],["q","Transactions really ought to be about bitcion transfers from one person to another, and the purpose of the script is to permit flexibility in terms of the method used to secure that transfer.  It may be possible that the nature of the scripting language itself may be changed to specifically exclude a \"payload\" being used in this fashion.","Quote from: RHorning on December 07, 2010, 07:09:44 PM"],["t","There's nothing forcing generators to include bitcoin payments that piggyback DomainChain data, but why wouldn't generators want to include them if the transaction fee is high enough to cover the extra costs plus a profit margin?"],["q","Another huge disadvantage is that this really isn't any sort of system for registering domains in a secure fashion.  You might put into the \"payload\" any sort of in here, but there is no reason for anything or anybody to recognize this data.","Quote"],["t","That's true, but it's no different from Bitcoin itself. The block chain only has value because a majority of users are prepared to interpret it in a certain way, according to certain rules. If that works well enough for coins, it will work well enough for domain names.\n\nAlthough we need generators to include the DomainChain transaction data, we don't need the average person's bitcoin client to recognise that data, or act on it in any way. Only the resolver software, and the modified clients used by those who want to register domain names, need to recognize the extra data."],["q","Two people trying to register the same domain simultaneously would have no real means to identify who actually has the domain with this system.","Quote"],["t","The first to get their registration into the block chain gets the domain. Ideally the generator who processes these transactions will reject the invalid one. Failing that, the resolver will certainly locate the valid one."],["q","It was also pointed out that transaction records can be dropped.  For instance when you send a coin like this:\n\nGeneration Block -- > Alice  -- > Bob -- > Charlie\n\nSince all that is necessary is to simply keep track of where the coin is currently at, all you have left is this:\n\nGeneration Block --> Charlie\n\nAnd all of the previous transactions are ignored and \"forgotten\".  If your registration record is in one of those other transaction blocks, it is then lost.","Quote"],["t","I don't think there is any problem here. The registration data is re-sent if the domain name is transferred to someone else by spending the coin. All we care about is who has the current registration. We don't care about the history of the domain name."],["q","This could work.","Quote"],["t","Let's do the \"simplest thing that could possibly work\" for the proof of concept. This seems to be it. If people like it, they will accept DomainChain into the Bitcoin block chain. If they don't like it, we go to plan B."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27838#msg27838"},{"f":"ribuck","d":1291750964,"b":[["t","I haven't read your spec yet, but..."],["q","...Some sort of expiration is required..","Quote from: theymos on December 07, 2010, 07:23:34 PM"],["t","That's fine. It's not problematic in my design."],["q","Normal clients will ignore such transactions.","Quote"],["t","That's also not problematic. If someone wants to work with domain names, they will use a domain-enabled client."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27839#msg27839"},{"f":"ribuck","d":1291751456,"b":[["t","Wow, after a first readthrough of the spec by Theymos and Nanotube I am astonished by the similarities. And their spec is so much further developed. This is excellent!\n\nI will look through it in detail tomorrow as I've already spent way too much time on this today."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27841#msg27841"},{"f":"Hal","d":1291752362,"b":[["t","My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27847#msg27847"},{"f":"kiba","d":1291753438,"b":[["q","My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.","Quote from: Hal on December 07, 2010, 08:06:02 PM"],["t","Speculation is natural; even healthy. "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27851#msg27851"},{"f":"ribuck","d":1291755748,"b":[["q","My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com.","Quote from: Hal on December 07, 2010, 08:06:02 PM"],["t","What do you suggest is a better way to decide who gets sex.domain?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27864#msg27864"},{"f":"kiba","d":1291755841,"b":[["t","Do we have a consensus on nanotube's proposal? Any objection?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27866#msg27866"},{"f":"nanotube","d":1291757132,"b":[["q","Do we have a consensus on nanotube's proposal? Any objection?","Quote from: kiba on December 07, 2010, 09:04:01 PM"],["t","just to be clear, it's nanotube's+theymos's proposal Smiley\n\nand, we're still working out some kinks in the protocol. consider this to be an open RFC period. it's a bit too early for 'consensus'. "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27872#msg27872"},{"f":"em3rgentOrdr","d":1291757243,"b":[["q","> Quote from: ribuck on December 07, 2010, 04:51:20 PM\n> OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.\n\nNanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.\n\nhttp://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal\n\nSome sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:\n- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.\n- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.\n\n> Quote\n> If they receive coins that are associated with a domain name registration they will see them as coins.\n\nYou can't receive non-standard transactions if you don't know the format (even if it just has some OP_DROP data). Normal clients will ignore such transactions.","Quote from: theymos on December 07, 2010, 07:23:34 PM"],["t","I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.  I like the idea of piggybacking bitDNS on top of bitcoin.  However, putting the domain name registration requests inside of bitcoin transactions as a message does cause concern about compatibility, should the bitcoin developers decide to remove that feature in the future for security or other reasons.  I would suggest, maybe is it possible to have the domain name registration request message be not included directly inside the bitcoin transaction, and instead use some cryptogrphic properties of the block be used to index to a bitcoin registration request message?  For example, somehow have the hash of the transaction/block be directly indexable to a DNS registration request?  In which case, the information about the sender and receiver of the DNS registration request would be embedded in the hash such that it proves that address X is the owner of that DNS registration request?  Thus the bandwidth/traffic of domain name table info/requests would only be paid by those clients who are engaged in domain name registration."],["q","Some sort of expiration is required, preferably a short one (the 52,000 blocks used currently in this spec is probably too big). Having a short expiration requires everyone to rebroadcast their messages, which solves two problems at once:\n- With an expiration of x, you can build a complete DNS database by downloading only the most recent x blocks. Having an unlimited expiration would require you to download the entire block chain, which will eventually become several terabytes in size.\n- Spent transactions more than y blocks deep can be completely forgotten from the network. The value of y is currently unknown, but I expect it to be between 5,000 and 52,000. Messages need to be rebroadcast at least this frequently to stay alive if you want to use the convenient one-coin-per-domain system.","Quote from: theymos on December 07, 2010, 07:23:34 PM"],["t","Expiration fixes the \"problem\" of domain names being lost for eternity.  My question is, what are the relative benifits/disadvantages of using a block count based expiration (e.g. 52,000 blocks) versus a time-based expiration (e.g. 1 year)?  I would think a time-based expiration would make more sense for average people to understand, since they will know that after a certain fixed period of time, they will need to renew their domain, and can set that in their calendar, instead of being completely unaware if the block count reaches some number?  Never mind...I get it...52,000 blocks is approximately the number of blocks that should be produced in 1-year time assuming a rate of 1 block/10 minutes is maintained."],["q","> Quote from: Hal on December 07, 2010, 08:06:02 PM\n> My concern is that there would be a rush to grab hot domains. I would expect that the first blocks generated with this system will all be maximum size and filled with the equivalent of sex.com. These domain names are worth millions of dollars, if the system succeeds. I suppose transaction fees would be enormous, otherwise miners will just fill blocks with their own registrations. Ordinary transactions would be crowded out, if this were part of Bitcoin.\n\nSpeculation is natural; even healthy.","Quote from: kiba on December 07, 2010, 08:23:58 PM"],["t","What Kiba said.  Speculation is a part of any world where there are limited resources.  Speculation allows the market to come to a subjective valuation of the unknown value of such resources.  The speculator takes a risk by buying domains (even if it is just an opportunity cost), and that risk is entirely held by the speculator."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27873#msg27873"},{"f":"kiba","d":1291758478,"b":[["q","I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.","Quote from: em3rgentOrdr on December 07, 2010, 09:27:23 PM"],["t","Simultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27879#msg27879"},{"f":"em3rgentOrdr","d":1291759689,"b":[["q","> Quote from: em3rgentOrdr on December 07, 2010, 09:27:23 PM\n> I read your draft bitcoin DNS spec Nanotube and theymous...very interesting.  And it's fascinating that ribuck also came up with a very similar design independently.\n\nSimultaneous inventions are not surprising. This phenomenon had been happening throughout the history of science and invention.","Quote from: kiba on December 07, 2010, 09:47:58 PM"],["t","Oh yes, I am perfectly aware.  In fact, the prevalence of simultaneous inventions is a strong argument against the necessity of a patent system to \"reward\" inventors with monopoly."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27887#msg27887"},{"f":"RHorning","d":1291765036,"b":[["q","> Quote from: ribuck on December 07, 2010, 04:51:20 PM\n> OK, here goes. My design for DomainChain builds on many of the ideas expressed here already. My main contribution is to remove \"generation\" from the design. It turns out that relying only on transaction fees makes everything very much simpler, and makes it easy to piggyback DomainChain onto Bitcoin.\n\nNanotube and I have been working on a DNS spec that is quite similar to yours. We had hoped to have a private RFC period, but since your proposal is so close, we decided to just publish what we have now.","Quote from: theymos on December 07, 2010, 07:23:34 PM"],["t","I'm looking at the fees, which certainly would be a reason for a miner to include these into a block with a high priority.  Still, I'm trying to find any sort of motivation for a \"DNS Server\" to recognize any of this data other than as a repository of potential domain information.  There is a reference to a \"vibrant market\" for the fees being used here, yet this seems very altruistic that one of these servers would recognize any fee at all if they aren't getting any themselves.  I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.\n\nI suppose that this is in effect a way to ensure that the Bitcoin network stays strong, as it certainly is going to be making any sort of mining activity much more profitable by doing this.\n\nWhat pricing strategies that would be used by a domain server which would have an adjustable price in the interface or config file and why one server would set the \"price\" at 10 BTC or another at 15 BTC or still another at 5 BTC?  Is this basically \"filtering out spamsites\" or is there something more serious going on here?  Is this simply an \"open bid\" for each domain where the most money invested \"wins\" the domain?\n\nToward the end of the document there is a reference after a fashion about some more complex fee allocation system that passes around addresses which get deposited into some servers after a fashion.  I guess this is where I'm totally missing the point here perhaps or not understanding what is going on at all with these fees as there is something more implied by this document not written down."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27917#msg27917"},{"f":"Hal","d":1291765229,"b":[["t","What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?\n\nI have a couple questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal\n\nWhen you register a name, there is a fee to a DNS server. In the doc, this appears like a Bitcoin transaction fee. The first example shows 10.01 input and 0.01 output, so the 10.00 difference would be a transaction fee. But tx fees go to miners. Is it assumed that miners are the same as DNS servers? Or would there be a 2nd output, a fee to a particular DNS server to get it to register you, in addition to a tx fee to the miner?\n\nAre you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?\n\nWould anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?\n\nThanks -"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27920#msg27920"},{"f":"Anonymous","d":1291766601,"b":[["t","This is exciting stuff. The benefits of having an intrinsic value to bitcoin is inestimable and kills a lot of arguments against it. I would like to hear satoshi's thoughts on this as forking the network is not a decision taken lightly.\n\nIs there a way to reserve the top 1000 domains at Alexa ?  I can see massive issues down the road if say google has their name squatted on. Doing this would bring a lot of goodwill towards bitcoin rather than having all the top companies against it. One way this could be done is for the dev team or a council of bitcoin elders  register all of these names before the client is publicly released and hold them in trust. When a top 1000 company wishes to claim their name the profits could go to benefit bitcoin. Is that a good plan?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27925#msg27925"},{"f":"da2ce7","d":1291767520,"b":[["q","Is there a way to reserve the top 1000 domains at Alexa ? ","Quote from: Anonymous on December 08, 2010, 12:03:21 AM"],["t","This is a very good and important idea, we should set-up some 'domain trust' where well established domains will be protected until they are claimed (at a good fee) by a verified owner.\n\nMaybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27926#msg27926"},{"f":"kiba","d":1291767725,"b":[["q","Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.","Quote from: da2ce7 on December 08, 2010, 12:18:40 AM"],["t","No, no, no. The DNS system should be kept as simple as possible.\n\nThere will be no silly voting, or court, or any complicating shit."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27928#msg27928"},{"f":"Anonymous","d":1291768459,"b":[["q","> Quote from: da2ce7 on December 08, 2010, 12:18:40 AM\n> Maybe we could have a 'time-lock' of about a week or so where you claim a domain, and if half of the network decides that that domain should be in the trust they can deny that request.  Once the network is more established the minimum time-lock can be reduced.\n\nNo, no, no. The DNS system should be kept as simple as possible.\n\nThere will be no silly voting, or court, or any complicating shit.","Quote from: kiba on December 08, 2010, 12:22:05 AM"],["t","I think the delay in releasing the client would be enough for the top 1000 to be locked in\n "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27931#msg27931"},{"f":"theymos","d":1291768644,"b":[["q","I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.","Quote from: RHorning on December 07, 2010, 11:37:16 PM"],["t","That is the point.\n\nA handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.\n\nPeople who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above."],["q","Is this basically \"filtering out spamsites\"","Quote"],["t","Exactly."],["q","What if the consensus is that the Bitcoin network should not be used to support DNS (as I expect)? Then the only alternative is to go forward with a parallel but independent block chain, creating a second currency. Are we ok with that?","Quote from: Hal on December 07, 2010, 11:40:29 PM"],["t","Bitcoin already supports it technically, though recently a change was made that causes non-standard transactions such as the ones used by BitDNS to be skipped in blocks created by the official Bitcoin client. However, BitDNS transactions produce quite a lot of fees for generators, so if an implementation is created, I expect it will be easy to get a reasonable percentage of miners to ignore this new rule (only like 5% is really necessary)."],["q","Are you allowing name changes of the main part of the domain? Like elephantfood.bitdns can change to dogfood.bitdns (if it is available)? Or is this disallowed, in which case, exactly which kinds of name changes are allowed?","Quote"],["t","The left-most part has to stay the same. \"theymos.btc\" can be changed to \"theymos.bc\". Everything but the left-most part is advisory: \"theymos.btc\" can actually appear as \"theymos.btcdns\". In particular, if someone registers a top-level domain such as \"theymos.\", most servers will probably map it to \"theymos.btc\" or something."],["q","Would anyone who wants be able to run one of these special DNS servers, or do you envision there being relatively few of these?","Quote"],["t","Anyone can run them. I think the expiry time should be lowered to like 5,000, though, to make it easier to run a server."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27932#msg27932"},{"f":"chaord","d":1291768902,"b":[["t","I think reserving the top 1000 alexa domains by seeding the genesis block with those \"registrations\" would be an excellent show of good faith towards the world at large.  A council of bitcoin \"elders\" could be elected to hold the private keys to those initial 1000 domains, and turn them over when the time comes (for a fee, which will go towards bitcoin/domainchain community funds).  "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27934#msg27934"},{"f":"da2ce7","d":1291769280,"b":[["t","So in theory this is the perfect system for claiming a 'named address'.  If I wanted to send a payment to 'theymos.btcdns' I could. Or is my understanding wrong?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27936#msg27936"},{"f":"da2ce7","d":1291769473,"b":[["t","re-read nanotube's+theymos's proposal! Sound Good  Grin\n+1"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27937#msg27937"},{"f":"chaord","d":1291771627,"b":[["t","This is all very fascinating stuff.  I read themos+nanotube's proposal, ribuck's proposal, and rhorning's.  While I think I grasp the fundamental differences between them, I am not confident to weigh in.  Could I ask that someone more knowledgeable than I am on these matters create a table (wiki?) that lists the proposals as they currently are?\n\nI'm personally very intrigued by the idea of piggy backing on the existing bitcoin network, if it can be done cleanly and with minimal modification to bitcoin (as per nanotube/themos suggested).\n\nAs Kiba pointed out, I am most excited for bitcoin to have it's intrinsic \"use-value!\"  And it couldn't come at a more needed time what with wikileaks, pirate bay, etc all over the news.\n\nLastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a \"DomainShadow\" system that is only used in the event of crisis (like wikileaks attack, etc)?\n\nOverall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27946#msg27946"},{"f":"kiba","d":1291774100,"b":[["q","Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)","Quote from: chaord on December 08, 2010, 01:27:07 AM"],["t","Very strange to form a foundation for DomainChain before we form an organization for Bitcoin."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27958#msg27958"},{"f":"theymos","d":1291778899,"b":[["q","Lastly, and this could be due to my lack of intimate knowledge of DNS, but will this work seamlessly with more secure DNS protocols as well? Also, is this designed to ultimately replace existing registrars or will this always be a \"DomainShadow\" system that is only used in the event of crisis (like wikileaks attack, etc)?","Quote from: chaord on December 08, 2010, 01:27:07 AM"],["t","DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!\n\nI can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.\n\nIt should scale well, though, if it did go mainstream."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg27993#msg27993"},{"f":"nanotube","d":1291782457,"b":[["q","DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!\n\nI can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.\n\nIt should scale well, though, if it did go mainstream.","Quote from: theymos on December 08, 2010, 03:28:19 AM"],["t","just to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28008#msg28008"},{"f":"Anonymous","d":1291784133,"b":[["q","> Quote from: theymos on December 08, 2010, 03:28:19 AM\n> DNSSEC will work fine. And if you run your own server, you don't need to trust anyone!\n>\n> I can't see any of this becoming mainstream any time soon. You have to at least change your nameservers, and to get all of the security benefits you have to run a bunch of extra software all the time.\n>\n> It should scale well, though, if it did go mainstream.\n\njust to throw in a little bit of optimism here Smiley, if the piratebay dot-p2p guys 'see the light' than this system is better than theirs, and decide to get behind it, this has a pretty good chance of getting wider adoption. Smiley","Quote from: nanotube on December 08, 2010, 04:27:37 AM"],["t","We need a proof of concept.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28019#msg28019"},{"f":"kiba","d":1291784275,"b":[["t","Yes, coding need to be done soon.\n\nRepeating ad nauseum:\n\nSpeed is of the essence."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28020#msg28020"},{"f":"chaord","d":1291787140,"b":[["q","> Quote from: chaord on December 08, 2010, 01:27:07 AM\n> Overall, great work guys!!! If we can get some pros/cons of each proposal down on paper, I'm prepared to up my bounty considerably and help out where I can (perhaps on forming an official DomainChain/BitDNS foundation?)\n\nVery strange to form a foundation for DomainChain before we form an organization for Bitcoin.","Quote from: kiba on December 08, 2010, 02:08:20 AM"],["t","Ha.  Good point.  I was thinking the two could potentially operate under the same umbrella.  We'll see though."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28033#msg28033"},{"f":"Anonymous","d":1291790910,"b":[["t","Referencing this thread  http://bitcointalk.org/index.php?topic=2129.msg27968#msg27968\n\nI think Gavin is trying to tell us the way forward .\n\nBitDns is not bitcoin.  Smiley\n\nWe already have a forked chain.... Get something working on the test network and prove your theories.\n\nLets get it started in  here..... Cheesy"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28047#msg28047"},{"f":"Hal","d":1291792135,"b":[["t","A few more questions about http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal\n\nIt appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.\n\nNames can be changed when registered, but only from one TLD to another. You could change pics.sex to pics.p2p. I don't understand the motivation for this. It seems like something that would seldom be useful.\n\nI'm still confused about fees. I was assuming that fees would be paid to the DNS servers, for the service of acting as a gateway from the Bitcoin block chain to the DNS system. I now see another interpretation, where DNS servers don't receive the fees, but they nevertheless demand that transaction fees of a certain minimum level be paid to miners. As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?\n\nThe proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today. (I may be misunderstanding this!) Each of these DNS servers publishes a schedule of fees for performing this service. To register a new name... hmm, I am guessing now. Would you contract with one particular DNS server to do something else than host your regular DNS records?\n\nI had thought it would be ok to expect DNS servers to follow the block chain and honor valid domain name transactions without requiring certain minimum fees. Domain names are so valuable (at least at first) that miners already have ample motivation to demand substantial (like $100 = 500 Bitcoins per transaction) fees. Eventually, if the system is successful, virtually all DNS servers would read the block chain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28049#msg28049"},{"f":"RHorning","d":1291818154,"b":[["q","> Quote from: RHorning on December 07, 2010, 11:37:16 PM\n> I guess I'm missing the point of the fee other than as a way to provide an incentive for miners, and to put a little pain on the registrants involved here.\n\nThat is the point.\n\nA handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.","Quote from: theymos on December 08, 2010, 12:37:24 AM"],["t","In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each \"TLD\" would have its own central server where you would have to \"pay\" to get onto that server?\n\nWhat I don't see is the mechanism for how or even why a particular DNS server ought to even receive these fees as opposed to somebody else creating a \"registrar server\" and following this same protocol to put that data into Bitcions for considerably less or even \"free\".  This issue of where the money goes has been to me the issue all along, and the only place that could be identified easily as having done some sort of \"proof of work\" in terms of organizing the data is the block miner itself.... that is the Bitcoin block miner and not the DNS block miner as there is no sort of DNS block here at all.\n\nI don't see any rationale for using a particular registrar other than merely because of sheer convenience and the hassle of setting up the software on your computer.\n\nIf there is some way that you might show some cryptographic \"proof of work\" in processing domain records, I might agree that a particular \"registrar\" deserves some separate fees in addition to the Bitcoin miner, but then the problem is how do you get those fees to that particular \"DNS Block miner\"?  Otherwise there isn't any sort of effort being put forth by the registrar at all where literally anybody could create some software to put these records into the system.\n\nI could imagine a system where a sort of auction system on a particular domain happens where the person throwing the most number of bitcions in for a registration record \"wins\" the domain, but something seems a little off on that as well.  It also implies that anybody can \"steal\" your domain simply by throwing more coins at it than you have.  It is a great idea for miners, but lousy for those trying to register domains.\n\nThis is all about the money from my perspective, and this part has not been cleaned up for me upon reading the documentation.  The actual storage of the registration data itself has always been to me a trivial piece of the puzzle.  Throwing those records into Bitcoin transactions are useful as they do provide the time stamping and hashing ability of Bitcoin software, but any fees beyond Bitcoin transaction fees seem to be a pointless exercise without any sort of further proof-of-work.  Any additional fees being thrown with the \"registration\" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.  I could imagine some \"greedy\" DNS servers that might expect to be paid for bandwidth and being paid in Bitcoins or some other currency, or perhaps a very small fee for actually putting the transaction into the Bitcoin blocks for those who only have a \"thin client\" for Bitcoins, but those fees would be subject to a huge and highly competitive market where for most people it would be \"free\" anyway.\n\nThis is why I was trying to put together some sort of proof of work chain for data of this nature too, in part to put some scarcity into creating domain records."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28127#msg28127"},{"f":"ribuck","d":1291823705,"b":[["t","I've now studied the theymos/nanotube spec in more depth, and my questions and comments are starting to flow."],["q","The left-most part has to stay the same. \"theymos.btc\" can be changed to \"theymos.bc\". Everything but the left-most part is advisory: \"theymos.btc\" can actually appear as \"theymos.btcdns\". In particular, if someone registers a top-level domain such as \"theymos.\", most servers will probably map it to \"theymos.btc\" or something.","Quote from: theymos on December 08, 2010, 12:37:24 AM"],["t","I really don't get this. What's the point of having a \"right-hand-side\" if it is advisory? The user doesn't want to have to type theymos.bc into their browser when they're at an internet cafe that uses one DNS, but have to type theymos.btcdns into their browser at home if their ISP uses a different DNS. And if they just type \"theymos\", what if they are on a LAN that has a node called theymos?\n\nAny default right-hand-side should be explicit in the spec. Also, I don't think something hard-to-pronounce like \".btcdns\" is going to work with the public. Can you imagine TV ads saying \"go to walmart dot bee tee see dee en ess\"?\n\nIn the initial phase at least, I suggest that all names registered should be of the form something.domain\n\nI propose \".domain\" for this purpose because it's generic and pronounceable. It also somewhat cheekily implies that this is the ultimate all-encompasing domain name registration system.\n\nThree advantages:\n\n• This establishes clear branding.\n\n• It helps to keep the system simple, so that we can easily describe how to get up-and-running with these newfangled names.\n\n• It avoids any clashes with existing domain names.\n\nIf people prefer to go for something more ambitious, I suggest that all names registered should be of the form something.tld where .tld can be anything of three or more characters except for existing recognised top level domains. So you could register hamburger.red or silly.fool but not zebra.com"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28139#msg28139"},{"f":"ribuck","d":1291824002,"b":[["q","Is there a way to reserve the top 1000 domains at Alexa ?","Quote from: Anonymous on December 08, 2010, 12:03:21 AM"],["t","Please let's drop the idea of reserving the top names. Would you think it was fair if you owned the 1001st domain? It's only going to lead to disputes and hassles.\n\nI suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.\n\nWe really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28145#msg28145"},{"f":"kiba","d":1291824147,"b":[["q","We really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest.","Quote from: ribuck on December 08, 2010, 04:00:02 PM"],["t","It could set some precedent for protocol change that allow people to shut down certain domains.\n\nI suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28146#msg28146"},{"f":"ribuck","d":1291824999,"b":[["q","My concern is that there would be a rush to grab hot domains.","Quote from: Hal on December 07, 2010, 08:06:02 PM"],["t","If desired, an initial rush could be spread out by a phased introduction.\n\nFor example, in the first week only names of ten characters or longer would be accepted for registration. The next week, names of nine characters or longer would be accepted. And so on, until by week ten any length will be accepted.\n\nA more sophisticated phasing would hash the domain name to a number from 1 to 1000. On each of the first thousand days, names that hash to that day's number are added to those that can be registered. So, by day 42 it would be possible to register any domain name that hashed to a number in the range 1 to 42. After day 1000, any name could be registered.\n\nA third possibility is simply to limit the number of registrations. Suppose each block limited the maximum number of domain name registrations to the current generation difficulty divided by 1024. For now, that would mean 8 domain name registrations per block, but the limit would rise over time (quite quickly, I think).\n\nI'm not convinced that a registration rush needs to avoided, but technical measures can be used to avoid a rush if it is desired to do so."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28148#msg28148"},{"f":"RHorning","d":1291825092,"b":[["q","I suggest that we exclude all existing top level domains from DomainChain registration. So no-one will be able to register google.com through this system. They could, however, register google.domain but they would probably have to fight with Google in court under trademark law.\n\nWe really don't want the DomainChain system saying that it will \"protect\" 1000 names but \"refuse to protect\" all the rest.","Quote from: ribuck on December 08, 2010, 04:00:02 PM"],["t","Agreed.  I suggested in my previous domain allocation system that the standard ICANN/InterNIC domains and perhaps to be fair some of the domains currently being done with other networks like OpenNIC and the .onion \"domain\" of the Bittorrent network ought to be held in \"reserve\" as a part of the internal protocol we are setting up here.  My suggested domain allocation system would have that as an organic part of the system although it would be useful to hold these TLD in escrow for whenever or if ICANN wants to have control of them.\n\nSince to use one of the TLDs with a server you would need to have it assigned to an IP address of some sort, somebody like Google could go aver \"google.btc\" as a trademark violation by searching for the network which assigned the IP address of the server using that name.  If the domain record points to 127.0.0.1, it really isn't a threat to Google until that address changes anyway.  I agree that this is beyond the scope of this protocol to take care of the Alexa top 1000 names and the only real issue is spoofing existing domain names being used by other DNS registries.\n\nAs a side note, during the actual reference implementation of one of these servers it would be nice to throw a bone to OpenNIC and the \"dot P2P\" guys (presuming they set up their own system) to forward DNS requests that might fall under those respective domain registries.  This is sort of a tip of the hat to say thanks for making sure ICANN doesn't have 100% exclusive control over domain registrations and to support what I think are good projects in their own right even if they aren't a P2P distributed naming system.  That might even get a reciprocal agreement with those alternate domain registries to spread these registrations with the DomainChain registries much further at least initially."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28149#msg28149"},{"f":"RHorning","d":1291825647,"b":[["q","It could set some precedent for protocol change that allow people to shut down certain domains.\n\nI suspect most of the domain names will be grabbed by speculators who will ransom it to large corporations. Search engines would ignore domain names that violate certain standard of a business mark.","Quote from: kiba on December 08, 2010, 04:02:27 PM"],["t","Who would be given the \"authority\" to remove domain names?  That implies central authority of some sort that has control over this network.\n\nDomain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to \"delist\" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your hands up and say \"I can't change that, sorry\".\n\nThe owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28151#msg28151"},{"f":"kiba","d":1291829049,"b":[["q","Who would be given the \"authority\" to remove domain names?  That implies central authority of some sort that has control over this network.\n\nDomain squatting has a time honored and long tradition anyway and isn't going to change with how we are going to be running this system.  By setting up a system to \"delist\" a domain name, it also sets up the person or group of people with presumably some private key which can in turn authorize the removal of domains as a target for receiving judicial injunctions and potentially other sorts of legal problems.  If instead you can demonstrate that it is cryptographically impossible to change the domain registration information, all you can do is throw your handseddrli up and say \"I can't change that, sorry\".\n\nThe owner of the IP address referenced by the domain registration should be the target of attack, not the domain registration system.","Quote from: RHorning on December 08, 2010, 04:27:27 PM"],["t","You have forgotten the rule that I asserted earlier in the thread:"],["q","When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.","Quote"],["t","Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28162#msg28162"},{"f":"RHorning","d":1291830234,"b":[["q","Nowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.","Quote from: kiba on December 08, 2010, 05:24:09 PM"],["t","Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to \"somebody\" to take care of that issue.  You could have a \"voting\" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore \"by consensus\" drop the domain.  It would also provide an unneeded attack vector on the network as well as the \"votes\" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.\n\nI just don't know of an effective way to kill a domain record shy of simply letting it expire.  As long as the registration is following the rules of the network (however we set that up), I don't see how it could possibly be removed."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28166#msg28166"},{"f":"kiba","d":1291830294,"b":[["q","Then I'm confused about how else you would set up a system to arbitrarily remove a domain record from the DNS network?  If you got an idea on how to implement that, I'm interested.  The only system I can think of is to arbitrarily assign authority to \"somebody\" to take care of that issue.  You could have a \"voting\" system perhaps that would count up requests to eliminate a domain from a majority of the network and therefore \"by consensus\" drop the domain.  It would also provide an unneeded attack vector on the network as well as the \"votes\" would also be subject to some kind of manipulation that perhaps would be even worse than a trusted authority figure.","Quote from: RHorning on December 08, 2010, 05:43:54 PM"],["t","You misunderstood me. I didn't suggest anything like voting or whatever."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28168#msg28168"},{"f":"ribuck","d":1291830562,"b":[["t","The theymos/nanotube design is much more heavyweight than my design, in terms of how much data it stores in the block chain.\n\nMy design stores the domain name plus a couple of nameserver IP addresses (say, 50 bytes) for an everlasting registration.\n\nThe theymos/nanotube design needs much more data: the initial registration, the regular renewals, and the possibility to include actual DNS records themselves up to 520 bytes. There's talk of the renewals being required perhaps as frequently as every 2000 blocks, and certainly no more than every 52000 blocks.\n\nOver 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.\n\nI'm starting to think that an everlasting registration really is the way to go. In the DomainChain design, the registration would not be affected by block chain compaction, since compaction only affects spent transactions. If you transfer a DomainChain registration, or modify its name servers, all of the necessary information is contained in the latest transaction, which will remain unspent until the registration is deliberately modified. However, the theymos/nanotube design requires a sequence of transactions (registration, extra fee, DNS record, ...) where only the last transaction in the sequence remains unspent.\n\nI think users will be uneasy about having to renew every 2000 or even 52000 blocks. Having to remember to renew, in order to avoid losing your registration, is bad enough. But block generation rates are variable, so that you won't even know for sure when your renewal falls due. Unpredictable renewals are not something that would make me feel good about using such a system for my domain name registrations. I can see many accidental domain name losses occurring under this system.\n\nObviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28170#msg28170"},{"f":"kiba","d":1291830843,"b":[["q","Obviously there needs to be a business case made that non-expiring domain names will work. But there also needs to be a business case made for the renewal process of the theymos/nanotube design.","Quote from: ribuck on December 08, 2010, 05:49:22 PM"],["t","Time based expiry date rather than block based expiration system. Obviously registrar could remain users to renew as they had done in the earlier system."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28172#msg28172"},{"f":"RHorning","d":1291834423,"b":[["q","A handful of servers will be public DNS servers running with \"authority\" over those BitDNS TLDs that they support. To get in one of these, you'll have to pay them directly in addition to the fees that go to whoever generates the block. This can be done with additional outputs, or you can pay on their site in the traditional Bitcoin way. This is where a registrar is especially useful, since they will know all of the current fee requirements of the various servers, and they can pay them all at once automatically.\n\nPeople who run their own servers will not get a fee like this, but will rely only on the block fee. Configure your server to require the fee that you think is best, and you will see only those domains that have paid that fee or above.","Quote from: theymos on December 08, 2010, 12:37:24 AM"],["t","Re-reading this, I think I \"get\" how this is going to work for registrars, at least how Theymos is proposing here.\n\nEach \"Domain server\" would separately and independently charge a fee for \"registering\" the domain on that particular server, where essentially everybody would be paid simultaneously when a new domain would be registered.\n\nSomething here just doesn't sound right, which is why I keep bringing this up.  I don't see the mechanism for recognizing new domain servers or what criteria ought to be used so far as to whom these fees are going to be allocated.  A domain server which is regularly being used by just a couple computers in a small office would in this case be a \"peer\" to a domain server at a major university servicing perhaps thousands of computers for domains.  Yet in this case both would be receiving registration fees and from a network perspective would be indistinguishable.  However getting \"your domain\" recognized by that major university server would be much more \"valuable\" than the server in a small office.  Any attempt to report usage could easily be manipulated in a number of ways making it to me impossible to realistically distinguish between the two servers, at least algorithmically.\n\nMaybe I'm missing something fundamental here.  I sure hope so.  It seems sort of silly for somebody to set up a \"domain name server\" on their home computer and essentially sit back and earn bitcoins simply by being connected to the internet alone (no proof of work), receiving payments for domain registrations that are never used.  That sounds like a neat gig to get into, but I don't understand what \"service\" they are providing to the community for doing that or why the fees ought to be paid yet other domain servers who are clearly being used by thousands of computers are going to be considered \"equal\" and receive roughly the same amount of money?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28188#msg28188"},{"f":"ribuck","d":1291837934,"b":[["t","I think we should dispense with the complexity associated with paying various servers. We should also dispense with the concept of paying more if we want better visibility for our domain names.\n\nNo-one wants a system where some people can reach some.domain and some people can't, depending on which servers are getting their share of the payment. Or a system where a new server can come to prominence and put pressure on people to pay again for the domains they already paid for.\n\nLet's cut it down to the simplest business model that can work.\n\nSuppose there are some generators who will include domain name registrations into blocks that they generate, because they want to earn the transaction fees. Those generators will operate public-facing domain name servers.\n\nWhy? They need to do this, to make the domain name service credible so that people will use DomainChain for their domain registrations. For the generators, it's an overhead, but a necessary one. Kind of like how most restaurants provide toilets without charging separately for them.\n\nYou could argue that there will also be some operators who would generate, and who would collect the transaction fees for domain name registrations, but who would not operate a server. After all, why incur the overhead if the other generators will operate the servers?\n\nBut the market will take care of this. The generators who do operate servers are not going to accept the blocks generated by those who sell domain names without providing domain name servers.\n\nAdditionally, a market like this is likely to have two other kinds of players.\n\nThere will be a few organizations who are willing to operate a server for free, perhaps for ideological reasons. Those servers will probably be overloaded and slow (like the free Usenet servers), but they act as a backstop which forces the commercial operators to provide something better.\n\nThere will also be a few commercial operators who provide enhanced super-fast servers without being generators. They will do this either because they have paying customers who want the best domain name service that is possible, or they will do it for their own business reasons (as Google does with their free-to-access domain name servers).\n\nHere are the advantages of this simpler system:\n\n• For the domain name owner, the registration is convenient, secure, and lasts forever,\n\n• For the internet user, the same set of domains is served to everyone,\n\n• For the generators, it's a worthwhile extra source of income, and\n\n• For the Bitcoin system, it's an easy way to get extra strength into the block chain with minimal extra data"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28211#msg28211"},{"f":"ribuck","d":1291838224,"b":[["q","Time based expiry date rather than block based expiration system.","Quote from: kiba on December 08, 2010, 05:54:03 PM"],["t","Well yes, time based expiry is better for the customer, but the motivation for block-based expiry in the theymos/nanotube design seems to be that the transaction records are vulnerable to block chain compaction, which might happen after a specific number of blocks.\n\nOf course, there is nothing that forces the providers of domain name servers to compact their copy of the chains, but then a new entrant into the business can't get all the data unless they can lay their hands on one of these uncompacted block chains."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28214#msg28214"},{"f":"Hal","d":1291839014,"b":[["t","I agree with ribuck that DNS servers don't necessarily need to get paid, to support Bitcoin domains. After all, what is the purpose of a DNS server? It is to lookup domains for its clients, which are users wanting to connect to computers using domain names. If BitDNS becomes popular, DNS servers will want to be able to lookup those domains too. All that is necessary is to track the block chain and maintain indexes and hash tables to record which domains are in effect and their basic DNS data. DNS servers don't have to be Bitcoin miners. The existing motivations for DNS servers to operate and provide lookup serves to their clients will be sufficient to make them track Bitcoin domains."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28220#msg28220"},{"f":"ribuck","d":1291848494,"b":[["t","DomainChain wiki is here:\nhttp://domainchain.org/wiki/doku.php?id=start\n\nThere's not much there, but I will work on it tomorrow.\n\nMeanwhile, some interesting further ideas on integrating with the Bitcoin block chain have been added to the Theymos/Nanotube wiki."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28295#msg28295"},{"f":"theymos","d":1291851406,"b":[["q","It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.","Quote from: Hal on December 08, 2010, 07:08:55 AM"],["t","This is like that, too. In this system, you're always registering a TLD. Even if I register \"theymos.btc\", I'm actually getting \"theymos.\". For better usability, though, BitDNS servers will make this a second-level domain by attaching a TLD like .bitdns or .btc to the registered name. The TLD in the registration is a suggestion for this: in this case, I'm suggesting that \"theymos.\" be followed by \"btc\" (though the server is free to ignore my suggestion).\n\nThe idea is to allow maximum market adaptability. Probably all servers will just use \".btc\" or whatever, and totally ignore the suggested value. As an example of something servers could do:\n- If your suggested domain suffix is com/org/etc., then your domain will actually overrule .com domains of the same domain for those few users who have configured BitDNS to do so.\n- Otherwise, \".btc\" is used.\n\nIt's a bad idea to hardcode any TLD into the spec. What if ICANN allocates .btc?\n\nA later version might also look at the entire name+TLD for uniqueness. It might be possible in that case to switch from old-style names to new-style names with namechange."],["q","As long as they see that the domain name was registered with a large enough transaction fee to the miner, they will pass it through to the DNS. Is it possible that this is what was intended?","Quote"],["t","Yes. The idea is not to compensate the servers (usually), but to eliminate spam registrations. The BTC is the \"proof-of-work\"."],["q","The proposal seems to envision a relatively small set of DNS servers that would be authorities for these new domain names and be the ones who bring the names from the block chain into DNS. These would be somewhat analogous to registrars today.","Quote"],["t","The servers are analogous to DNS root servers. There may also be registrars, which will interface with several BitDNS servers (as current registrars interface with gtld-servers.net, for example)."],["q","In other words, this isn't really a distributed or P2P DNS system, or perhaps I'm missing something else here too.  Each \"TLD\" would have its own central server where you would have to \"pay\" to get onto that server?","Quote from: RHorning on December 08, 2010, 02:22:34 PM"],["t","Certainly not. You pay and everyone recognizes you at whatever TLDs they have chosen to see BitDNS domains at."],["q","Any additional fees being thrown with the \"registration\" is not going to anybody actually putting effort in terms of running the domain server or doing registrations.","Quote"],["t","Almost all of the load is carried by the Bitcoin miners, which is why they get most of the money. Some BitDNS servers will provide public lookup services, which demands some payment. I'm thinking that the registrants will pay these to list them, but maybe the people looking up BitDNS domains will pay them instead."],["q","Over 10 years, the theymos/nanotube design might store anywhere between 600 bytes and 120,000 bytes per domain name.","Quote from: ribuck on December 08, 2010, 05:49:22 PM"],["t","The average Bitcoin transaction size is 216 bytes. Why does anyone care if BitDNS names are worth 3-500 Bitcoin transactions over 10 years? If miners are taking the transactions, then there is no supply problem. If there is a supply problem, then whoever pays more gets space in blocks. This is fair."],["q","I'm starting to think that an everlasting registration really is the way to go.","Quote"],["t","Without an expiration, you need to download the entire block chain to get a current DNS database. Domains must expire if you want to allow end-users to run their own server.\n\nIt also destroys unique resources. The pricing scheme would have to control the use of these unique resources appropriately, which requires some market mechanism."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28306#msg28306"},{"f":"em3rgentOrdr","d":1291852214,"b":[["q","You have forgotten the rule that I asserted earlier in the thread:\n\n> Quote\n> When in doubt, remove human elements. Adopt certainty of computer software code over uncertainty of judges. Complicated rules invite gaming and abuse.\n\nNowhere did I suggest that we should give authority to whoever, or shutting down the DNS system in favor of court/judges/messyhumanjudgement.","Quote from: kiba on December 08, 2010, 05:24:09 PM"],["t","Kiba is wise beyond his years!\n\nAnyway, I've been thinking outside the box a little bit...and wondering maybe to scratch the whole idea of domain names.  I'm thinking somehow be able to associate a bitcoin address, or maybe some hash of a transaction, with a location on the internet somehow.  Also, it maybe possible to sidestep away from the concept of domain names considering that nowadays search engine technology has improved so much.\n\nWouldn't it be cool to associate a bitcoin address directly with a webpage/internet location for that product/resource/whatever that is being sold with that bitcoin address?  Anyway, let me think about this some more and write out a concrete proposal.  Obviously, this is sortof off topic from this thread..."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28310#msg28310"},{"f":"RHorning","d":1291854489,"b":[["t","Asking as a general question, is the whole concept of throwing the data into transactions a dead issue now?  With the release of Bitcoin v. 3.1.18 Satoshi has essentially thrown down the gauntlet that adding such data to transactions is considered a form of an attack on the network.  Miners who aren't using a codebase derived from the reference implementation still may add blocks to the network involving these \"goofy\" transaction packets, but by design the reference implementation will not recognize the transactions.  If we work around the IsStandard() algorithm, it is only going to change to stop whatever changes we make.\n\nThis is a subtle but interesting issue where essentially the only way we can guarantee that a domain transaction can be put into a block chain is to create a custom miner and compete for blocks to put those transactions into the network.  That makes for some interesting problems in terms of latency for an effort like DomainCoin.\n\nShould we move onto the forked version of Bitcoin to implement this idea again?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28318#msg28318"},{"f":"kiba","d":1291855152,"b":[["t","Miners are rejecting the [edit]isStandard."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28322#msg28322"},{"f":"RHorning","d":1291855939,"b":[["q","Miners are rejecting the same.","Quote from: kiba on December 09, 2010, 12:39:12 AM"],["t","How are the miners going to get these transactions?  I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.  I'll have to dig into the 0.3.18 source code for the details, but the description is just an initial shot across the bow on this concept.  If you have a miner as a peer who ignores this algorithm, they might get put into the block, otherwise you might just be SOL.  From what I understand, if all of your peers are 0.3.18 clients (and presumably later versions too) they won't even forward transactions to other peer nodes that are \"corrupted\".\n\nIt is a subtle change, but it is a big deal."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28327#msg28327"},{"f":"MoonShadow","d":1291856279,"b":[["q","> Quote from: Hal on December 08, 2010, 07:08:55 AM\n> It appears this can support several top level domains, such as .anon, .sex, .p2p, or whatever. Other proposals envisioned a single new TLD like .bitdns.\n\nThis is like that, too. In this system, you're always registering a TLD.","Quote from: theymos on December 08, 2010, 11:36:46 PM"],["t","So what would prevent me from registering the domain jackass.theymos.btc?  "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28329#msg28329"},{"f":"kiba","d":1291856360,"b":[["t","Others elsewhere or previously have suggested we build a chain dependent on the bitcoin chain. Some way to hash the data against a block.\n\nThat way, miners would still be strengthening the bitcoin network."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28331#msg28331"},{"f":"appamatto","d":1291858069,"b":[["t","Hey guys.  I'm really surprised that my post received so much attention!\n\nAnd, I'm glad that BitDNS (or domain chain?) has generated this level excitement.\n\nHowever, I urge you to re-read my initial post, as I feel that original formulation of the idea solves many of the problems you are currently discussing, including the (1) business-plan problem and (2) the bitcoin integration problem.  There is also a third problem which hasn't been brought up by anyone thus far, which is (3) the problem of dividing the CPU pool among multiple block chains.\n\nIn the original formulation, bitDNS is simply an example of a possible generalization of bitcoin.  It should be possible to dream up many such applications requiring block chains for systems that need some kind of quorum.\n\nWe should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.\n\nBitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.  This way a bitDNS server will only need to download its own app payload without worrying about bitcoin's payload and vice-versa.  As the number of bit-apps increase, this problem of smushing them all into bitcoin will only get worse, and (2) becomes a big problem that has to be solved for each app.  BitX neatly deals with applications liberally, leaving it completely up to them to decide their own protocols but forming a valuable backbone for them.\n\nWith bitcoin and bitDNS as separate apps running on BitX, (1) is easily solved with third-party escrows.  Escrowing is a big problem, and perhaps unsolveable, with respect to bitcoin and USD or PPUSD transactions, but it is incredibly reliable when executed between two bitapps.  A trusted escrow can receive both transactions, verify them mechanically and automatically release the assets when both transactions are properly verified.\n\nNote that this also frees bitDNS from bitcoin baggage when bitMoney overtakes bitcoin as the most popular bit-currency.  I believe in fact that bitcoin in its present form will necessarily be overtaken due to problem (3).\n\nThe big deal: the CPU pool division problem.  CPU division will occur when bitcoin can't or won't support bit-application bitFoo.  This may occur with bitDNS, or it may occur later, but I think it will occur at some point.\n\nEvery miner for bitFoo will be one less miner for bitcoin and vice-versa.  Both of these systems will be twice as susceptible to attack (if they have roughly equal CPU pools), and the problem multiplies as the number of bit-apps and their block chains increases.\n\nBitX cleanly solves this by having every bit-app generate on the same block chain, the BitX chain.  They weave their own block chains within the uber-chain, and unwittingly protect eachother from attack.  It also greatly speeds adoption of any given bit-app; the BitX miners are already generating bitcoins, so why not generate bitDNS names as well?  There is no cost to the miner, and who knows, this new-fangled bitDNS thing might actually take off someday?\n\nEven if the demerits of separate block chains can be mitigated, the merits of a unified chain cannot be overstated in my view.\n\nFinally, I hope that the name will remain BitDNS or BitNames, keeping the trend of revolutionary projects like bittorrent and bitcoin.  There isn't any reason to call it domainchain if it is built upon BitX in any case, because the name registration aspect will be an implementation on top of the BitX chain rather than a full implementation with its own chain.\n\nThis separation of concerns makes BitX and bitDNS/bitcoin simple enough that I feel I can implement them myself if necessary, although slowly, in my spare time.  I'm looking forward to some bit fun!\n\nThanks guys!"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28343#msg28343"},{"f":"theymos","d":1291858736,"b":[["q","So what would prevent me from registering the domain jackass.theymos.btc? ","Quote from: creighto on December 09, 2010, 12:57:59 AM"],["t","Nothing. But hopefully servers will ignore tricks like that."],["q","How are the miners going to get these transactions?  I don't think the transactions are even being broadcast from one node to the next if they fail to meet the IsStandard() algorithm, but rather they must be put in directly by a miner.","Quote from: RHorning on December 09, 2010, 12:52:19 AM"],["t","Right. You can send directly to artforz.ath.cx or any of doublec's pool addresses. I will relay non-standard transactions at theymos.ath.cx."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28350#msg28350"},{"f":"jgarzik","d":1291859423,"b":[["q","We should be discussing BitX, the general block chain that in the future will support both bitcoin and bitDNS.  It neatly solves (1) and (2), as well as the biggest problem in my view, the CPU pool division problem.\n\nBitX is essentially an uber-chain which has hashes of app (bitcoin, bitDNS, ...) payloads as its payload.","Quote from: appamatto on December 09, 2010, 01:27:49 AM"],["t","Responded, in this new thread <http://bitcointalk.org/index.php?topic=2163.0>."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28356#msg28356"},{"f":"da2ce7","d":1291861456,"b":[["t","I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.\n\nThe solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.\n\nEDIT: see http://bitcointalk.org/index.php?topic=1847.0  for info about how the transaction fees will dictate what is included in the chain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28364#msg28364"},{"f":"kiba","d":1291861839,"b":[["q","I believe the problem with the generalized BitX is that the more that one adds to the chain, the higher the payload and overhead.\n\nThe solution to this is to use the Bitcoin chain, and use transaction fees to add additional content, the market will decide what is worth including in the chain or not, based solely on the cost/benefit of doing so.","Quote from: da2ce7 on December 09, 2010, 02:24:16 AM"],["t","Bigger stuff mean higher priority. Bitcoin users who didn't load the bitcoin chain data with lards are left with lower priority."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28366#msg28366"},{"f":"Anonymous","d":1291889957,"b":[["t","Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.\n\nProblem solved. To provide the initial security to the network it needs a few miners with gpu cards.\n\nWhos in?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28474#msg28474"},{"f":"da2ce7","d":1291890477,"b":[["q","Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.\n\nProblem solved. To provide the initial security to the network it needs a few miners with gpu cards.\n\nWhos in?","Quote from: Anonymous on December 09, 2010, 10:19:17 AM"],["t","Not me! I think that nanotube's+theymos's proposal has real elegance! Creating another chain is all good and well, but the current chain can be used for many things, might as well maximize it's potential.\n\nhttp://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28476#msg28476"},{"f":"ribuck","d":1291893313,"b":[["q","Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.\n\nProblem solved. To provide the initial security to the network it needs a few miners with gpu cards.\n\nWhos in?","Quote from: Anonymous on December 09, 2010, 10:19:17 AM"],["t","I'm not in for a new genesis block. It risks harming Bitcoin. If the alternative block chain is commercially successful, someone will add a currency to the alternate chain and it will overtake Bitcoin.\n\nAnyway, don't think that Satoshi has killed the idea of Domain Names in the block chain. Here's what the latest changes mean:\n\n1. If you register a domain name, you must connect to a miner that supports it (because standard clients won't relay your request). No problem. You will need to be using a modified client anyway (to give you a way to specify the domain name, the IP addresses and the fee) and the client can be designed to connect to known performant miners (which will probably be most of them).\n\n2. The standard Bitcoin clients will accept the blocks generated by the performant miners, but won't see the Domain Name transactions.\n\nSo what's the problem? What's not to like?\n\nI say we should continue to develop the ideas, then try them out on the test network."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28480#msg28480"},{"f":"Anonymous","d":1291893534,"b":[["t","I still hear talking.  Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28481#msg28481"},{"f":"em3rgentOrdr","d":1291903276,"b":[["t","I was doing some reasearch into alternatives to DNS, and I was reading about how TOR's hidden services <http://www.torproject.org/docs/hidden-services.html.en> assigned .onion address, and I came across the concept of Zooko's Triangle <http://en.wikipedia.org/wiki/Zooko's_triangle>, which argues that names cannot be global, secure, and memorable, all at the same time:\n\n\"Domain names, for example, are global and memorable, but as the rapid rise of phishing demonstrates, they are not secure\".  Basically, there will always be imposters who try to claim the domain name of your brand or some misspelling.  So I'm almost wondering if the whole concept of domain names is fundamentally flawed to begin with.  And it seems there is always has to be some sort of centralized means of allocating domain names.  We can't even decide what should be the rate-of-issue for new bitDNS domain names, what the starting price should be for transaction/purchase, how many top Alexis domain names (if any) we should reserve, where/how should the domain directory be located/stored. Maybe we need to stop using domain names entirely, and put our focus more on search engines, links, coupled with public-key cryptography to authenticate the genuity of an internet brand/website/address.  I'm looking into some system called Pet Names <http://www.skyhunter.com/marcs/petnames/IntroPetNames.html>...and am trying to figure out a nice way they could be used to assign unique, human-readable (memorable), and global names for bitcoin addresses.  I will start another thread for this, and provide a link here...\n\nAnyway, I think NoAgenda is right here that the Bitcoin block chain, from now on, should be a pure financial vehicle, considering that the latest bitcoin version update removes the ability to include extra text in transactions:"],["q","Ok its time to stop talking and do something. Create another genesis block for domaincoins. Bitcoin will be a pure financial vehicle from this point forward. As such it should be as lean as possible.","Quote from: Anonymous on December 09, 2010, 10:19:17 AM"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28521#msg28521"},{"f":"ribuck","d":1291905371,"b":[["q","Maybe we need to stop using domain names entirely","Quote from: em3rgentOrdr on December 09, 2010, 02:01:16 PM"],["t","If you try to redesign everything, you will end up successfully redesigning nothing.\n\nThe way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way."],["q","... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...","Quote from: em3rgentOrdr on December 09, 2010, 02:01:16 PM"],["t","Not so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28532#msg28532"},{"f":"em3rgentOrdr","d":1291906764,"b":[["q","> Quote from: em3rgentOrdr on December 09, 2010, 02:01:16 PM\n> Maybe we need to stop using domain names entirely\nIf you try to redesign everything, you will end up successfully redesigning nothing.","Quote from: ribuck on December 09, 2010, 02:36:11 PM"],["t","of course, I didn't mean I wanted to redesign the whole DNS.  The conclusion of my musing is: maybe there is some way to associate bitcoin addresses with a unique and human readable (memorable) name using a petname system."],["q","The way for a small group to achieve success is to design a drop-in-replacement that's significantly better in one important way.","Quote from: ribuck on December 09, 2010, 02:36:11 PM"],["t","I think this is important, and I encourage people to work on this."],["q","> Quote from: em3rgentOrdr on December 09, 2010, 02:01:16 PM\n> ... considering that the latest bitcoin version update removes the ability to include extra text in transactions ...\n\nNot so. The latest version won't include transactions with extra text in blocks that it generates itself, but it accepts blocks generated by others that contain transactions with extra text.","Quote from: ribuck on December 09, 2010, 02:36:11 PM"],["t","Ok, thanks for clarifying."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28543#msg28543"},{"f":"ribuck","d":1291923696,"b":[["t","Of likely interest:\n\n\"Gov't crackdown spurs initiatives to route around DNS\"\nhttp://www.itworld.com/legal/129947/net-censorship-dns-alternative"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28667#msg28667"},{"f":"kiba","d":1291924265,"b":[["t","Our code repository is non-existent and we're still debating the best route for DomainChain/BitDNS.\n\n* kiba is anxious."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28673#msg28673"},{"f":"satoshi","d":1291928562,"b":[["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696","s":1,"n":532,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/532/"},{"f":"ribuck","d":1291928736,"b":[["t","Kiba, I wrote this response before Satoshi posted above. I'll need some time to understand Satoshi's post."],["q","* kiba is anxious.","Quote from: kiba on December 09, 2010, 07:51:05 PM"],["t","Don't be anxious. I already said I thought it would take 2 weeks to agree design directions before coding.\n\nThere has been excellent development over the past 24 hours. It has become clear that Gavin's changes to handling of non-standard transactions don't rule out domain registration integrated with Bitcoin.\n\nIt is also becoming clearer that there is less distance between my DomainChains ideas and the theymos/nanotube design. Their design does not have the tangled ties with domain name server operators, that I previously thought it did.\n\nHang in there! Two weeks will seem like nothing in the long term outcome."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28697#msg28697"},{"f":"nanotube","d":1291929640,"b":[["q","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.","Quote from: satoshi on December 09, 2010, 09:02:42 PM"],["t","sounds excellent in theory..."],["q","The 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.\n\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.","Quote"],["t","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) ?\n\nvery curious to hear your further thoughts on this. Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28700#msg28700"},{"f":"jgarzik","d":1291930355,"b":[["q","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.\n\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.","Quote from: satoshi on December 09, 2010, 09:02:42 PM"],["t","This sounds very very interesting, something to explore.\n\nCan you elaborate on how would it work in practice?  Separate networks and block chains implies hashing one block header for each network, with different resulting hashes, does it not?\n\nThe only thing I can come up with is the completely naive and slightly cache-unfriendly implementation...\n\nwhile (nonce < 0xffffff)\n    nonce++\n    for each network\n        data_block[nonce_offset] = nonce        // ie. our nonce\n        scanhash(data_block)\n\nor\n\nfor each network\n    while (nonce < 0xffff)\n        data_block[nonce_offset]++\n        scanhash(data_block)\n\nI could easily update cpuminer to poll multiple RPC endpoints for 'getwork'..."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28702#msg28702"},{"f":"jgarzik","d":1291931346,"b":[["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) ?","Quote from: nanotube on December 09, 2010, 09:20:40 PM"],["t","Same incentive as the main chain -- you get paid."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28705#msg28705"},{"f":"Anonymous","d":1291933417,"b":[["t","So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?\n\nIts a simple elegant solution from satoshi."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28710#msg28710"},{"f":"nanotube","d":1291934606,"b":[["q","> Quote from: nanotube on December 09, 2010, 09:20:40 PM\n> 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) ?\n\nSame incentive as the main chain -- you get paid.","Quote from: jgarzik on December 09, 2010, 09:49:06 PM"],["t","but if you get paid just as much by mining pure bitcoin without the side hashing..."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28713#msg28713"},{"f":"satoshi","d":1291934810,"b":[["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) ?","Quote from: nanotube on December 09, 2010, 09:20:40 PM"],["t","The incentive is to get the rewards from the extra side chains also for the same work.\n\nWhile you are generating bitcoins, why not also get free domain names for the same work?\n\nIf you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28715#msg28715","s":1,"n":533,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/533/"},{"f":"Judson","d":1291935625,"b":[["t","I agree with satoshi's idea. It seems like the best of both worlds."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28717#msg28717"},{"f":"da2ce7","d":1291939807,"b":[["q","If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.","Quote from: satoshi on December 09, 2010, 10:46:50 PM"],["t","I'm still trying to get my head around your idea completely.  The main reason that I liked the idea of including BitDNS into the bitcoin block chain via transaction fees is that it gives BitDNS a very comprehensive economic support using bitcoins, thus increasing the value and usefulness of bitcoins.\n\nI gather from Sotoshi's model, both BitDNS coins and bitcoins are generated by the same block, allowing them both to be traded as a commodity.  The problem I see with that is that domain names have value from their name, registration costs, and bandwidth/computer cost , not scarcity in number.\n\nIn nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market.  As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28731#msg28731"},{"f":"theymos","d":1291940280,"b":[["t","Satoshi's idea eliminates the need for BitX. Alternative chains can be made without splitting CPU power.\n\nOur version of BitDNS would never use its own chain, though, because creating domains should not be tied to a proof-of-work, and we therefore have no generation incentive.\n\n120 bytes with an OP_CHECKSIG is enough for our proposal, I think."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28734#msg28734"},{"f":"RHorning","d":1291944190,"b":[["q","So if its possible to have a separate block chain and share the cpu power it seems like the issue is solved. Dont go pushing non financial transactions into one central block chain but let each application be a separate entity. If there are many different block chains it increases the chance of earning a block doesnt it?\n\nIts a simple elegant solution from satoshi.","Quote from: Anonymous on December 09, 2010, 10:23:37 PM"],["t","While I like the idea in general, it doesn't really solve the problem in terms of parallel currencies.  I don't think the idea of where the CPU power was going to come from for powering this network was ever an issue.  People who got into mining would go wherever the money was at and find solutions to \"earn\" whatever coins happen to be around.\n\nI do like the idea of pooling Bitcoin-like block chains in terms of attempting to \"earn\" hashes, and if there were more ways use CPU power to generate hashes it can only be beneficial to everybody involved.\n\nI still would like to use miners for \"authentication\" of the DomainCoin registrations in some way and I'm trying to come up with a good system to get that done.  By authentication I'm referring to basic \"rules\" that can verify that a domain hasn't been claimed, and a \"miner\" who doesn't follow those rules as accepted by the rest of the network gets that block rejected.  That is happening right now with Bitcion in regards to transactions, but doesn't happen with any other data and won't happen with other data at least as it is presented.\n\nIt still gets to the issue I presented earlier on another thread:"],["q","> Quote from: caveden on December 07, 2010, 10:21:41 PM\n> I agree with jgarzik, the chain should not be used as storage.\n>\n> If you want to create your own proof-of-work chain but would like to avoid double-work, you could make your parallel chain \"dependent\" on the bitcoin chain. Like, for creating a block in a dependent chain, you first have to create a block on the bitcoin chain and then use the private key you used to create that block to sign your new block on the dependent chain.\n\nI think I've asked this question a number of times getting the run around.  Perhaps I'll be more clear with this example as proposed by Caveden:\n\nIf you create this alternate \"proof of work\" chain (presumably to keep this junk out of the main Bitcoin financial traffic), how can you get those who are performing this work to be paid in Bitcions, based upon some fee system agreed to by the network running that proof of work chain?\n\nIf simply running that network is its own reward, it doesn't matter, but if there is going to be a fee involved for adding information into that proof of work chain, I don't see how that can be done without actually putting those block into the main Bitcoin chain, or setting up a completely parallel currency to Bitcoins.","Quote from: RHorning on December 08, 2010, 07:11:04 PM"],["t","This is an intractable problem if you want to include the data itself in an authenticated form in a chain block and have that chain block directly connected to Bitcoin without a parallel currency.  Theymos simply ignores the issue entirely with his protocol.... which is fine as far as that goes but a miner isn't really being paid to process domain registrations and certainly isn't authenticating bad registrations.  The real \"work\" in terms of a DNS system is to authenticate precisely who \"owns\" the domain and make sure that somebody else can't claim that domain.  The Theymos/Nanotube protocol forces authentication into a free good, and puts potential attacks on the protocol into the hands of the Bitcoin network... where I don't think it belongs either.\n\nI firmly believe that the data for domains must be in an authenticated system, preferably its own independent chain (perhaps linked to Bitcoin), where all of those serving this data can agree upon the same information and there is no ambiguity about the data.  Previous proposals that shove the data into the transactions of Bitcoins fail to get that accomplished."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28738#msg28738"},{"f":"ribuck","d":1291980212,"b":[["q","The incentive is to get the rewards from the extra side chains also for the same work.","Quote from: satoshi on December 09, 2010, 10:46:50 PM"],["t","You don't really get any extra reward. Either you are collecting generation fees + transaction fees from the Bitcoin side, plus some profits from the Domain Name side. Or, everything is in the Bitcoin block and you earn the same total profits, but all from the Bitcoin side (due to the additional Domain Name transaction fees on the Bitcoin side)."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28837#msg28837"},{"f":"ribuck","d":1291983694,"b":[["t","[edit: nevermind this post. I haven't been able to express my idea clearly here.]\n\nSuppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.\n\nTo register foo.domain, the buyer pays 10 BTC using the standard Bitcoin system, then goes to the other system to claim their domain name. But how to know that they paid? They can prove cryptographically that the 10 BTC payment came from them, but they can't prove that the payment was for a domain name. They might be using that same payment to claim services from several separate sites.\n\nSo obviously Bitcoin needs a way to associate a transaction ID with a Bitcoin payment. If you can include a transaction ID (of say 64 characters), then you may as well just use the Domain Name details as the transaction ID (because it's short enough), in which case there's no need for a separate domain name registration chain.\n\nA domain registration is just a Bitcoin Payment to an unspecified miner, with a transaction ID that happens to be meaningful."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28843#msg28843"},{"f":"bitcoinex","d":1291984140,"b":[["t","Introduction of BitX reduces the likelihood that will be invented a way to cut the chain?\n\nOr is it generally no longer considered a necessity?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28846#msg28846"},{"f":"RHorning","d":1291988367,"b":[["q","> Quote from: satoshi on December 09, 2010, 10:46:50 PM\n> If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.\nIn nanotube's+theymos's proposal, the real cost making a BitDNS is _automatically_ paid by the transaction fee, their is no need to create a second market.  As many or as little domains names will be included in the chain, and the generators will be compensated in bitcoins for providing that service.","Quote from: da2ce7 on December 10, 2010, 12:10:07 AM"],["t","The thing is that the miner receiving the transaction fee is just getting that as a sort of free lunch.  The fee may be in place to cut out spammers, but they aren't doing any work so far as anything to do with the DNS system.  Those computers which are processing and authenticating the raw data are not getting any sort of fee at all and the generators are not being compensated in Bitcions.  All that is happening is that the miners are getting paid essentially as a data storage service entirely, and that is of marginal utility in my opinion.\n\nThis is also why there are some huge complaints about using the Bitcion blockchain as a generic data storage system... rightfully so I might add."],["q","Suppose you have a separate block chain for domain name registrations, and you want people to pay in Bitcoins.","Quote from: ribuck on December 10, 2010, 12:21:34 PM"],["t","Let's assume for a minute we have another block chain which contains just domain data which is cryptographically hashed, but may or may not have proof of work (let's ignore that for now, which I'll address below).  The purpose of the block chain is for the authentication of the data primarily where the \"network\" of domain servers can \"certify\" that the data fits the network rules and that domain data within that chain is valid in terms of who \"owns\" what domain.  As a public block chain, it also shows what the majority of the \"network\" agrees ought to be in that chain too.  Improperly formatted data that is not agreed to by the majority of the network is rejected from this block.  Since it is a chain it also verifies against tampering and does a timestamp, and more importantly by being outside of the main Bitcoin chain it reduces the data payload for what is admittedly a specialized service which not all Bitcion users are necessarily interested in.  These are the features of the Bitcoin transaction database that are being desired to be applied to other sets of data.\n\nSo far that is the easy stuff.  We also want to set up some system where the \"registrar\" putting data into this chain is going to be \"paid\" for the registration and authentication of this system.  I emphasize this as this is both going to be a reason to be a registrar as to even exist as a registrar has a strong financial stake in maintaining the database to receive more registrations, and provides a reason to have fees to cut down on spamming domain names or abusing the public commons.  The fees are being paid to maintain the database, which is the important thing here.  Without this fee, at best this database is being authenticated and supplied to the world at large strictly as a public service for free.  Some people like that but I hope that those involved with the Bitcoin project can appreciate how being paid for such a service can be very useful and motivating.  The Theymos/Nanotube proposal and for that matter all registrations into the Bitcoin database through extra data in a transaction sidestep this issue entirely by ignoring authentication and only using the timestamp ability of Bitcoin, where this database would have to be built anyway but derived from Bitcoin and thus provided as a public service for free.\n\nHere is the real issue, however:  Since there is no central server, the registrant wants to make sure their registration is put in by whatever registrar happens to be in line to put in the next record onto the block chain, however that is decided (by proof of work or some other agreed upon system).  They want to send out some sort of generic transaction that can be received by the \"authenticator\" of their registration application who puts this registration into that block chain.  Only if their registration is accepted into the block chain should that authenticator be paid.\n\nA problem arises here:  A bitcoin miner may know that a fee is available from a registrant, but how do you decide where those coins properly belong?  Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute (it likely will happen just like it is happening with Bitcoin even now) those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block.  Some other registrar may pick up the registration and simply out of the kindness of their heart decide to include it in another block, but they won't be receiving any fee at all for that service.  Some system could be perhaps set up where after a block is down to a given depth in the block chain that the fee can be \"released\".  Still, regardless of how you set this up there will be some trolls who will be collecting fees, pretending to put stuff into the domain registry but not really caring about the domain registry protocols and siphoning off the fees for themselves, perhaps in collaboration with a Bitcoin miner.  Since this represents serious money, there will always be some trolls doing this.  Even an \"honest\" registrar is still going to make some mistakes due to a bug or something similar which may on occasion capture fees when they are deserved under this system.\n\nI believe the fee system is critical to the success of this domain registration system.  That ensures selfish behavior on the part of the registrars which puts it into their self-interest to maintain the databases, computer equipment, and everything else which makes this work.  Yes, there are other ways that a domain name server can earn some coins, and perhaps that ought to be done too, but registration fees are already a part of the marketplace and something which this system is trying to capture as well.\n\nIn short, I am trying to demonstrate here that the authentication simply must happen with an entirely different currency, or that authentication of the data (not merely the time stamping) must happen within the Bitcoin client and that data at least in some fashion or another included more directly into the Bitcion block chain with the data authenticated by the miner itself.  A Bitcoin miner may choose not to process domain data, but some system must be set up that can certify that a given block including the domain data meets some sort of authentication standard to be accepted into the block chain to \"earn\" those registration fees.  Otherwise the system falls apart and any talk of fees other than as a pure transaction fee to a Bitcoin miner alone is meaningless, with that transaction only to be used to preserve the transaction database.\n\nI am also suggesting that to ensure promptness of registration, that it may also have to be a separate currency simply because not all miners are going to want to bother with domain registration authentication and over time the latency of even getting a domain registration into the system may be intolerably long (on the order of days or weeks) depending on the setup of the Bitcoin network and other priorities of the miners.  I'm not suggesting an alternate currency to drive this project out of Bitcoin as useless data, but to point out that it is unworkable even from the perspective of the goals of the peer to peer domain server concept too.  Putting the data into transactions isn't authentication and is also losing much of the power of what Bitcoin offers in terms of the authentication too.  The proof of work system as used by Bitcion is also the only reasonable way to ensure that the system stays decentralized in terms of deciding who gets to put in the next block.  Certainly some sort of common protocol for finding the next proof of work hash can be set up through a common mining pool between multiple currencies like this, but that is a completely separate issue from if it is to be a separate currency or not which I don't think has been decided on this thread.\n\nThe only other solution would be for Bitcoin to fully embrace this and other similar concepts that might come along and provide hooks and some sort of standard protocol to authenticate data of this nature on the main Bitcoin network.  I think in theory that could be done and may be done in the more distant future in terms of \"unifying\" the proliferation of currencies that may result if it isn't done.  I just don't see how that is going to get into the main Bitcoin chain anytime soon and even that has a whole bunch of drawbacks which I haven't fully explored either."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28857#msg28857"},{"f":"bitcoinex","d":1291992099,"b":[["t","I have not yet read all the posts but I have a few thoughts:\n\nNeed to divide the creation of a domain name and change of authoritative servers for him:\nFirst is the expenditure limited domain name space and must be expensive.\nSecond only settings that can be changed frequently and should be generated in large quantities and cost little.\n\nNames should be allowed to specify the relative and absolute value (with dot at the end). Absolute in case the system will supplement or replace the main in the conventional TLD.\n\nAlso names should be allowed to specify 3rd or more level domain names too."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28873#msg28873"},{"f":"bitcoinex","d":1291992710,"b":[["q","> Quote from: Anonymous on December 06, 2010, 11:53:37 AM\n> I suggest tahoe lafs if you are looking for a database for storage.\n\nRemember, speed is of the essence. We can alway replace the database with something else, but not time.\n\nAll non-essential features should be blocked from implementation focus.\n\nThat mean the core developers don't work on a fancy GUI. They will focus on:\n\n1. The mechanism to mine, register, and change a domain name.\n\n2. The mechanism to distribute or output the DNS database.","Quote from: kiba on December 06, 2010, 01:12:33 PM"],["t","2. \"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28876#msg28876"},{"f":"ribuck","d":1291993057,"b":[["q","... Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block","Quote from: RHorning on December 10, 2010, 01:39:27 PM"],["t","That doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the \"winning\" chain gets the transaction fee.\n\nThere is no \"irreversible\" payment to the generator in the \"losing\" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28877#msg28877"},{"f":"ribuck","d":1291993167,"b":[["q","\"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it.","Quote from: bitcoinex on December 10, 2010, 02:51:50 PM"],["t","No-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28878#msg28878"},{"f":"ribuck","d":1291993300,"b":[["t","I have fleshed out the DomainChain spec quite a bit more:\nhttp://domainchain.org/wiki/doku.php?id=start"],["q","Also names should be allowed to specify 3rd or more level domain names too.","Quote from: bitcoinex on December 10, 2010, 02:41:39 PM"],["t","Yep, that's in the spec. But it's only useful if you know that someone is going to serve them. For example, the owner of some.domain might announce that they will serve any subdomain that people register of the form something.some.domain"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28879#msg28879"},{"f":"bitcoinex","d":1291993881,"b":[["q","> Quote from: bitcoinex on December 10, 2010, 02:51:50 PM\n> \"powerdns\" can work with plugins and with bind9 configs by default. We can write a plugin for it.\n\nNo-one has made a proof-of-concept, but we think that all we need is a program that trawls through the block chain, extracts the registration details, and writes them out in bind's data format. No plugin or hacks should be needed.","Quote from: ribuck on December 10, 2010, 02:59:27 PM"],["t","bind9 is not the best format. pdns have a simple interface for plugins, do not worry."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28881#msg28881"},{"f":"RHorning","d":1291999801,"b":[["q","> Quote from: RHorning on December 10, 2010, 01:39:27 PM\n> ... Keep in mind that once a fee is processed in Bitcoin, it is irreversible.  If there is a chain split on the domain records due to a formatting/authentication dispute ... those Bitcoin transactions may be going to an authenticator who in fact never did get the registration done because the majority of the network has ignored that domain registration block\n\nThat doesn't really reflect how it works. If there is a chain split, eventually the network will settle on one of the chains. The generator that mined the block in the \"winning\" chain gets the transaction fee.\n\nThere is no \"irreversible\" payment to the generator in the \"losing\" chain. Well, in a sense it is irreversible but as they can only spend it in the losing chain it's not much use to them.","Quote from: ribuck on December 10, 2010, 02:57:37 PM"],["t","I think you got the context mixed up here.  The reason why the payment is irreversible is because it is derived from a completely different chain.  If there is a chain split in the domain registry chain, the fees spent as bitcoins (going into a completely different system) will have already been spent for those block in the \"losing\" chain.  Transaction going into that \"losing block\" are essentially a wasted effort.\n\nI'm suggesting that somebody simply sets up enough of the protocol to be able to appear to be following the domain processing rules so as to appear \"legit\", but they only have to make an appearance to get a block accepted.  Perhaps they even get some blocks accepted, but then start to make up stuff or somebody attempts to register an existing name (as a scammer claiming they can hijack a domain from somebody else or however).  If there is any reason why the rest of the network doesn't accept the block, for any reason, all of the fees collected by that \"miner\" or \"registrar\" would still be collected by that scammer regardless of if it actually gets into the chain.\n\nOn the other hand, if the block being \"authenticated\" is a part of the same chain that creates the currency, this isn't a problem.  If the blocks get rejected by the network, any fees (set up in a system like how transaction fees are done with Bitcoin) are also similarly rejected by the network too.  Any chain splits remove any fees paid to \"losing\" blocks and therefore can be ignored.  This is why the authentication must happen in the same chain as the transaction.  Either that is in Bitcoin or a parallel currency, but if it is with Bitcoin, the authentication must happen within the Bitcoin network too.  Otherwise, there isn't a way to get payment to the miner with an outside currency that is similar to Bitcoin without fraud and a significant attack on the payment system.  This is fraud because a service is being claimed and paid for, but the service isn't being rendered.\n\nHacking the data into Bitcoin transactions does not perform authentication of the data and pushes that need somewhere else.  In effect, it permits \"double spending\" of a domain name or allocation of a domain name to more than one person with ambiguity over who actually owns that domain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28899#msg28899"},{"f":"ribuck","d":1292000295,"b":[["q","The reason why the payment is irreversible is because it is derived from a completely different chain.","Quote from: RHorning on December 10, 2010, 04:50:01 PM"],["t","Got you now. Yes, keeping two chains synchronised is fraught with difficulty."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28904#msg28904"},{"f":"satoshi","d":1292002168,"b":[["t","Piling every proof-of-work quorum system in the world into one dataset doesn't scale.\n\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.\n\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.\n\nFears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917","s":1,"n":535,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/535/"},{"f":"ribuck","d":1292007335,"b":[["q","Piling every proof-of-work quorum system in the world into one dataset doesn't scale.","Quote from: satoshi on December 10, 2010, 05:29:28 PM"],["t","If you say \"no\" after you've seen how this runs on the test network, I will totally respect that and won't generate domain registrations on the live network.\n\nBitcoin is your bird, and if you don't want it to soar as high as it can, that's OK.\n\nBut even if the domain name stuff is on a separate chain, there is still going to be a Bitcoin transaction for every DNS registration. So having two chains would cause no reduction in the number of Bitcoin transactions, just 40 or 50 bytes reduction in the size of the transactions in the Bitcoin chain."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28935#msg28935"},{"f":"RHorning","d":1292007804,"b":[["q","Fears about securely buying domains with Bitcoins are a red herring.  It's easy to trade Bitcoins for other non-repudiable commodities.","Quote from: satoshi on December 10, 2010, 05:29:28 PM"],["t","I dont see how this was a red herring.  Unfortuantely if you use a Bitcoin-like system of authentication of a transaction, you can't conduct that transaction in Bitcoins, at least for authentication transaction fees."],["q","If 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.","Quote"],["t","I'm really curious about how you make this sort of transaction risk-free without having it integral to Bitcoin as some sort of authentication mechanism.\n\nOne thing that really makes this nasty is that the \"miner\" is unknown until the block is added into an authentication hash tree.  You don't have the two key release mechanism because one of the parties in the transaction is unknown until after the hash is successfully put in, and even that is conditional.\n\nIt makes it much more secure and coincidentally easier to scale to treat it as a simple exchange between two currencies, something that happens entirely outside of the system as evidenced by the various exchanges that already exist between Bitcoin and other currencies.  BTW, I agree that Bitcoin or any other monolithic application should not be the ultimate repository of all human knowledge and interaction, as I don't think any sort of system can possibly scale to that size.  I'm not even sure TCP/IP itself can scale to that size.\n\nThis is much of what Jgarzik has said that it is unworkable, but going from a different perspective.  The problem is that everybody is trying to get these fees paid for with bitcoins, and I don't think that can be done at all, at least directly.  As an indirect mechanism, perhaps, such as a floating currency that isn't locked down until after the exchange takes place.\n\nBTW, the idea of a \"locking exchange\" would be a fantastic idea for a peer-to-peer currency exchange network, particularly for electronic currencies like Bitcoin or Liberty Reserve.  I just don't see how you can put any sort of authentication transaction fee in a block that is denominated by a currency other than the currency represented by that block itself."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28936#msg28936"},{"f":"MoonShadow","d":1292008288,"b":[["t","Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28937#msg28937"},{"f":"Hal","d":1292008444,"b":[["t","Satoshi, are you endorsing the idea that 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?"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28938#msg28938"},{"f":"RHorning","d":1292008844,"b":[["q","Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.","Quote from: creighto on December 10, 2010, 07:11:28 PM"],["t","This is indeed something that can be tweaked, but the issue has to do with network latency, which is independent of the purpose for which the \"currency\" was created.  10 minutes is a guess that has worked out pretty well.  Yes, it could be longer or shorter.  Shorter intervals increase hash collisions from multiple \"miners\" and a longer intervals decrease those collisions.  10 minutes is also something tolerable on average to somebody used to using computers, certainly if you have experienced sending information and expecting a reply by e-mail.  Domain registrations in particular may take a day or so for processing, depending on the registrar and the method of payment, so anything less than a 10 minute interval seems like a waste of effort.\n\nIn short, the reasons why 10 minute intervals would apply to Bitcoin apply equally well to any other peer-to-peer cryptocurrency with what other applications are using similar principles."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28946#msg28946"},{"f":"jgarzik","d":1292008960,"b":[["q","Satoshi, are you endorsing the idea that 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?","Quote from: Hal on December 10, 2010, 07:14:04 PM"],["t","It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.\n\nThe possibilities are endless.\n\nBitcoin rewards you, essentially, with a piece of [digital] property."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28949#msg28949"},{"f":"RHorning","d":1292009748,"b":[["q","It might be coins, but it doesn't have to be.  Your reward could be a portion of namespace, ie. the domains themselves.\n\nThe possibilities are endless.\n\nBitcoin rewards you, essentially, with a piece of [digital] property.","Quote from: jgarzik on December 10, 2010, 07:22:40 PM"],["t","If you are a miner and you \"win\" the block, yes, you can throw in any domains to the chain for free I suppose, and the network could accept or reject your block depending on whatever rules that network sets up to regulate that behavior.  That is like a Bitcoin miner can throw any transactions they care for as much as they care without having to pay a transaction fee, since they are paying for themselves.  Including a transaction fee in the process is just rearranging coins and doesn't change the net amount actually being spent or received.\n\nI think that is of limited utility, unless you are saying that miners can eventually \"earn\" the \"right\" to a top-level domain after a certain number of hashes and inclusions into the domain registry.  That would be an artificial form of scarcity that would be interesting to implement, but it still fails to get fees paid by registrants to the registrar.  It would just make you \"god-king\" over a particular TLD... if you really \"owned\" that.\n\nSuch a non-coin \"reward\" also doesn't provide any incentive to maintain the database, while a coin-based reward would."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28955#msg28955"},{"f":"jgarzik","d":1292010101,"b":[["t","bitcoin itself is artificial scarcity."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28956#msg28956"},{"f":"satoshi","d":1292010912,"b":[["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?","Quote from: Hal on December 10, 2010, 07:14:04 PM"],["t","Right, the exchange rate between domains and bitcoins would float.\n\nA longer interval than 10 minutes would be appropriate for BitDNS.\n\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:\n\nChanging the IP record.\n\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.  \n\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."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28959#msg28959","s":1,"n":537,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/537/"},{"f":"kiba","d":1292011394,"b":[["q","bitcoin itself is artificial scarcity.","Quote from: jgarzik on December 10, 2010, 07:41:41 PM"],["t","The supply of bitcoin is just an integer determined by network. Otherwise, bitcoin are non-scarce. I can copy a wallet a millllllllllllioooooooooon of time and it will contain the same integer. It's a very weird form of scarcity and non-scarcity."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28961#msg28961"},{"f":"Hal","d":1292011922,"b":[["t","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.\n\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\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.)"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28962#msg28962"},{"f":"satoshi","d":1292012379,"b":[["t","I agree.  All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28963#msg28963","s":1,"n":538,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/538/"},{"f":"bitcoinex","d":1292013705,"b":[["q","Also, why on Earth would a BitDNS want a blockchain that updates every 10 minutes?  Why not an hour instead?  Or every minute?  Why be chained to the cycles set for another purpose?  It's less than ideal from the beginning.","Quote from: creighto on December 10, 2010, 07:11:28 PM"],["t","Then be sure to add the ability to specify multiple authoritative servers for one domain. This is possible for DNS as I know (MS Windows AD does it)\n\nSo those who do not want what their site to be able to shutdown can make a lot of spare servers and when they turned off by Big Brother name owner just change the settings by removing old servers and adding new ones."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg28973#msg28973"},{"f":"da2ce7","d":1292025660,"b":[["t","It seems like killing two birds with one stone isn’t enough on the bitcoin forum; one has to kill three.\n\nFirstly, I would like to commend nanotube's+theymos proposal.  I like it because it makes economic sense, and it is simple.\nThe design that I am proposing in this post is backwards compatible with nanotube's+theymos proposal, however solves all the ‘issues’ said. (I still think there is really nothing wrong about how it is proposed to work as it is.  However, if there is a better way of doing it, why not?)\n\nBefore we start, one must state that domain names a fundamentally different to currency, as they obtain their value in a very different manner; currency obtains values from being something that has restricted supply.  Domain names, rather have values from the quality of the name, i.e. a short dictionary word has more value that a long random sequence.\n\nIf a restriction of the total number of domain names is made, it would be an arbitrary restriction, causing a lower efficiency market, thus reducing the attractiveness of using that market.\nSo with this in mind, lets design a system that can have an unlimited number of domain names; providing people are willing to pay for the service of claiming the domain name.\n\nThe main concern on the forum is the inclusion of ‘other data’ in the block chain; the problem isn’t a fundamental one, as the bitcoin transactions block chain is indeed data in its own right.\nIn discussions elsewhere, it has been shown that:\n1.   Generators will happily include any data that is profitable to include.\n2.   The block size will grow to a size that balances data demands and the profitably of the miners.\n3.   Clients only need to ‘keep’ data that they interested in.  Data that is irrelevant to the client may be forgotten once processed.\n4.   Transaction balances may be used to cull the chain of old transactions.\nTherefore it has already been shown that the amount of data in the chain is not an issue with: generation (they get paid for it), or storage (they only keep what they want).  The only outstanding issue is: transfers.\n\nWhat has been discussed is that every client must download the entire block chain (before it is culled) then, every new block generated and check it.  Only after processing may a client delete any data that it doesn’t want.  This accounts for a small amount of work while the chain is small, however the fear is when large amounts of irrelevant data (to any particular client) is included in the chain this task will become overly taxing.\n\nI propose, a design hinted at by Satoshi, to solve this problem:  Split bitcoin transactions into multiple groups.\nWhile keeping the important tie between data and bitcoin transactions, (every bit of data still must include it’s compensation to the miners as a bitcoin transaction fee).\nGroup the transactions by templates.  For example:  Put the ‘vanilla template’ bitcoin transactions into the vanilla group, the ‘bitdns template’ bitcoin transactions into the bitdns group, the ‘bitpgp template’ bitcoin transactions into the bitpgp group, and so on.\n\nFinally include a ‘summary’ group that contains only the changes to the transaction balances accumulated in all the other groups.\n\nA Block could contain something like this:\n\nOnce one block has confirmed the previous block (checking that all the accounting is correct in the summary block), only downloading the merkle tree and the summary group is required to keep up2date about the changes.  This is in-effect less data than is required to download now! If the client decides that it needs some in-particular bit of data from one of the other groups after checking the summary, it can optionally download that also.\n\nThe important thing to notice is it that there is no free lunch, every bit of data must still include the appropriate transaction fees, in bitcoins.\n\nNanotube and Teymos’s design fits very nicely on top of this design, as the transactions that the BitDNS system makes will simply be automatically grouped by the template that the generators use to check the BitDNS transactions before accepting them. Allowing clients to download the BitDNS data if they want it, or just download the transaction summaries."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29033#msg29033"},{"f":"dtvan","d":1292053388,"b":[["t","After reading through this whole thread, I've got a couple of comments that I think would be helpful:\n\n1)  Everyone in the thread seems intent on replacing the entire DNS infrastructure in one fell swoop, which I think is the wrong approach.  The real problem with the DNS system as it exists today is that somebody has to own the root.  At the end of the day, you have to trust ICANN.  What the DomainChain/BitDNS system should strictly focus on is establishing ownership of domain names.  All it needs to track is that the holder of Key A owns domain foo.bar.  Once we've established this shared trust, we can support many different DNS infrastructures that can be implemented independently from this project.  Whatever new systems are created use DomainChain/BitDNS to establish which key owns the domain, and only allows that individual to insert records for that domain.  This works out well, since all participants in the system can validate that the record they've looked up is valid.  Right now it is easy to get bogged down in all the details of managing DNS records, when all we need to do is establish a trusted, distributed authority that can form the root of DNSSEC, some new p2p DNS, or whatever.\n\nI'm also thinking this could be used to solve the CA problem with HTTPS, since signing your certificate with the same key would prove that I've reached the correct server.  But I digress...\n\n2)  Limiting the TLDs should be a requirement.  If this system doesn't inter-operate with the existing DNS infrastructure by preventing name collisions, it will undermine the trust you are trying to generate.  Even I'm not sure I'm ready to sign up for a distributed DNS system if someone new can pick up www.mylocalbank.com <http://www.mylocalbank.com> and cause havok.  I'd humbly suggest .web as the TLD to use, but anything will work as long as it is short and not currently in use.\n\nRight now the focus should be on getting this up and running in a way that doesn't conflict with the existing system.  If this system becomes dominant at some point and needs to tackle additional TLDs, that is a \"problem\" that can be dealt with then.\n\n3)  Personally, I think expiring domain names are the way to go.  Even with relatively expensive renewals today, there is still a ton of junk out there.  I can't imagine how bad it would be if you owned a domain forever.  It isn't asking much to say that you have to renew your domain periodically to keep it, especially since this shouldn't be the ripoff that the existing system is today.\n\nI'd like to close out by saying that this is really exciting stuff.  I've read a number of different ideas about how to solve the DNS problem, and this is the first one I've seen that could actually solve it (and not just replace ICANN with pick-your-new-benevolent-dictator)."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29108#msg29108"},{"f":"joe","d":1292064838,"b":[["t","What is Bitcoin? A decentralized way to keep track of ownership of a fixed quantity of things.\n\nThe DNS problem is a specific example of a more general functionality: keeping track of ownership of a fixed quantity of things, where each member of the set is distinguishable.\n\nIt turns out that bitcoins are already distinguishable. They are well ordered, mathematically speaking, so a number can be assigned to every bitcoin, for example 0 to 21 million.\n\nSo, for a DNS functionality, this is all we need to do:\n1. create a second coinbase, possibly forked from the main coinbase (bitcoin)\n2. interpret each coin in the second coinbase as a well-defined interval of the sha256 hash space of all DNS names.\n\nOwnership of DNS names is therefore determined by which coins in the second coinbase you own.\n\nSome months ago I was opposed to adding DNS stuff to the existing bitcoin network protocol and client, because I argued bitcoin should stay true to its limited purpose. 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.\n\nIn fact, maybe anyone should be able to create a new coinbase on the main network, and specify rules such as quantity and distribution rate. In the case of DNS, everyone will just have to agree that a particular coinbase is to be interpreted as the DNS rights to different parts of the sha256 hash space for the DNS names.\n\nI agree with the idea put forth by da2ce7, which he says is derived from an idea put forth by Satoshi. I think it is compatible with my idea of allowing arbitrary creation of new coinbases on the same network.\n\nI cannot find the nanotube+theymos proposal so i cannot comment on it."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29130#msg29130"},{"f":"ribuck","d":1292067924,"b":[["q","I cannot find the nanotube+theymos proposal","Quote from: joe on December 11, 2010, 10:53:58 AM"],["t","It's here <http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal>. The simpler DomainChain proposal is here <http://domainchain.org/wiki/doku.php?id=start>."]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29136#msg29136"},{"f":"Anonymous","d":1292068111,"b":[["q","It seems like killing two birds...","Quote from: da2ce7 on December 11, 2010, 12:01:00 AM"],["t","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. "]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29137#msg29137"},{"f":"satoshi","d":1292072910,"b":[["t","@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."],["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.","Quote from: joe on December 11, 2010, 10:53:58 AM"],["t","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"]],"u":"https://bitcointalk.org/index.php?topic=1790.msg29159#msg29159","s":1,"n":539,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/539/"}]},{"id":"p245","k":"p","s":"bitcointalk","t":"Transaction / spam flood attack currently under way","u":"https://bitcointalk.org/index.php?topic=1850","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/245/","m":[{"f":"jgarzik","d":1290193358,"b":[["t","Someone is apparently \"testing\" the main bitcoin network by flooding it with 0.01 BTC transactions from A->A and B->B, where A and B are two random public keys.  You can watch at http://theymos.ath.cx:64150/bbe\n\nWe've hit the free transaction limit on each block, for many blocks now -- appears to be ~219 free transactions per block.  \"real\" transactions do not appear DoS'd at this time, presumably due to logic that prioritizes, in part, based on transaction value.\n\n<soapbox>\nFree TX's are just asking for permanent level of spam.  There should be a cost to each TX, even if it's only 0.001 BTC or so.\n</soapbox>"]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22870#msg22870"},{"f":"FreeMoney","d":1290193521,"b":[["t","http://bitcointalk.org/index.php?topic=1842.0"]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22873#msg22873"},{"f":"jgarzik","d":1290194009,"b":[["t","I'm not so ready to blame this on MrBurns."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22874#msg22874"},{"f":"FreeMoney","d":1290195066,"b":[["q","I'm not so ready to blame this on MrBurns.","Quote from: jgarzik on November 19, 2010, 07:13:29 PM"],["t","Oh, right he did it earlier for sure, same address I sent the coins to. I assume he split it up and is now using multiple computers.\n\nGo back about 1 day and you can see a bunch of .06 trades to and from the address MrBurns put in his thread."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22878#msg22878"},{"f":"ByteCoin","d":1290196444,"b":[["t","The .06 in 17yhRAYKJvVmBh14HMxYRHp2Z4erWgk1ne which was MrBurns old spam eventually was transferred to 1GcbuFVxrjstRoGzChn5t2xJnm2HKoDBSE 0.05 and\n15JzKgaSoW5nX3qJKh6ze1uCojn9WVVnDE 0.01\nin transaction c37dd025e8b7329989ab9ac378604d015895e4ec630c863620a90f3a12f73e76\nin block 92767 (2010-11-18 22:51:36)\n\nIt got 0.05 back from 1GcbuFVxrjstRoGzChn5t2xJnm2HKoDBSE in block 92767\nwhich was transferred to 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp in 92875\n\nThere has been a lot of spamming with 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp but also with\n1NNVFX7SiJF44fkqB27QbARXojhRSotF2o which was created from 14mUbjiofYY2F6h3ZGUSoTo3kxdqtajVTp\nvia 1H2aPofjULC65MBeojs3eVpPvdScV8H9ou\nin block  92877 (2010-11-19 15:12:33)\n\nSo it's the same person.\n\nByteCoin"]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22885#msg22885"},{"f":"jgarzik","d":1290196564,"b":[["t","That's a good point about fee competition, but I'm wondering about near-term implications of this spam flood, too, like\n\n• What happens to the transactions that don't make it into the current block?  (somewhat rhetorical question... the answer is \"they keep piling up in memory\" AFAICS, but that raises a bigger question -- how to deal with ever-larger TX cache?)\n\n• Will this create a de facto situation where TX fee is required for \"normal\" bitcoin users?\n\n• Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22888#msg22888"},{"f":"theymos","d":1290197250,"b":[["q","What happens to the transactions that don't make it into the current block?","Quote from: jgarzik on November 19, 2010, 07:56:04 PM"],["t","The network forgets about them over time. Queued transactions are forgotten when Bitcoin shuts down (or when it crashes because it's using too much memory...). The attacker probably won't rebroadcast their spam transactions, but real users will."],["q","Will this create a de facto situation where TX fee is required for \"normal\" bitcoin users?","Quote"],["t","Yes. This has always been inevitable."],["q","Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses.","Quote"],["t","This would be easy to bypass unless you also follow a transaction's history, and if you do that the attacker can \"infect\" people by sending them bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22890#msg22890"},{"f":"FreeMoney","d":1290197494,"b":[["q","...","Quote from: nanotube on November 19, 2010, 07:39:14 PM"],["t","Oh, I agree. Well, I'm not going to praise him, we were already aware of the possibility. Apparently, \"no incentive\" isn't good enough and we need an actual cost of some sort. Well... actually there is some tiny cost to him, so I guess we need a little bit bigger cost. An increasing marginal cost really would be good.\n\nI mentioned a minimum required [age]*[size] could be required by miners in the other thread. Maybe with a portion (10-20 transactions?) with no requirement."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22892#msg22892"},{"f":"FreeMoney","d":1290197542,"b":[["t","MrBurns is probably just checking to see what happens before he buys 100,000 coins."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22893#msg22893"},{"f":"MoonShadow","d":1290198552,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896"},{"f":"Timo Y","d":1290198614,"b":[["t","In a free market for transaction fees,\nspamming the network will have the effect of increasing transaction fees for everybody.\n\nMaybe Mr Burns is more than just a common griefer. Maybe he is a miner with more rational motivations.\n\nA miner has more to gain than to lose by spamming. Yes, eventually a spam equilibrium will be reached where the marginal amount you lose in your spam to the transaction fees of competing miners equals the marginal amount gained from your own transaction fees.  But that is still a macroeconomically subobtimal situation.\n\nTo escape this http://en.wikipedia.org/wiki/Social_trap social trap, more than a market is needed.\n\nSome simple but effective rules should be hardcoded into the Bitcion protocol/specification itself, to discourage the excesses of spamming.\n\nI know that this approach probably sounds too \"top-down\" for the free market enthusiasts in this forum, but the rules should of course be purely voluntary and consensus based, like the 21M rule we have already."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22897#msg22897"},{"f":"MoonShadow","d":1290199419,"b":[["q","> Quote from: creighto on November 19, 2010, 08:29:12 PM\n> 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.\n\nThat could make people get tied up in their funds again. Think MtGox or even the bitcoin faucet. Faucet can only send out a nickel every 3 blocks, because each time it sends a nickel, it sends the change to a new address, tying up transaction fee free for 3 blocks.","Quote from: davidonpda on November 19, 2010, 08:35:15 PM"],["t","Only a little.  If the rule is generally known, and the reason for it, I think that those like the bitcoin faucet could adjust.  I'm talking about limiting based upon the coins movement, if that's possible, not a three block ban upon a particular address.  The new client has 100 addresses, correct?  If bitcoin faucet has more than BTC .05 in each address, and simply rotates the addresses as the requests come it, then it can service 100 requests in half an hour without delay, and more with delays.  I'm not saying that transactions can't be created, just that generators will not put them into blocks until the transaction that they depend upon is three blocks deep without a fee.  With a fee, they can do whatever they want; and the generators probably wouldn't honor a 3 block delay upon a fee paying transaction anyway.  This leaves the possibility of free transactions an open possibility, while inhibiting spamming.  If there is a technical reason that this rule cannot work, I wouldn't know about that.\n\nEDIT:  Markets that are trying to service withdraw requests would know how many requests have been sent in the previous 30 minutes, and could choose to warn the requester that such requests may be delayed by this rule, or they can choose to pay a fee out of it."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22903#msg22903"},{"f":"satoshi","d":1290210624,"b":[["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.","Quote from: creighto on November 19, 2010, 08:29:12 PM"],["t","I'm doing something like that.  Priority is a more formalised version of the concept you're describing."],["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 ?\n\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.","Quote from: FreeMoney on November 19, 2010, 05:39:44 PM"],["t","Yes, like this.  And the no-priority-requirement area is 3K, about a dozen transactions per block.\n\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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952","s":1,"n":505,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/505/"}]},{"id":"p246","k":"p","s":"bitcointalk","t":"New getwork","u":"https://bitcointalk.org/index.php?topic=1901","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/246/","m":[{"f":"satoshi","d":1290541812,"b":[["t","I uploaded a redesign of m0mchil's getwork to SVN rev 189 (version 31601)\n\nm0mchil's external bitcoin miner idea has solved a lot of problems.  GPU programming is immature and hard to compile, and I didn't want to add additional dependencies to the build.  getwork allows these problems to be solved separately, with different programs for different hardware and OSes.  It's also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.\n\nThe interface has a few changes:\n\ngetwork [data]\nIf [data] is not specified, returns formatted hash data to work on:\n  \"midstate\" : precomputed hash state after hashing the first half of the data\n  \"data\" : block data\n  \"hash1\" : formatted hash buffer for second hash\n  \"target\" : little endian hash target\nIf [data] is specified, tries to solve the block and returns true if it was successful.  [data] is the same 128 byte block data that was returned in the \"data\" field, but with the nonce changed.\n\nNotes:\n- It does not return work when you submit a possible hit, only when called without parameter.\n- The block field has been separated into data and hash1.\n- data is 128 bytes, which includes the first half that's already hashed by midstate.\n- hash1 is always the same, but included for convenience.\n- Logging of \"ThreadRPCServer method=getwork\" is disabled, it would be too much junk in the log."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23876#msg23876","s":1,"n":507,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/507/"},{"f":"wumpus","d":1290543080,"b":[["t","Nice, that will save a lot of patching Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23882#msg23882"},{"f":"davout","d":1290544954,"b":[["t","That's really nice.\nWill it be a drop-in replacement a patched client already used by GPU miners ?"]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23889#msg23889"},{"f":"nelisky","d":1290545032,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23890#msg23890"},{"f":"satoshi","d":1290545727,"b":[["t","It's not an exact drop-in replacement.  I wanted to clean up the interface a little.  It only requires a few changes.\n\nScanHash_ functions aren't going away.  BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1)."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891","s":1,"n":508,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/508/"},{"f":"davout","d":1290551947,"b":[["t","Btw satoshi, you should give a shot at git, it's so much better than svn, especially with lots of patches and forks going around =)"]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23917#msg23917"},{"f":"jgarzik","d":1290552365,"b":[["t","Fantastic stuff, this eliminates one of my patches completely.\n\nI am also tempted to work on an external CPU miner..."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg23920#msg23920"},{"f":"jgarzik","d":1290574062,"b":[["t","Just started working on a simple CPU miner in C, mainly as a demonstration, and to understand 'getwork'.\n\nRepository is at git://github.com/jgarzik/cpuminer.git\n\nImplementation is complete... but it does not work, so don't get too excited.  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."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008"},{"f":"DiabloD3","d":1290598271,"b":[["t","Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification"]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050"},{"f":"m0mchil","d":1290599794,"b":[["t","No need to do this, I'll change the miner to comply. I am just a little busy right now."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24053#msg24053"},{"f":"satoshi","d":1290619261,"b":[["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.","Quote from: jgarzik on November 24, 2010, 04:47:42 AM"],["t","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.\n\nI should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they're consistent.\n\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]."],["q","Satoshi, please fix your implementation of getwork so it complies with m0mchill's specification","Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM"],["t","This is the new spec.  It shouldn't be hard to update your miner to use it.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095","s":1,"n":509,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/509/"},{"f":"jgarzik","d":1290645994,"b":[["t","Figured out the problem.  My sha256 algo was byteswapping the input into big endian, when it was already big endian.\n\nFirst version of this new CPU miner now described here:  http://bitcointalk.org/index.php?topic=1925.0"]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24218#msg24218"},{"f":"DiabloD3","d":1290806227,"b":[["q","- It does not return work when you submit a possible hit, only when called without parameter.","Quote from: satoshi on November 24, 2010, 05:21:01 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24701#msg24701"},{"f":"satoshi","d":1290807073,"b":[["t","That's what it does, it returns true/false."]],"u":"https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708","s":1,"n":515,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/515/"}]},{"id":"p247","k":"p","s":"bitcointalk","t":"New demonstration CPU miner available","u":"https://bitcointalk.org/index.php?topic=1925","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/247/","m":[{"f":"jgarzik","d":1290645923,"b":[["t","A new CPU miner is now available, making use of the new 'getwork' RPC command.\n\nIn the beginning, this is intended largely to demonstrate a 'getwork' miner.  It is written in straight C, with minimal dependencies (libcurl, jansson).\n\nIt has successfully generated blocks on testnet, mainnet and almost all pools.\n\nLinux/BSD release tarball: http://yyz.us/bitcoin/cpuminer-1.0.2.tar.gz\nWindows installer: http://yyz.us/bitcoin/cpuminer-installer-1.0.2.zip\ngit repository: git://github.com/jgarzik/cpuminer.git\n\nContributions welcomed!  (GPL v2 license)\n\nUPDATE:  This has largely been superceded by Con Kolivas's cgminer fork <http://forum.bitcoin.org/index.php?topic=28402.0>.  See cgminer's official forum thread <http://forum.bitcoin.org/index.php?topic=28402.0> for updates and details."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24217#msg24217"},{"f":"slush","d":1290651257,"b":[["q","In the beginning, this is intended largely to demonstrate a 'getwork' miner.  It is written in straight C, with minimal dependencies (libcurl, libcrypto, jansson).","Quote from: jgarzik on November 25, 2010, 12:45:23 AM"],["t","Cool, I like simplicity of your code. I want to try similar implementation in javascript. Partially because of curiosity and partialy because (inspired by hashcash) it can generate few hashes by fighting comments spam :-).\n\nI just made few tests. In four javascript threads I get ~4khash/s, which is EXTREMELY slow. Probably because javascript is interpreted and without any JIT yet. Would be great if javascript supports GPU. Flash will support GPU soon, so we will see Wink."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24236#msg24236"},{"f":"sturle","d":1290691725,"b":[["q","> Quote from: jgarzik on November 25, 2010, 12:45:23 AM\n> In the beginning, this is intended largely to demonstrate a 'getwork' miner.  It is written in straight C, with minimal dependencies (libcurl, libcrypto, jansson).\nCool, I like simplicity of your code. I want to try similar implementation in javascript. Partially because of curiosity and partialy because (inspired by hashcash) it can generate few hashes by fighting comments spam :-).\n\nI just made few tests. In four javascript threads I get ~4khash/s, which is EXTREMELY slow. Probably because javascript is interpreted and without any JIT yet. Would be great if javascript supports GPU. Flash will support GPU soon, so we will see Wink.","Quote from: slush on November 25, 2010, 02:14:17 AM"],["t","Is your JavaScript code available?\n\nI wish the getwork RPC command could be allowed for non-authenticated users from other hosts.  It isn't revealing any secret information, is it?"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24350#msg24350"},{"f":"wumpus","d":1290692045,"b":[["t","Nice idea on the independent C miner.\n\nOn the JS one: Oh no, soon all kinds of websites will be sneakily generating bitcons on the background while you browse them, hogging your CPU even more Tongue"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24351#msg24351"},{"f":"slush","d":1290696800,"b":[["q","Is your JavaScript code available?\n\nI wish the getwork RPC command could be allowed for non-authenticated users from other hosts.  It isn't revealing any secret information, is it?","Quote from: sturle on November 25, 2010, 01:28:45 PM"],["t","Will be available if I finish that. It is just for curiosity because it will be slow as hell. Also network overhead will be significant.\n\nI expect simple PHP proxy will do good work for hiding credentials to client. something like yourdomain.com/getwork.php which call rpc to localhost and return json encoded data."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24374#msg24374"},{"f":"wumpus","d":1290697166,"b":[["q","Will be available if I finish that. It is just for curiosity because it will be slow as hell. Also network overhead will be significant.","Quote from: slush on November 25, 2010, 02:53:20 PM"],["t","I believe that IE has cryptographic extensions that you can use from javascript. Maybe that will speed it up?"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24376#msg24376"},{"f":"slush","d":1290703650,"b":[["q","I believe that IE has cryptographic extensions that you can use from javascript. Maybe that will speed it up?","Quote from: witchspace on November 25, 2010, 02:59:26 PM"],["t"," Do you have any link or reference? I found only 3rd party ActiveX component here http://www.chilkatsoft.com/js-sha512-hash.asp."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24417#msg24417"},{"f":"teknohog","d":1290778899,"b":[["t","Should I use a particular version of jansson? I installed it from git, and get the following compile error:"],["c","util.c: In function ‘json_rpc_call’:\nutil.c:133:2: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast\n/usr/local/include/jansson.h:188:9: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’\nutil.c:133:2: error: too few arguments to function ‘json_loads’\n/usr/local/include/jansson.h:188:9: note: declared here"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24635#msg24635"},{"f":"jgarzik","d":1290795029,"b":[["q","Nice work.\n\nBut :\n\n> Quote\n> DBG: found zeroes in hash:\n> 6c1e0d9af9b06eab5aae7fbe058760708c1c7869870142b91b9c0ae300000000\n> PROOF OF WORK FOUND?  submitting...\n> PROOF OF WORK RESULT: false (booooo)\n> [...]\n> DBG: found zeroes in hash:\n> c155613cbd70edad88bf56b06cbd788329a2a741b27ee78f25abdb2e00000000\n> PROOF OF WORK FOUND?  submitting...\n> PROOF OF WORK RESULT: false (booooo)\n\nI don't know if this is a bug or not.\nThe miner has been compiled with cygwin, I don't know if it matters.","Quote from: bugmenot on November 26, 2010, 12:08:00 PM"],["t","Not a bug.  The miner finds a hash with \"several\" zeroes in it, but then relies on bitcoin to do the full 256-bit hash < target value comparison.  It's normal that some hashes will be found by the CPU miner, then rejected by bitcoin.  We call those almost-solutions Smiley"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24671#msg24671"},{"f":"jgarzik","d":1290800822,"b":[["t","FWIW, the default bitcoin miner also does this -- it just doesn't print out when it \"finds some zeroes\", only when a real proof of work is found.\n\nThus, my CPU miner always shows when it stops working on a solution, and starts working on a new solution.  Just giving you a bit more information on the whole process."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24681#msg24681"},{"f":"jgarzik","d":1290807171,"b":[["t","Attached is a Windows executable build with mingw32.  I'd be interested to know if it works.\n\nrun \"minerd.exe --help\" or \"minerd.exe -h\" to show command line options.\n\nminerd.exe SHA-1 sum: 722fa3b956de3ed3438ed3294fe191f0d55c1514\nminerd.exe MD5 sum: 9f75f8da7a5d02da1d45d46d4a032489"]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24709#msg24709"},{"f":"jgarzik","d":1290807954,"b":[["q","Should I use a particular version of jansson? I installed it from git, and get the following compile error:\n\nutil.c: In function ‘json_rpc_call’:\nutil.c:133:2: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast\n/usr/local/include/jansson.h:188:9: note: expected ‘size_t’ but argument is of type ‘struct json_error_t *’\nutil.c:133:2: error: too few arguments to function ‘json_loads’\n/usr/local/include/jansson.h:188:9: note: declared here","Quote from: teknohog on November 26, 2010, 01:41:39 PM"],["t","It's been tested with jansson 1.2 and 1.3 release versions.\n\nEDIT:  If 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."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24712#msg24712"},{"f":"satoshi","d":1290808961,"b":[["t","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++.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1925.msg24719#msg24719","s":1,"n":516,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/516/"}]},{"id":"p248","k":"p","s":"bitcointalk","t":"RFC: ship block chain 1-74000 with release tarballs?","u":"https://bitcointalk.org/index.php?topic=1931","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/248/","m":[{"f":"jgarzik","d":1290668871,"b":[["t","It appears that blk0001.dat, where bitcoin stores block chain information, is compatible across Windows, Linux, 32-bit and 64-bit.\n\nTherefore, why not save new users some time by shipping blocks 1-74000 with each release?\n\nPresumably, indexing and verifying a local file would be faster, and use fewer network resources, than downloading all those blocks via P2P."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24277#msg24277"},{"f":"wumpus","d":1290692233,"b":[["t","Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?\n(also the reason why some gaming companies use bittorrent to distribute updates)"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24352#msg24352"},{"f":"RHorning","d":1290695137,"b":[["t","I have mixed feelings about this.  Part of the problem is that there is perceived to be a free good, a network hosting service in the form of Source Forge, which will certainly allow those performing software releases to include considerably more data than is currently the case for Bitcoins.  If somehow we were paying for this service as a community in terms of $$$ per MiB, I think it would be a no brainer that this should stay out of the distribution.  Unfortunately for this consideration, it is a free good from the perspective of most users.\n\nThe other issue is that the network bandwidth between nodes is also a free good.  I've suggested in this thread <http://bitcointalk.org/index.php?topic=1764.0> that perhaps the presumption of network bandwidth may also not be considered a free good either.  In fact, I believe that it shouldn't be the case, but that is a completely separate issue entirely.\n\nThe network bandwidth for downloading the blocks is to me a wash either way, although a new client coming \"on-line\" trying to get the full block chain does suck up a whole bunch of blocks through the Bitcoin network and that impacts anybody who happens to be connected to those nodes.  BTW, this is one of the reasons I think it would be incredibly useful to start \"charging\" for bandwidth as a means to discourage this behavior... and of course to earn a few extra Bitcoins on the side.  If you can obtain blocks \"free\" from another source, some people might get more creative on how to get that accomplished including downloading a second package on some free file hosting service (perhaps included with the main client distributions) or coming up with a scheme on how to bootstrap new clients that impacts the network in a less obtrusive fashion.\n\nI guess what I'm saying is that while this is a simple solution to a complex problem, it doesn't solve all of the problems including perhaps clients which may store the block data in another format.  There also isn't any apparent reason to necessarily encourage other software client distros to include this kind of data or for that matter to put in more than the most minimum number of blocks.  Still, raising the issue is useful here and I hope it raises a discussion about the problem."],["q","Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?\n(also the reason why some gaming companies use bittorrent to distribute updates)","Quote from: witchspace on November 25, 2010, 01:37:13 PM"],["t","I agree it seems very odd that you would take something which is by its nature distributed through P2P channels and instead put it into a conventional client-server distribution model.  Part of why I'm saying that perhaps more thought ought to go into this is perhaps to encourage a bittorrent distribution connection of some sort for a large collection of blocks if somebody has had their client off for awhile or some other kind of experimentation on how to solve this same problem.  The problem is that new clients are demanding the whole block chain and really can't get into \"mining\" or confirming new transactions until they have that chain.  Let's solve that problem, which is a larger issue.\n\nThe other issue is that it seems like a waste of bandwidth to include these blocks in a client when all you are doing is updating the software.  I would be just as worried that the block chain might get wiped out by the installation software with this \"older\" version of the chain, forcing older clients to update to the current block all over again, although this is certainly an installation bug.  Just because it is a free good doesn't imply there are no other consequences to going this route."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24369#msg24369"},{"f":"wumpus","d":1290695494,"b":[["t","Indeed, shipping the data with the client is just a kludge.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24370#msg24370"},{"f":"satoshi","d":1290707499,"b":[["t","It's not the downloading that takes the time, it's verifying and indexing it.\n\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.\n\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.\n\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.\n\nMaybe Berkeley DB has some tweaks we can make to enable or increase cache memory."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438","s":1,"n":511,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/511/"},{"f":"MrFlibble","d":1290727195,"b":[["t","My first reaction was \"+1 for fast setup\", but most of the 24hr delay I suffered was local disc.  Disabling fsync (?) on the database while in catch-up mode would help the most."],["q","Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?\n(also the reason why some gaming companies use bittorrent to distribute updates)","Quote from: witchspace on November 25, 2010, 01:37:13 PM"],["t","Good point.  But since the sha-256 of the block is wired into the code, it is perfectly reasonable to ship the data too.  When the blockchain is over 500meg, I think transfer efficiency will become important.\n\nWe have options,\n\n• ship blockchain from SF until it's not politely within their AUP, then re-evaluate.  I couldn't find a file size limit, even for the project website service (only a quick surf of their docs).\n\n• ship 'small' binaries from SF, and 'large' releases with data via BitTorrent\n\n• ship 'small' release, including the .torrent for the blockchain and a fetcher script. This looks for one of three popular command line BitTorrent clients for the platform and uses that to fetch the chain, or whinge if it can't.\n\nhttp://sourceforge.net/apps/trac/sourceforge/wiki/Developer%20web says"],["q","Note: All file releases should be a single file. Multiple files for the same release should be archived together (tar, deb, zip, etc.). We recommend using rsync for all uploads over 20 megabytes in size, as rsync allows for resuming canceled or interrupted transfers.","Quote"],["t","Hmm, shipping the blockchain for each binary arch would be perverse.\n\nThen, who provides the tracker & seed for the data?  Someone with incentive or community spirit?  Well, this forum+wiki seem to live on http://www.slicehost.com/ => min $20/month.  It could probably share without hurting the website, and (I think) the seed could be severely throttled to make other BT seeds pull more weight."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24499#msg24499"},{"f":"jgarzik","d":1290736063,"b":[["q","It's not the downloading that takes the time, it's verifying and indexing it.","Quote from: satoshi on November 25, 2010, 05:51:39 PM"],["t","This is not true of many novice users, who say things like \"well it took several hours to catch all the 90 000 blocks but finally it arrived\" (quoted from one new user, on IRC, today)."],["q","Bandwidthwise, it's more efficient than if you downloaded an archive.","Quote"],["t","Agreed.  Compressed in an archive, blk0001.dat is around 36MB."],["q","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.\n\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.","Quote"],["t","It remains the download, not the verification, that has the highest variability of experience, where first time users see a delay of 30 minutes to several hours before the software is actually usable.  Some P2P nodes may be extremely slow (I see high variability in latency and throughput for old blocks, and blocks larger than 512 bytes).  End user bandwidth may be low, spotty or expensive.  Firewalls are often a problem.\n\nI'm betting that the above complaint from a new user was due to a Microsoft firewall; but the point stands:  large variance of network configuration and capability implies the P2P download impact may be far, far greater than impact of on-disk verification of 90,000 blocks."],["q","Doing 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.","Quote"],["t","Who said untrusted?  The proposal is that you distribute blk0001.dat (and only blk0001.dat) in the bitcoin.org official client downloads.  And of course the client will spend some time verifying blk0001.dat upon first use.  This is unavoidable, and nobody has proposed changing or eliminating verification.\n\nJust shipping blk0001.dat with official bitcoin would eliminate several headaches that new bitcoin users continue to experience."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24518#msg24518"},{"f":"jgarzik","d":1290737263,"b":[["q","Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.","Quote from: satoshi on November 25, 2010, 05:51:39 PM"],["t","Which of the ACID <http://en.wikipedia.org/wiki/ACID> properties do you need, while downloading?\n\nAdding BDB records is simply appending to a log file, until you issue a checkpoint <http://www.mathematik.uni-ulm.de/help/BerkeleyDB/ref/transapp/checkpoint.html>.  The checkpoint then updates the main database file.\n\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 <http://www.mathematik.uni-ulm.de/help/BerkeleyDB/api_c/env_set_flags.html> still gives you a lot:\n\n     \"database integrity will be maintained, but if the application or system fails, it is possible\n      some number of the most recently committed transactions may be undone during recovery\"\n\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.\n\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?"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522"},{"f":"satoshi","d":1290792721,"b":[["t","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.\n\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.\n\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."],["q","> Quote from: satoshi on November 25, 2010, 05:51:39 PM\n> Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.\nWhich of the ACID <http://en.wikipedia.org/wiki/ACID> properties do you need, while downloading?","Quote from: jgarzik on November 26, 2010, 02:07:43 AM"],["t","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.\n\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."],["q","Adding BDB records is simply appending to a log file, until you issue a checkpoint.  The checkpoint then updates the main database file.","Quote"],["t","We checkpoint every 500 blocks."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662","s":1,"n":513,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/513/"},{"f":"RHorning","d":1290793337,"b":[["q","Who said untrusted?  The proposal is that you distribute blk0001.dat (and only blk0001.dat) in the bitcoin.org official client downloads.  And of course the client will spend some time verifying blk0001.dat upon first use.  This is unavoidable, and nobody has proposed changing or eliminating verification.\n\nJust shipping blk0001.dat with official bitcoin would eliminate several headaches that new bitcoin users continue to experience.","Quote from: jgarzik on November 26, 2010, 01:47:43 AM"],["t","My personal suggestion is to have the block data as a separate download, but strongly recommended.  If you want to simplify the installation for Windows users and otherwise clueless computer users that can't take a block file of this nature and put it into the correct directory, perhaps setting up a formal installation file to put it where it needs to go would be more \"user friendly\", but all it really has to contain is just the block data.\n\nThe purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24664#msg24664"},{"f":"zipslack","d":1290794920,"b":[["q","The purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time.","Quote from: RHorning on November 26, 2010, 05:42:17 PM"],["t","I'm not sure how it is for you, but when I upgrade Bitcoin I don't have to re-download any blocks. It just picks up right where it left off before the upgrade."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24670#msg24670"},{"f":"RHorning","d":1290799045,"b":[["q","> Quote from: RHorning on November 26, 2010, 05:42:17 PM\n> The purpose of this is mainly so those who are updating to a new version can do so without having to also keep downloading the same block data, which by definition is going to grow over time.\n\nI'm not sure how it is for you, but when I upgrade Bitcoin I don't have to re-download any blocks. It just picks up right where it left off before the upgrade.","Quote from: zipslack on November 26, 2010, 06:08:40 PM"],["t","That is the point.  If the blocks are included in the update it would also by definition include blocks you already have obtained via the network.  This is why I'm suggesting that it ought to be a separate but strongly recommended download for new users instead of something combined in the normal distros."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg24679#msg24679"},{"f":"jgarzik","d":1290911609,"b":[["t","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.\n\nOther commenters in this thread are correct that upgrading users don't need a block database...  but something needs to be done to improve the initial block download experience for new users.  Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.\n\nWe 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."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017"},{"f":"tyler","d":1290928984,"b":[["q","Other commenters in this thread are correct that upgrading users don't need a block database...  but something needs to be done to improve the initial block download experience for new users.  Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.","Quote from: jgarzik on November 28, 2010, 02:33:29 AM"],["t","*something* needs to be done, the block chain will be *huge* in the next year or so, correct?"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25054#msg25054"},{"f":"jgarzik","d":1290929635,"b":[["q","> Quote from: jgarzik on November 28, 2010, 02:33:29 AM\n> Other commenters in this thread are correct that upgrading users don't need a block database...  but something needs to be done to improve the initial block download experience for new users.  Improve the database all you want.. you'll still have peers giving you blocks slowly for any number of reasons.\n\n*something* needs to be done, the block chain will be *huge* in the next year or so, correct?","Quote from: tyler on November 28, 2010, 07:23:04 AM"],["t","Yes, correct.\n\nPresumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those..."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058"},{"f":"zipslack","d":1290934380,"b":[["q","This is why I'm suggesting that it ought to be a separate but strongly recommended download for new users instead of something combined in the normal distros.","Quote from: RHorning on November 26, 2010, 07:17:25 PM"],["t","Sorry, I misunderstood you."],["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.","Quote from: jgarzik on November 28, 2010, 02:33:29 AM"],["t","I suppose you are referring to the checkpoints? If so, as I understand it, they are only applied while verifying a block which has been downloaded. The contents of blk0001.dat and blkindex.dat are never checked by the client, because the client is designed to check that data before it gets written to those files. As satoshi indicated in this thread,"],["q","Doing 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.","Quote from: satoshi on November 25, 2010, 05:51:39 PM"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25064#msg25064"},{"f":"jgarzik","d":1290938542,"b":[["q","I suppose you are referring to the checkpoints? If so, as I understand it, they are only applied while verifying a block which has been downloaded. The contents of blk0001.dat and blkindex.dat are never checked by the client, because the client is designed to check that data before it gets written to those files.","Quote from: zipslack on November 28, 2010, 08:53:00 AM"],["t","Not quite true.  \"-checkblocks\" (CheckBlock()) performs quite a few checks on the contents of blk0001.dat / blkindex.dat.  AcceptBlock() does a bit more, adding context, but not much more.  But let's ignore that for the moment.\n\nI think a more important point you're missing is that nobody is proposing that verification be skipped.  The bitcoin code is quite capable of verifying and indexing untrusted blk0001.dat data.  It would just need a few modifications to behave sensibly if blkindex.dat is missing.\n\nThe proposal is simply:  don't download massive amounts of uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer."],["q","As satoshi indicated in this thread,\n\n> Quote from: satoshi on November 25, 2010, 05:51:39 PM\n> Doing 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.","Quote"],["t","The client is clearly capable of verifying the cryptographic integrity of blk0001.dat from an untrusted source, because it does that for blocks coming in over the network, and blk0001.dat contains... serialized blocks originally received from untrusted sources over the network.\n\nIt does not seem overly difficult to pass in blk0001.dat file position data to ProcessBlock(), and simply skip the WriteToDisk() storage call in downstream callee AcceptBlock()."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25073#msg25073"},{"f":"RHorning","d":1290960586,"b":[["q","The client is clearly capable of verifying the cryptographic integrity of blk0001.dat from an untrusted source, because it does that for blocks coming in over the network, and blk0001.dat contains... serialized blocks originally received from untrusted sources over the network.\n\nIt does not seem overly difficult to pass in blk0001.dat file position data to ProcessBlock(), and simply skip the WriteToDisk() storage call in downstream callee AcceptBlock()","Quote from: jgarzik on November 28, 2010, 10:02:22 AM"],["t","Unless I'm mistaken here, what this implies is that at the moment the \"official\" client presumes that blk0001.dat contains validated data, so if you download that data from another source which may have been compromised, at the moment there is no way to verify this information.  This is but a temporary danger to be aware of while the software attempts to cope with this particular issue.\n\nOn the other hand, somebody could also put into the UI or as a command-line switch on bitcoind some sort of \"reverifications\" of the block data which would be performed locally.  I think there are other applications for this including perhaps as a precaution against some virus on your computer manipulating data in the block chain where this would be useful anyway, but it seems like an option which ought to be added to the software.  Since the verification code is already in the software, it is merely setting up the algorithm and triggering mechanism to perform that verification.  Indeed if there is a particular block which is of concern during the verification process, an effort to \"heal\" the chain based upon block requests to peer nodes could be used to fix potential errors or even discard the whole chain.\n\nI hope such a feature eventually is added."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25122#msg25122"},{"f":"MoonShadow","d":1290961515,"b":[["t","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. \n\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?"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25126#msg25126"},{"f":"satoshi","d":1290964381,"b":[["t","Despite everything else said, the current next step is:"],["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.","Quote"],["t","In particular, I suspect that more read caching might help a lot."],["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.","Quote from: jgarzik on November 28, 2010, 02:33:29 AM"],["t","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?"],["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.","Quote"],["t","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.\n\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."],["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...","Quote from: jgarzik on November 28, 2010, 07:33:55 AM"],["t","80 bytes per header and no indexing work.  Might take 1 minute."],["q","uncompressed data using a protocol (bitcoin P2P) that wasn't designed for bulk data transfer.","Quote"],["t","The data is mostly hashes and keys and signatures that are uncompressible.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138","s":1,"n":518,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/518/"},{"f":"jgarzik","d":1290970789,"b":[["q","If there was a \"verify it\" step, that would take as long as the current initial download, in which it is the indexing, not the data download, that is the bottleneck.\n[...]\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.","Quote from: satoshi on November 28, 2010, 05:13:01 PM"],["t","Sorry, these users' disk and CPU were not at 100%.  It is clear the bottleneck is not the database or indexing, for many users."],["q","The data is mostly hashes and keys and signatures that are uncompressible.","Quote"],["t","bzip2 gives you 33% compression ratio, saving many megabytes off a download:"],["c","[jgarzik@bd data]$ tar cvf /tmp/1.tar blk0001.dat\nblk0001.dat\n\n[jgarzik@bd data]$ tar cvf /tmp/2.tar blk*.dat\nblk0001.dat\nblkindex.dat\n\n[jgarzik@bd data]$ bzip2 -9v /tmp/[12].tar\n  /tmp/1.tar:  1.523:1,  5.253 bits/byte, 34.34% saved, 55439360 in, 36402074 out.\n  /tmp/2.tar:  1.512:1,  5.291 bits/byte, 33.86% saved, 103690240 in, 68577642 out."],["t","I wouldn't call 33% \"uncompressible\""]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25164#msg25164"},{"f":"theymos","d":1290983693,"b":[["q","Sorry, these users' disk and CPU were not at 100%.  It is clear the bottleneck is not the database or indexing, for many users.","Quote from: jgarzik on November 28, 2010, 06:59:49 PM"],["t","It seemed to me that it was some sort of disk problem or network condition on his end. Some selected quotes from my IRC log:"],["q","<manveru> also, when i woke up, there were thousands of entries in the debug.log that look like: trying connection  lastseen=-135.6hrs lasttry=-358582.4hrs\n<theymos> How many connections do you have?\n<manveru> 2 right now\n<theymos> How many blocks do you have?\n<manveru> blockcount and blocknumber are 29124\n<theymos> How fast is that increasing?\n<manveru> around 1 every 4 seconds\n<jgarzik> manveru: 32-bit or 64-bit linux?\n<manveru> 64\n<manveru> now 'blkindex.dat flush' takes a few minutes :|\n<manveru> still hangs on flush\n<theymos> manveru: Are you on some network file system?\n<manveru> no, just a normal harddisk\n<manveru> it's only 5200 rpm though","Quote"],["t","Also, replacing the blocks might have prevented him from noticing a transaction:"],["q","<manveru> jgarzik: sent me the blocks, but it didn't change my balance\n<MT`AwAy> manveru: in your getinfo you're at block 94236 ?\n<manveru> yeah","Quote"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25219#msg25219"},{"f":"jgarzik","d":1291057272,"b":[["q","Building blkindex.dat is what causes all the disk activity.\n[...]\nMaybe Berkeley DB has some tweaks we can make to enable or increase cache memory.","Quote from: satoshi on November 25, 2010, 05:51:39 PM"],["t","The following code in AddToBlockIndex(main.cpp) is horribly inefficient, and dramatically slows initial block download:"],["c","    CTxDB txdb;\n    txdb.WriteBlockIndex(CDiskBlockIndex(pindexNew));\n\n    // New best\n    if (pindexNew->bnChainWork > bnBestChainWork)\n        if (!SetBestChain(txdb, pindexNew))\n            return false;\n\n    txdb.Close();"],["t","This 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.\n\nFurthermore, database open + close for each new block is incredibly expensive.  For each database-open and database-close operation, db4\n\n• diagnose health of database, to determine if recovery is needed.  this test may require data copying.\n\n• re-init memory pools\n\n• read database file metadata\n\n• acquire file locks\n\n• read and initialize b-tree or hash-specific metadata.  build hash table / b-tree roots.\n\n• forces a sync, even if transactions called with DB_TXN_NOSYNC\n\n• fsync memory pool\n\nAnd, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.\n\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.\n\nRecommendations:\n\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.\n\n2) For the initial block download, txn commit should occur once every N records, not every record.  I suggest N=1000.\n\nEDIT:  Updated a couple minor details, and corrected some typos."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25434#msg25434","sj":"Problem: opening and closing database for each block"},{"f":"satoshi","d":1291061952,"b":[["t","It seems like you're inclined to assume everything is wrong more than is actually so.\n\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."],["q","1) bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.","Quote"],["t","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."],["q","And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.","Quote"],["t","If it was doing that it would be much slower.  It's supposed to be only once a minute or 500 blocks:\n\n    if (strFile == \"blkindex.dat\" && IsInitialBlockDownload() && nBestHeight % 500 != 0)\n        nMinutes = 1;\n    dbenv.txn_checkpoint(0, nMinutes, 0);\n\nProbably should add this:\n    if (!fReadOnly)\n        dbenv.txn_checkpoint(0, nMinutes, 0);"],["q","2) For the initial block download, txn commit should occur once every N records, not every record.  I suggest N=1000.","Quote"],["t","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.\n\nIn the following cases, would case 1 flush once and case 2 flush twice?\n\ncase 1:\nwrite\nwrite\nwrite\nwrite\ncheckpoint\n\ncase 2:\nbegin transaction\nwrite\nwrite\ncommit transaction\nbegin transaction\nwrite\nwrite\ncommit transaction\ncheckpoint\n\nContorting our database usage will not be the right approach.  It's going to be BDB settings and caching."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449","s":1,"n":520,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/520/"},{"f":"jgarzik","d":1291064442,"b":[["t","Yeah, I missed the database-open caching buried in all the C++ constructors.  Major red herring, sorry about that.\n\ndb4 cache control is http://download.oracle.com/docs/cd/E17076_01/html/api_reference/CXX/dbset_cachesize.html"]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25467#msg25467"},{"f":"jgarzik","d":1291075617,"b":[["t","I instrumented my import using the -initblock=FILE patch <http://bitcointalk.org/index.php?topic=1999.0> posted last night, putting printf tracepoints in TxnBegin, TxnCommit, TxnAbort, Read and Write:"],["c","ProcessBlock: ACCEPTED\nCDB::Write()\nDB4: txn_begin\nCDB::Write()\nCDB::Write()\nCDB::Write()\nDB4: txn_commit\nSetBestChain: new best=000000005b5c1859db19  height=1751  work=7524897523416\nProcessBlock: ACCEPTED\nCDB::Write()\nDB4: txn_begin\nCDB::Write()\nCDB::Write()\nCDB::Write()\nDB4: txn_commit\nSetBestChain: new best=00000000f396ab6b62ba  height=1752  work=7529192556249\nProcessBlock: ACCEPTED\nCDB::Write()\nDB4: txn_begin\nCDB::Write()\nCDB::Write()\nCDB::Write()\nDB4: txn_commit\nSetBestChain: new best=000000000c6bcf972117  height=1753  work=7533487589082"],["t","So, it appears that we have a CDB::Write() that occurs outside of a transaction (vTxn is empty??).\n\ntxnid==NULL is perfectly legal for db4, but it does mean that callpath may be operating outside of the DB_TXN_NOSYNC flag that is set in ::TxnBegin().  Thus, a CDB::Write() outside of a transaction may have synchronous behavior (DB_TXN_SYNC) as governed by DB_AUTO_COMMIT database flag.\n\nEDIT:  Wrapping WriteBlockIndex() inside a transaction does seem to speed up local disk import (-initblocks)."],["c","--- a/main.cpp\n+++ b/main.cpp\n@@ -1427,7 +1427,10 @@ bool CBlock::AddToBlockIndex(unsigned int nFile, unsigned\n     pindexNew->bnChainWork = (pindexNew->pprev ? pindexNew->pprev->bnChainWork\n \n     CTxDB txdb;\n+    txdb.TxnBegin();\n     txdb.WriteBlockIndex(CDiskBlockIndex(pindexNew));\n+    if (!txdb.TxnCommit())\n+       return false;\n "],["t","Of course that implies begin+commit+begin+commit in quick succession (SetBestChain), so maybe a less naive approach might be preferred (nested transactions, or wrap both db4 writes in the same transaction)."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25531#msg25531"},{"f":"jgarzik","d":1291102080,"b":[["t","I timed two runs with clean data directories (no contents), -noirc, -addnode=10.10.10.1, Linux 64-bit.  Hardware: SATA SSD\n\nMainline, no patches:\n     32 minutes to download 94660 blocks.\n\nMainline + TxnBegin/TxnCommit in AddToBlockIndex():\n     25 minutes to download 94660 blocks."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg25675#msg25675"},{"f":"satoshi","d":1291238739,"b":[["t","That's a good optimisation.  I'll add that next time I update SVN.\n\nMore generally, we could also consider this:\n\n        dbenv.set_lk_max_objects(10000);\n        dbenv.set_errfile(fopen(strErrorFile.c_str(), \"a\")); /// debug\n        dbenv.set_flags(DB_AUTO_COMMIT, 1);\n+       dbenv.set_flags(DB_TXN_NOSYNC, 1);\n        ret = dbenv.open(strDataDir.c_str(),\n                         DB_CREATE     |\n                         DB_INIT_LOCK  |\n                         DB_INIT_LOG   |\n\nWe would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes."]],"u":"https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016","s":1,"n":522,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/522/"}]},{"id":"p249","k":"p","s":"bitcointalk","t":"Version 0.3.17","u":"https://bitcointalk.org/index.php?topic=1946","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/249/","m":[{"f":"satoshi","d":1290715656,"b":[["t","Version 0.3.17 is now available.\n\nChanges:\n- new getwork, thanks m0mchil\n- added transaction fee setting in UI options menu\n- free transaction limits\n- sendtoaddress returns transaction id instead of \"sent\"\n- getaccountaddress <account>\n\nThe UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.\n\nThe accounts-based commands: move, sendfrom and getbalance <account> will be in the next release.  We still have some more changes to make first.\n\nDownloads:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24460#msg24460","s":1,"n":512,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/512/"},{"f":"SmokeTooMuch","d":1290716285,"b":[["t","where are the windows binaries ?"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24463#msg24463"},{"f":"BioMike","d":1290718195,"b":[["t","Why no 0.3.16?"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24474#msg24474"},{"f":"nanotube","d":1290726182,"b":[["t","and what exactly does \"free transaction limits\" mean? what is the new transaction fee schedule?"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24494#msg24494"},{"f":"slush","d":1290728990,"b":[["q","and what exactly does \"free transaction limits\" mean? what is the new transaction fee schedule?","Quote from: nanotube on November 25, 2010, 11:03:02 PM"],["t","Is transaction fee used for confirmation priorities? If yes, it would be cool to allow changes of fees directly on 'send coins' dialog. For some donations of few bitcoins I don't care about time, but if I want to send coins to somebody who is waiting to confirmation, it can help..."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24501#msg24501"},{"f":"nanotube","d":1290733496,"b":[["q","Is transaction fee used for confirmation priorities? If yes, it would be cool to allow changes of fees directly on 'send coins' dialog. For some donations of few bitcoins I don't care about time, but if I want to send coins to somebody who is waiting to confirmation, it can help...","Quote from: slush on November 25, 2010, 11:49:50 PM"],["t","that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24514#msg24514"},{"f":"slush","d":1290733839,"b":[["q","that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)","Quote from: nanotube on November 26, 2010, 01:04:56 AM"],["t","Yes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24515#msg24515"},{"f":"nanotube","d":1290745303,"b":[["q","> Quote from: nanotube on November 26, 2010, 01:04:56 AM\n> that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)\n\nYes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution.","Quote from: slush on November 26, 2010, 01:10:39 AM"],["t","yea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24538#msg24538"},{"f":"tyler","d":1290755904,"b":[["q","> Quote from: slush on November 26, 2010, 01:10:39 AM\n> > Quote from: nanotube on November 26, 2010, 01:04:56 AM\n> > that's what the \"added transaction fee setting in UI options menu\" bit is. you can set the fee you'll pay through the gui. (earlier it was only possible with bitcoind.)\n>\n> Yes, I found that in .17 and it is cool. But I think the 'send coins' dialog is better place for this because of usability. It gives easier way how to set up fee separately for every transaction. But it is only an idea and I'm happy also for current solution.\n\nyea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both.","Quote from: nanotube on November 26, 2010, 04:21:43 AM"],["t","Are you planning on changing the fee for every transaction?"]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24568#msg24568"},{"f":"nanotube","d":1290756012,"b":[["q","Are you planning on changing the fee for every transaction?","Quote from: tyler on November 26, 2010, 07:18:24 AM"],["t","yes, when it gets to the point that fees really make a difference in speed of getting into the chain... i might send a larger fee for transactions i want to be fast, and smaller or none where i don't care about speed (e.g., donations). "]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24569#msg24569"},{"f":"ribuck","d":1290768908,"b":[["q","yea, i also think that the 'send coins' dialog is a better place for it. or at least, to have it in both.","Quote from: nanotube on November 26, 2010, 04:21:43 AM"],["t","I think it's worth keeping the default interface as simple as possible for new users. If people want to set a price in the \"send coins\" dialog, this field should be enabled by a configuration option, not presented to new users."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24615#msg24615"},{"f":"nelisky","d":1290794298,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24668#msg24668"},{"f":"satoshi","d":1290795810,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673","s":1,"n":514,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/514/"}]},{"id":"p250","k":"p","s":"bitcointalk","t":"[2.5+ EH] Slush Pool (slushpool.com); World's First Mining Pool","u":"https://bitcointalk.org/index.php?topic=1976","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/250/","m":[{"f":"slush","d":1290865541,"b":[["t"," <https://slushpool.com/>\n\nNews <https://slushpool.com/news/> | Pool Statistics <https://slushpool.com/stats/?c=btc> | Block History <https://slushpool.com/stats/blocks/?c=btc> | Help Center <https://slushpool.com/help/> | Demo Account <https://slushpool.com/accounts/demo-login/>\n\nWe are the world's first cryptocurrency mining pool founded in 2010.\nSince then we have together mined over 1 million BTC.\n\nReasons to mine on Slush Pool\n\n• low flat fee of 2 % (network fees are shared with miners!)\n\n• stable income thanks to our significant network share (~ 15 blocks a day)\n\n• neat interface with dashboard and worker monitoring\n\n• advanced security with 2FA and payout address locking\n\n• servers in Europe, North America and Asia\n\n• free withdrawals above 0.01 BTC\n\nStart mining on Slush Pool\n\n• Basic Mining Setup <https://slushpool.com/help/get-started/getting_started>\n\n• Advanced Mining Setup <https://slushpool.com/help/get-started/advanced_mining>\n\n• please note only cgminer and BFGminer are supported ATM\n\nSupport\n\n• Create a ticket in our support system <https://support.slushpool.com/conversation/new>, if you have any issues or questions.\n\n• We will get back to you as soon as possible, usually within 24 hours.\n\n• We cannot guarantee answering questions posted elsewhere. Thank you for understanding.\n\nFollow us: Twitter <https://twitter.com/slush_pool> | Facebook <https://www.facebook.com/SlushPoolMining> | Blog <https://blog.slushpool.com/>\n\n―――\n\n―――\n\n―――\nOriginal post:\nOnce people started to use GPU enabled computers for mining, mining became very hard for other people. I'm on bitcoin for few weeks and didn't find block yet (I'm mining on three CPUs). When many people have slow CPUs and they mining separately, each of them compete among themselves AND against rich GPU bastards ;-), because everybody counts sha256 hashes from the same range. Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!. But new feature of the official bitcoin client called 'getwork' now enables work of many computers together, so they don't compete. Because there is now standalone CPU miner (thanks to jgarzik!) and 'getwork' patch is in official client now, I have an idea:\n\nJoin poor CPU miners to one cluster and increase their chance to find a block!\n\nHow that should work? There will be web page where you can register, enter your wallet address and get URL and your personal rpcuser/rpcpassword for your CPU/GPU miners. When you start own miner with these credentials, server will send you work which was not calculated yet by other members of cluster.\n\nBut when your client find winning hash, you do not get full reward for block (50BTC right now), but only proportional part, which you calculate. When you offer 1000khash/s for one day and whole cluster performance will be 20000khash/s and it takes two days to find a block, your reward will be (50/20/2=)1.25BTC.\n\nAdvantages? When you have poor standalone computer, you need to wait many weeks or even months for finding full 50BTC reward. When you join cluster like this, you will constantly receive small amount of bitcoins every day or week (depends on full cluster performance).\n\nDisadvantages? You need to trust in central authority (me) that I don't steal block for myself. But I'm goofing around for few week and I'm amazed with bitcoin idea, so I don't plan to steal anybody right now :-).\n\nAnother possible problem is that somebody will ask for new work very often, but in fact he will not count real hashes. In this case it will look like he has very strong CPU and he should get big part of reward if cluster find a block. But there is a simple defense against cheaters: Central server sometimes send work which leads to 'winning' hash. Worker which don't return this hash as matching will be permanently banned (login/password and IP address). This was succesfully solved by letting miners calculate proof-of-work. It is not anymore possible to be a part of cluster and not count hashes.\n\nAre you interested in?"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24844#msg24844"},{"f":"ribuck","d":1290868556,"b":[["q","Two separate CPUs with 1000khash/s isn't the same as one 2000khash/s machine!","Quote from: slush on November 27, 2010, 01:45:41 PM"],["t","Actually, they are equal. The low-power machines aren't \"racing\" against the high power machines. For any given difficulty level, it doesn't even matter how many other machines are generating. If all the other machines dropped off the network, it wouldn't increase the number of blocks you generate (until the next difficulty level adjustment).\n\nThe only thing that counts significantly is the difficulty level and your khash/s. There are some relatively minor effects due to network latency, but they're not a big deal."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24858#msg24858","sj":"Re: Cooperative mining"},{"f":"td","d":1290869283,"b":[["t","I will offer a Six-Way AMD Processor to the Cooperative Mining Group. I tried generating for weeks on it to no avail. I have given up in the mean time and have instead purchased coins for use. I would love to turn the value of my tiny 9,000/k/hash/s into something productive. If nothing else as part of an experiment to make your software more secure. There is another thread already on the forum for the source code to Cooperative Mining but I am not sure that it was complete or successful. There appeared several people participating but no additional work from them. Perhaps it was so successful that they no longer wish to have additional participants into their group- I am unsure. My rate contribution may not win me blocks by myself but as a larger group hopefully I could be helpful. Please let me know if you move forward with this. "]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24862#msg24862","sj":"Re: Cooperative mining"},{"f":"BitLex","d":1290869329,"b":[["t","i always liked the idea of distributed mining,\nwith CPUs its actually the only chance you got to get some coins on a regular basis now and even using a GPU it already takes days to generate a block on your own, rising for sure.\n\ncall me in at least for beta-testing, there's always some cores around to share."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24863#msg24863","sj":"Re: Cooperative mining"},{"f":"bober182","d":1290874344,"b":[["t","Sure seems fair its better then waiting 1 year for 50 bitcoin. Now I wait 1/50 of a year for 1 bitcoin yay!"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24875#msg24875","sj":"Re: Cooperative mining"},{"f":"slush","d":1290874826,"b":[["q","For any given difficulty level, it doesn't even matter how many other machines are generating.","Quote from: ribuck on November 27, 2010, 02:35:56 PM"],["t","You are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.\n\nI think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs."],["q","The only thing that counts significantly is the difficulty level and your khash/s.","Quote"],["t","Of course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24878#msg24878","sj":"Re: Cooperative mining"},{"f":"FreeMoney","d":1290875209,"b":[["q","> Quote from: ribuck on November 27, 2010, 02:35:56 PM\n> For any given difficulty level, it doesn't even matter how many other machines are generating.\n\nYou are true for long term. But I think many people with poor CPUs simply switch off their minings because they see it will take ages until they receive single bitcoin from that. When you are in cluster of cooperative miners, you will receive small amount (say 0.01 BTC if you contribute 0.02% to cluster performance) but more often. I feel that it may be a motivation for people to not shut down their miners.\n\nI think it is extremely important for bitcoin economy to diversify mining across whole network and not leave mining on few lucky guys with fast GPUs.\n\n> Quote\n> The only thing that counts significantly is the difficulty level and your khash/s.\n\nOf course. The more khash/s in cluster, the more blocks found by cluster and more often payments to cluster members.","Quote from: slush on November 27, 2010, 04:20:26 PM"],["t","I like the idea, but your rhetoric is awful.\n\nLucky guys with GPUs? Do you think those are distributed via lottery or something?"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24880#msg24880","sj":"Re: Cooperative mining"},{"f":"grondilu","d":1290876224,"b":[["t","Isn't cooperative mining a form of communism ?\n\nPersonnaly I gave this a thought and I think it's useless and much harder to do than one might think.\n\nFirst I thought it was a problem if only a few nodes were capable of mining.  Now I don't care anymore.  Even if only one was mining all new bitcoins, I wouldn't care much.  This node would do all the work recquired, and in the best way.   Plus, anyone can take its place if it can hash more."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24882#msg24882","sj":"Re: Cooperative mining"},{"f":"slush","d":1290877491,"b":[["q","Lucky guys with GPUs? Do you think those are distributed via lottery or something?","Quote from: FreeMoney on November 27, 2010, 04:26:49 PM"],["t","It is just my feeling of inferiority that I have few Mhash/s :-D\n\nDon't take it personally, I'm OK with GPU miners. But I'd like to give real chance to get few btc for many users with poor computers. That's all."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24885#msg24885","sj":"Re: Cooperative mining"},{"f":"slush","d":1290877798,"b":[["q","Isn't cooperative mining a form of communism ?","Quote from: grondilu on November 27, 2010, 04:43:44 PM"],["t","Do you really think cooperation is communism? There is nothing as 'free bitcoins for everybody' in cooperative mining."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24886#msg24886","sj":"Re: Cooperative mining"},{"f":"FreeMoney","d":1290877845,"b":[["q","Isn't cooperative mining a form of communism ?\n\nPersonnaly I gave this a thought and I think it's useless and much harder to do than one might think.\n\nFirst I thought it was a problem if only a few nodes were capable of mining.  Now I don't care anymore.  Even if only one was mining all new bitcoins, I wouldn't care much.  This node would do all the work recquired, and in the best way.   Plus, anyone can take its place if it can hash more.","Quote from: grondilu on November 27, 2010, 04:43:44 PM"],["t","There is nothing wrong with voluntary communism. Not sure if you were implying that there is or not. I think someone has worked out the details of making it work, but I'm not sure."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24888#msg24888","sj":"Re: Cooperative mining"},{"f":"BitLex","d":1290878760,"b":[["q","useless and much harder to do than one might think","Quote"],["t","i agree on the harder part, there'd be some problems to solve and hurdles to take,\nbut i don't think it's useless.\n\nany bit of computing-power, be it from CPUs or GPUs, makes our network stronger.\nit'll help even those that aren't generating at all, by protecting their coins.\n\npeople are willing todo lots of stuff, if you give them at least something in return.\ncurrently you practically don't get anything for adding your cpu/s to the cloud, you probably have to pay for it, so why do it anyway?\nmost people won't, maybe they will if you give them just a few coins, or bitcents for what they do.\n\nof course bitcoin in general is not about generating at all, but it's a nice way to attract it to a lot more people."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24891#msg24891","sj":"Re: Cooperative mining"},{"f":"farmer_boy","d":1290879695,"b":[["t","This is fundamentally flawed. I can join the \"effort\" and figure out how long it generally takes to perform one unit of work. After that time I send a message \"ah, too bad I didn't find anything\". Then someone does find an answer and I collect.\n\nNow, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.\n\nThe distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins. "]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24894#msg24894","sj":"Re: Cooperative mining"},{"f":"slush","d":1290880980,"b":[["q","This is fundamentally flawed. I can join the \"effort\" and figure out how long it generally takes to perform one unit of work. After that time I send a message \"ah, too bad I didn't find anything\". Then someone does find an answer and I collect.","Quote from: farmer_boy on November 27, 2010, 05:41:35 PM"],["t","Do you mean somebody can cheat by simply asking for work, but not counting hashes? I talked about it already - I will send task which leads to 'winning' hash and when worker does not return it, I will ban them."],["q","Now, if I find the answer, I would simply communicate that to the rest of the network (not the central server) and there is no way for you to figure out that I double crossed you.","Quote"],["t","Also this kind of cheat will be detected by technique described above. You will succeed at most once before you will be banned by central server."],["q","The distributed method there is now is a good way to mine. Possibly it would be better if it was easier to solve and that you would get less bitcoins, OTOH, people are still generating coins.","Quote"],["t","Partially agree. But until one mined block will be for more than 1 BTC, cooperative mining should be still better for slow computers, because possible reward in coop can be also in BTC cents or less."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24896#msg24896","sj":"Re: Cooperative mining"},{"f":"bitcoin2","d":1290881721,"b":[["t","puddinpop has released a Pooled/Remote Mining - client:\nhttps://www.bitcoin.org/smf/index.php?topic=1458.0;all\n\nIs this client gpu-ready?"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24901#msg24901","sj":"Re: Cooperative mining"},{"f":"jgarzik","d":1290882029,"b":[["q","puddinpop has released a Pooled/Remote Mining - client:\nhttps://www.bitcoin.org/smf/index.php?topic=1458.0;all\n\nIs this client gpu-ready?","Quote from: bitcoin2 on November 27, 2010, 06:15:21 PM"],["t","Your answer is here <http://bitcointalk.org/index.php?topic=1283.msg24900;topicseen#msg24900> in the thread where you originally posted this question."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24904#msg24904","sj":"Re: Cooperative mining"},{"f":"bitcoin2","d":1290882762,"b":[["q","> Quote from: bitcoin2 on November 27, 2010, 06:15:21 PM\n> puddinpop has released a Pooled/Remote Mining - client:\n> https://www.bitcoin.org/smf/index.php?topic=1458.0;all\n>\n> Is this client gpu-ready?\n\nYour answer is here <http://bitcointalk.org/index.php?topic=1283.msg24900;topicseen#msg24900> in the thread where you originally posted this question.","Quote from: jgarzik on November 27, 2010, 06:20:29 PM"],["t","The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24911#msg24911","sj":"Re: Cooperative mining"},{"f":"ribuck","d":1290883666,"b":[["t","The cheating problem has a trivial solution.\n\nThe distributed miners work to find a hash at a difficulty level that is considerably lower than the network requires. Whenever they find one, they send it back. When one of those hashes is difficult enough to meet the needs of the network, it generates 50 bitcoins which are distributed to those who have been sending in hashes at the easier level.\n\nThere's no way to look for easy hashes without also having a chance to find the occasional difficult hash. And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).\n\nWith this scheme there is no incentive to cheat, and no need for \"banning\"."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24922#msg24922","sj":"Re: Cooperative mining"},{"f":"slush","d":1290884299,"b":[["q","And when you find a difficult hash, there's nothing better to do with it than to send it back to the mining co-ordinator (because it's a hash that pays them 50 bitcoins, not one that pays you 50 bitcoins).","Quote from: ribuck on November 27, 2010, 06:47:46 PM"],["t","Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as \"my own\" hash? I don't think so. I thought it is possible to not return hash to coordinator and put it directly to bitcoin network in own transaction... "]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24928#msg24928","sj":"Re: Cooperative mining"},{"f":"ribuck","d":1290887455,"b":[["q","Oh, so when I got work from coordinator which leads to winning hash, I cannot send it to bitcoin network as \"my own\" hash?","Quote from: slush on November 27, 2010, 06:58:19 PM"],["t","In a pooled mining situation, the winning hash cannot be used as \"your own\".\n\nThe hash incorporates all of the transactions in the block, including the one that pays 50 BTC to the generator.\n\nIf you are hashing for pooled generation, the winning hash is only useful to the pool.\n\nIf you are hashing for yourself, then obviously the winning hash is useful to you. But in that case the \"low-difficulty\" hashes that you generate are useless to the pool, so the pool will not pay you a share of the generated 50 BTC.\n\nIt is a solved problem to prevent cheating with pooled generation."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24940#msg24940","sj":"Re: Cooperative mining"},{"f":"puddinpop","d":1290892639,"b":[["q","The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops.","Quote from: bitcoin2 on November 27, 2010, 06:32:42 PM"],["t","Is there a particular reason that the pooled miner I created is not sufficient?  It has the basics there already.  It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client.  I just updated this thread <https://www.bitcoin.org/smf/index.php?topic=1458.msg16906#msg16906> with the latest source and binaries for pooled mining."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24960#msg24960","sj":"Re: Cooperative mining"},{"f":"farmer_boy","d":1290895619,"b":[["t","How can the server create winning hashes? Winning hashes are by definition hard to compute objects that are all shared as soon as they are known. In fact, you can cheat by simply having a fake miner on a bunch of different IPs (via ipv6 you can have millions) with one real miner. The real miner remembers all the previously hard to compute objects and does hard work so has the same information as the server. If the server sends a unit of work to a fake miner, the fake miner forwards the request to the real miner and otherwise does nothing.\n\nYour assumption about IP addresses is also invalid, btw. People still have dynamic ip addresses.\n\nI would be interested in the concept, but I don't think there is a solution. "]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24963#msg24963","sj":"Re: Cooperative mining"},{"f":"grondilu","d":1290896487,"b":[["t","To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked.  What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?\n\nI wonder if it wouldn't be simpler to just rent processing power.  For instance by renting a ssh access to each machine.\n\nThe price could be directly proportionnal to the total number of computed hashes."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24966#msg24966","sj":"Re: Cooperative mining"},{"f":"FreeMoney","d":1290898758,"b":[["q","> Quote from: bitcoin2 on November 27, 2010, 06:32:42 PM\n> The Remote mining in the official bitcoin release has no \"send back\" - function but we are searching a pooling-miner like puddinpops.\n\nIs there a particular reason that the pooled miner I created is not sufficient?  It has the basics there already.  It checks the best hash from each client to make sure the clients are doing the work they say, and it distributes the generated bitcoins based on the calculated hash rate of each connected client.  I just updated this thread <https://www.bitcoin.org/smf/index.php?topic=1458.msg16906#msg16906> with the latest source and binaries for pooled mining.","Quote from: puddinpop on November 27, 2010, 09:17:19 PM"],["t","Can't they just send all except the winning ones? Maybe I don't understand though."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24979#msg24979","sj":"Re: Cooperative mining"},{"f":"ribuck","d":1290899042,"b":[["q","To me it seems that cooperative mining is a tough task, because the honnesty of participants has to be checked.  What's preventing someone to run a modified version of the client, that would just keep generated bitcoin for himself, while receiving bitcoins from others ?","Quote from: grondilu on November 27, 2010, 10:21:27 PM"],["t","<sigh>\n\nEither I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.\n\nSuppose I operate a pooled mining server, and I recruit some clients who wish to pool their mining.\n\nMy server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current \"official\" difficulty level.\n\nMy server gets a constant trickle of candidate hashes sent back by the remote mining clients. Every now and then, one of those hashes meets the official difficulty level and my server can generate a block, which earns my server 50 bitcoins.\n\nI now distribute bitcoins to the remote mining clients, at the rate of one bitcoin for each hash that was submitted for the current block that was at or above 1/40th of the official difficulty level.\n\nIn the long run, I would expect to distribute 40 coins out of every 50 that my server generates, although there will be some fluctuation from block to block. Nothing in this scheme requires the clients to be honest, because there is no way that a dishonest client can cheat!\n\nThe client is calculating hashes that will generate 50 BTC for my server. Those same hashes are not of any use to a dishonest client. They cannot be used to generate 50 BTC for the dishonest client, because a different hash code is needed to encode the payment of the generated bitcoins to someone else. And if the dishonest client tries to cheat by generating hashes that will pay the generated bitcoins to themselves, then the hash codes they submit won't validate at my server and I won't distribute any share of the payouts to them.\n\nSo this scheme requires absolutely no trust of the client.\n\nThis scheme also does not require the mining client to have faith that the server is honest. If the server advertises that it is paying out 1BTC for each hash that is at least 1/40th of the official difficulty level, then every client that submits an \"easy\" hash for a block that was generated can check that they received their bitcoin. Any fraud would show up immediately."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24981#msg24981","sj":"Re: Cooperative mining"},{"f":"grondilu","d":1290899869,"b":[["q","Either I haven't been very good at explaining why there's no possibility to cheat, or I'm wrong. But if I'm wrong, no-one has posted a specific objection. So I'll try to explain it again, by presenting a specific design to show that a dishonest client cannot cheat.","Quote from: ribuck on November 27, 2010, 11:04:02 PM"],["t","Sorry, your system seems quite well thought, indeed.  I hadn't been paying enough attention.\n\nStill, I keep thinking that renting ssh access would be much simpler a solution."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg24989#msg24989","sj":"Re: Cooperative mining"},{"f":"FreeMoney","d":1290916660,"b":[["t","Ribuk, thank you for explaining again. I get it now. It wasn't sinking in that the miners were working on a block for which they couldn't take the reward, seems obvious now."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25026#msg25026","sj":"Re: Cooperative mining"},{"f":"QuantumMechanic","d":1290921828,"b":[["t","It sounds like pooled mining would either flood the network with tiny transactions, or be unfeasible due to transaction fees.  So the server would therefore have to keep accounts for users which they could withdraw from once their balance gets large enough.\n\nI guess it would probably be best then if the server required the miners to have MyBitcoin accounts, or something similar.  It'd be nice if MyBitcoin offered a pooled mining service; they've got all the accounting infrastructure in place, and it could be a nice additional source of revenue for them.\n\nVery elegant solution, Ribuck."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25032#msg25032","sj":"Re: Cooperative mining"},{"f":"RHorning","d":1290928293,"b":[["q","My server asks each client to do some hashing for it. It asks each client to submit any hashes they find that are above a certain threshold of difficulty. The server chooses a difficulty that is one-fortieth (1/40th) of the current \"official\" difficulty level.","Quote from: ribuck on November 27, 2010, 11:04:02 PM"],["t","One of the potential problems I can see is that you may have to tweak the \"reduced\" difficulty level in some way so that it really is about a 1 in 40 chance of getting a successful hash.  It would seem to me that a reduction of even a couple of bits in the expected hash would have major consequences in terms of how many \"reduced difficulty hashes\" are created and it is possible that reducing the difficulty to 1/40th of the \"official\" difficulty level may create many more \"successful\" reduced difficulty hashes than 40, perhaps even to a higher order of magnitude.  This is something to test with a successful experiment of this idea to see just how it might turn out.\n\nFurthermore, it is also going to be random in terms of how many reduced hashes are going to be created per successful hash cycle, as you are dealing with probability here and not mathematical certainty in terms of how many are going to be generated by the \"farm\" even if it does produce in this example on average about 40 \"reduced difficulty hashes\".  It may still be worth the effort if it turns out that on average that is all you have to spend for an increase in successful blocks created, but it will be some blocks where the hash farm server makes a bunch of coins for the server operator and other times it may be at least temporarily a loss.\n\nAnother potential problem I also see is if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty.  This is a potential liability issue so far as the \"owner\" of the hash farm server is concerned, as it would substantially impact the \"profit margin\".  Think of it this way:  If the current difficulty is at say 800 and you've received 30 hashes with a difficulty level of 20 (1/40th of the difficulty, as you suggested here), then the difficulty increases to 1600, it is very likely that you may have to plow through another 30-40 hashes at the new higher difficulty level of 40 before you get a successful block into the chain mining the coins.  If in this example you are still paying out 1 BTC per reduced hash, it could get very costly for the person running the hash farm in this case.  It may wipe out any profit earned and certainly is another potential liability issue to think about.  I'd have to think through the statistical probability on an increase of difficulty some more in terms of giving some hard numbers, but it is something that should be accounted for.\n\nThen again, difficulty could drop brining in at least statistically more money to the server operator.  The current tendency is for increases of difficulty, however.\n\nOtherwise, I think the basic concept as outlined here is pretty sound and would tend to work rather well.  Almost too well as I could see this being put into a botnet and having the computers in the botnet be sending back potential hashes without having to worry about any payments.  Network bandwidth would be trivial and almost unnoticed, and you could even \"throttle\" the CPU bandwidth or throw it onto the GPU instead.  I have no doubt that eventually somebody is going to build one of these botnets if it hasn't already been built for Bitcoins."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25053#msg25053","sj":"Re: Cooperative mining"},{"f":"ribuck","d":1290953242,"b":[["q","... if you happen to be requesting hashes where you've received a couple dozen reduced hashes and then the network has a huge spike in difficulty.  This is a potential liability issue so far as the \"owner\" of the hash farm server is concerned, as it would substantially impact the \"profit margin\"","Quote from: RHorning on November 28, 2010, 07:11:33 AM"],["t","Sorry, you misunderstand. The server operator only pays out to easy hashes that were submitted for a block that is won. There's no payout for easy hashes that were submitted for a block that someone else generates.\n\nThe difficulty can't change in the middle of a block. It always changes at a known time, and you always know exactly what the difficulty is, so there's no risk here."],["q","...you are dealing with probability here and not mathematical certainty...","Quote"],["t","That's absolutely true, but over time probability tends towards mathematical certainty. If the server operator is getting a few percent of the generated bitcoins, it doesn't take long to become virtually guaranteed profit."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25102#msg25102","sj":"Re: Cooperative mining"},{"f":"asdf","d":1290955498,"b":[["t","This is brilliant!\n\nIn the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one \"server\" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25106#msg25106","sj":"Re: Cooperative mining"},{"f":"grondilu","d":1290956142,"b":[["t","Am I the only one who thinks it would be way more simple to just rent distant shell access ??"]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25111#msg25111","sj":"Re: Cooperative mining"},{"f":"FreeMoney","d":1290958479,"b":[["q","This is brilliant!\n\nIn the future, when bock sizes are huge, this will save a lot of bandwidth and storage. Only one \"server\" node needs the blockchain and the fat bandwidth required to receive the flood of transactions. Many clients can then contribute to bitcoin without the need to pay for all that infrastructure multiple times. This means that small players can stay in the market and kind of solves the whole scaling problem. Awesome!","Quote from: asdf on November 28, 2010, 02:44:58 PM"],["t","Oh, I didn't even realize this. But it is correct I think. Only the header needs to be hashed. So this scheme has benefits beyond reducing the variance in generating. Very nice."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25115#msg25115","sj":"Re: Cooperative mining"},{"f":"farmer_boy","d":1290959898,"b":[["t","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.\n\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.\n\nForcing cooperation out of nodes is not easy. "]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25118#msg25118","sj":"Re: Cooperative mining"},{"f":"satoshi","d":1290960210,"b":[["t","ribuck's description is spot on.\n\nPool operators can modify their getwork to take one additional parameter, the address to send your share to.\n\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\n\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.\n\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.\n\nEither way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119","s":1,"n":517,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/517/","sj":"Re: Cooperative mining"}]},{"id":"p251","k":"p","s":"bitcointalk","t":"Is safe running bitcoins with the same wallet on more computers simultaneously?","u":"https://bitcointalk.org/index.php?topic=1986","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/251/","m":[{"f":"Aleš Janda","d":1290951852,"b":[["t","Hi,\n\nI would like to use bitcoins but I'm using more than one computer. Can I use just one wallet on all computers (by copying settings)? Or it isn't possible?\n\nWhat happened if someone send me money and bitcoin client run on more computers? What happened if I send money to anyone from one of clients? Will it be synchronized automatically?\n\nMaybe it's a simple quetsion but I didn't find answer to this.\nThanks."]],"u":"https://bitcointalk.org/index.php?topic=1986.msg25093#msg25093"},{"f":"BitLex","d":1290952764,"b":[["t","i've never tried it myself and wouldn't recommend to,\nin no way it's \"safe\", i guess it will cause some trouble sooner or later.\n\nif you just want to use your wallet (spend/receive coins) on multiple machines, there's ways to make it portable (i guess, also not tried yet).\n\nif you want to generate on multiple machines, that's possible by using a single client/wallet and multiple miners (GPU <http://bitcointalk.org/index.php?topic=1334.0>, CPU <http://bitcointalk.org/index.php?topic=1925.0>) running on the same, or multiple remote machines."]],"u":"https://bitcointalk.org/index.php?topic=1986.msg25099#msg25099"},{"f":"FreeMoney","d":1290959101,"b":[["t","I'm interested in hearing the problems with this. The current version generates a pool of 100 address, but are these used for receiving change? Maybe there could be an option for generating more than 100 addresses, and also for seeing how many you have left?\n\nIs there some other type of problem I'm overlooking?"]],"u":"https://bitcointalk.org/index.php?topic=1986.msg25116#msg25116"},{"f":"BitLex","d":1290960221,"b":[["t","the option to generate more addresses to the keypool already exists"],["c","# bitcoin.conf\n\n# Pre-generate this many public/private key pairs, so wallet backups will be valid for\n# both prior transactions and several dozen future transactions.\nkeypool=100"],["t","but as far as i understand, it's supposed to keep backups valid (for some time), not to sync multiple wallets.\ni have no idea how that would work in the long term."]],"u":"https://bitcointalk.org/index.php?topic=1986.msg25120#msg25120"},{"f":"satoshi","d":1290967599,"b":[["q","Will it be synchronized automatically?","Quote"],["t","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.\n\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).\n\nNew demonstration CPU miner available:\nhttp://bitcointalk.org/index.php?topic=1925.0"]],"u":"https://bitcointalk.org/index.php?topic=1986.msg25154#msg25154","s":1,"n":519,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/519/"}]},{"id":"p252","k":"p","s":"bitcointalk","t":"Incompatible wallet format with latest bitcoin-git ?","u":"https://bitcointalk.org/index.php?topic=2007","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/252/","m":[{"f":"davout","d":1291063546,"b":[["t","Hi all,\n\njust built the latest bitcoin-git source, seems like the wallet or database format has changed\n\n************************\nEXCEPTION: NSt8ios_base7failureE       \nCDataStream::read() : end of data       \nbitcoin in AppInit()       \n\nterminate called after throwing an instance of 'std::ios_base::failure'\n  what():  CDataStream::read() : end of data\n\nCould it be 84d7c981dc52cc738053 that broke something ?"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25457#msg25457"},{"f":"Gavin Andresen","d":1291064162,"b":[["t","I haven't tested my 'master' bitcoin-git branch in a while, I wouldn't be surprised if the new 'accounts' code in the subversion tree broke something.\n\nWhich not-in-subversion features are you using?"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25464#msg25464"},{"f":"jgarzik","d":1291064310,"b":[["q","Hi all,\n\njust built the latest bitcoin-git source, seems like the wallet or database format has changed\n\n************************\nEXCEPTION: NSt8ios_base7failureE       \nCDataStream::read() : end of data       \nbitcoin in AppInit()       \n\nterminate called after throwing an instance of 'std::ios_base::failure'\n  what():  CDataStream::read() : end of data\n\nCould it be 84d7c981dc52cc738053 that broke something ?","Quote from: davout on November 29, 2010, 08:45:46 PM"],["t","What are the lines in debug.log leading up to the end-of-file exception you pasted?"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25465#msg25465"},{"f":"davout","d":1291064848,"b":[["t","I have tested accounts, it works very well"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25468#msg25468"},{"f":"davout","d":1291064946,"b":[["t","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\n addresses               122ms\nLoading block index...\nLoadBlockIndex(): hashBestChain=00000000000013587f18  height=94571\n block index            1294ms\nLoading wallet...\n\n************************\nEXCEPTION: NSt8ios_base7failureE       \nCDataStream::read() : end of data       \nbitcoin in AppInit()       \n\nterminate called after throwing an instance of 'std::ios_base::failure'\n\n************************\nEXCEPTION: NSt8ios_base7failureE       \nCDataStream::read() : end of data       \nbitcoin in AppInit()       \n\n  what():  CDataStream::read() : end of data"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25471#msg25471"},{"f":"satoshi","d":1291143751,"b":[["t","What was this wallet used with?  An early accounts patch or git build?\n\nIt's while loading the wallet.  I assume it must be in this:\n\n    else if (strType == \"acentry\")\n    {\n        string strAccount;\n        ssKey >> strAccount;\n        uint64 nNumber;\n        ssKey >> nNumber;\n        if (nNumber > nAccountingEntryNumber)\n            nAccountingEntryNumber = nNumber;\n    }\n\nYou could check that with this:\n\n    else if (strType == \"acentry\")\n    {\n        string strAccount;\n        assert(!ssKey.empty());\n        ssKey >> strAccount;\n        uint64 nNumber;\n        if (ssKey.size() != 8 )\n            printf(\"***** %s %d\", strAccount.c_str(), ssKey.size());\n        assert(ssKey.empty() == false);\n        ssKey >> nNumber;\n        if (nNumber > nAccountingEntryNumber)\n            nAccountingEntryNumber = nNumber;\n    }\n\nWas there an interim version of accounts on git at some point that had just (\"acentry\", \"account\") for the key?\n\nIf you have gdb, you could run it in gdb and do a backtrace.\n\ngdb --args bitcoin ...\nrun\n(wait for exception)\nbt"]],"u":"https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799","s":1,"n":521,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/521/"}]},{"id":"p253","k":"p","s":"bitcointalk","t":"JSON-RPC method idea: list transactions newer than a given txid","u":"https://bitcointalk.org/index.php?topic=2151","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/253/","m":[{"f":"davux","d":1291828041,"b":[["t","It would be great to have a JSON-RPC method for listing new transactions that are newer than a particular transaction id. This would enable developpers to watch new transactions easily, by just keeping track of the latest known txid and polling that method at the rate of their choice.\n\nA possible way to do it would be to extend listttransactions so that it accepts an optional txid argument:"],["c","listtransactions <account> [count=10] [txid]"],["t","If txid is given, don't show it, nor any transaction older than it.\n\n(As a sidenote, maybe listtransactions, with or without txid, should accept filtering by transaction category: generate, send, receive, move.)\n\nI'm sorry I can't propose any patch here, as I can't do any decent C++."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28160#msg28160"},{"f":"nelisky","d":1291830241,"b":[["t","+1\n\nI haven't got my hands dirty there yet, and would rather spend what time I find to do import/export of keys, but that is something that would help some of my scripts a lot."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28167#msg28167"},{"f":"jgarzik","d":1291834862,"b":[["q","It would be great to have a JSON-RPC method for listing new transactions that are newer than a particular transaction id. This would enable developpers to watch new transactions easily, by just keeping track of the latest known txid and polling that method at the rate of their choice.","Quote from: davux on December 08, 2010, 05:07:21 PM"],["t","If we're adding code to watch for new transactions, then we should be including gavin's monitor patches:\nhttps://github.com/gavinandresen/bitcoin-git/tree/monitorreceived"]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28193#msg28193"},{"f":"genjix","d":1291839657,"b":[["t","Surely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?\n\nThen it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.\n\nCan anyone confirm this?"]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28227#msg28227"},{"f":"satoshi","d":1291839709,"b":[["t","It's not safe to use listtransactions this way.\n\nI know I've been criticized for being reluctant about listtransactions.  Let me explain my reluctance.\n\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.\n\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.\n\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.\n\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.\n\nNow that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28228#msg28228","s":1,"n":524,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/524/"},{"f":"jgarzik","d":1291839762,"b":[["q","Surely since the WalletTx are added sequentially to the wallet, we can assume that older txid's appear earlier in the wallet?\n\nThen it's simply trivial to do a linear lookup and then continue on spitting out the txid's after that one.","Quote from: genjix on December 08, 2010, 08:20:57 PM"],["t","The wallet is a key/value db4 database (and a key/value map in RAM).\n\nNeither data structure is ordered by time."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28229#msg28229"},{"f":"mikegogulski","d":1291840901,"b":[["t","I can see the motivation for davux's request. In developing the e-commerce plugins I've released, I've wondered about the viability long term of using a \"dump\" method against the wallet, since over time the data returned is just going to grow and grow.\n\nWhat I'd prefer is being able to attach a JSON-RPC callback URL to an account or an address, maybe to be invoked each time a confirmation or any other status change to that account or address comes in, until the callback is cleared. That would eliminate the need for polling the wallet entirely.\n\nI threw a \"feature request\" post in about that someplace."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28245#msg28245"},{"f":"jgarzik","d":1291841163,"b":[["q","I know I've been criticized for being reluctant about listtransactions.  Let me explain my reluctance.\n\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.\n\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.","Quote from: satoshi on December 08, 2010, 08:21:49 PM"],["t","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.\n\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).\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28247#msg28247"},{"f":"satoshi","d":1291847805,"b":[["t","Then how do you cope with the issues I listed in the message you quoted?"]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28292#msg28292","s":1,"n":525,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/525/"},{"f":"jgarzik","d":1291849642,"b":[["t","I think the important point is that these things are unavoidable unsafe after a certain point, even for listreceivedbyaddress.  So I think it's helpful to compare current website behavior under mainline bitcoin, with listtransactions.   Let us call this the confirmation point.  Addressing your queries..."],["q","1) How do you know if a past transaction becomes invalid and disappears?","Quote from: satoshi on December 08, 2010, 10:36:45 PM"],["t","bitcoinmarket and mtgox and other sites seem to consider 6 confirmations their \"confirmation point\", the moment at which a transaction may be considered \"safe.\" If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.\n\nSame for a web store or brick-and-mortar store.  There is a confirmation point at which the customer receives goods.  If a TX becomes invalid after that, the store takes an unavoidable loss, because the customer is already gone with the purchased goods."],["q","2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.","Quote from: satoshi on December 08, 2010, 10:36:45 PM"],["t","Let us assume that confirmation count for txid 0x1234 is bouncing wildly between 0 to 10 to 0 and back and forth, due to a large number of block reorgs.\n\nWhether it is listreceivedbyaddress or listtransactions, you still have a binary confirmation point, a moment in time, at which the transaction crosses the \"approved by store\" level of confidence.  At that confirmation point, the customer leaves with purchased goods, and store takes a loss regardless of further block chain or TX behavior.\n\nI do agree a programmer may make a mistake, and assume that number of confirmations will always increase.  But that human mistake, too, will cause danger when used with listreceivedbyaddress."],["q","3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.","Quote from: satoshi on December 08, 2010, 10:36:45 PM"],["t","On this point, I agree that listtransactions presents some additional danger here, due to changing txid, if and only if the new double-spend matches destination bitcoin address being sought by the JSON-RPC user.\n\nNevertheless, in this case too, the user's security rests entirely on their level of confidence:  if the TX is replaced before 6 confirmations, software will likely not notice anything.  If the TX is replaced after 6 confirmations, the customer has already left with purchased goods, and the bitcoin user takes a loss.\n\nThis is simply inherent to bitcoin itself.  A block chain reorg might happen after 50 blocks.  But websites do not want to make their users wait 50 blocks before receiving goods.  It is the well-known snack machine problem.  listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.\n\nTransactions can and will be replaced after the binary \"confirmation point.\"  All users of bitcoin must figure this into their business plans, just like they account for credit card chargeback risk or shoplifting risk."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28301#msg28301"},{"f":"davux","d":1291851659,"b":[["q","Any 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.","Quote from: satoshi on December 08, 2010, 08:21:49 PM"],["t","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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28307#msg28307"},{"f":"satoshi","d":1291853537,"b":[["t","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."],["q","2) When there's a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.","Quote from: satoshi on December 08, 2010, 10:36:45 PM"],["t","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.\n\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."],["q","> Quote from: satoshi on December 08, 2010, 10:36:45 PM\n> 3) A transaction can be replaced by a double-spend with a different txid.  You would count both spends.\n listtransactions does not add anything to this problem, beyond that which is already vulnerable through listreceivedbyaddress.","Quote from: jgarzik on December 08, 2010, 11:07:22 PM"],["t","Suppose both spends are to the same address.  getreceivedbyaddress would always count only one or the other spend at any given time, never both.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28313#msg28313","s":1,"n":527,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/527/"},{"f":"Gavin Andresen","d":1291855304,"b":[["t","I'll and add another reason not to have a \"list transactions that happened after <txid>\" :\n\nmove \"transactions\" don't have a transaction id, but they do affect account balances (and are listed in listtransactions).\n\nYour code is going to get really messy if you expect to call listtransactions and then squirrel away the txid of the last item returned.  If it was \"category\":\"move\",  there WILL be no txid...\n\nRE: eliminating polling:  at some point fairly soon, I plan on cleaning up my \"monitorreceived\" patch, to POST to a URL when transactions come in or blocks are accepted... but I need to do some Deep Thinking to redesign based on lessons learned from 'accounts'.  It might turn into a very minimal API, where the notification is \"Hey, txid <123ae4221...> just got to N confirmations, you might want to call gettransaction and getbalance to get up-to-date.\""]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28324#msg28324"},{"f":"jgarzik","d":1291856285,"b":[["q","I'll and add another reason not to have a \"list transactions that happened after <txid>\" :","Quote from: gavinandresen on December 09, 2010, 12:41:44 AM"],["t","I agree with you and satoshi about \"txs after <txid>\".  My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28330#msg28330"},{"f":"ribuck","d":1291895336,"b":[["q","If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.","Quote from: jgarzik on December 08, 2010, 11:07:22 PM"],["t","That's not always the case. Sometimes the customer will have a balance at the website. The operator of the website will certainly want to know if a past transactions becomes invalid and disappears."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28491#msg28491"},{"f":"jgarzik","d":1291911230,"b":[["q","> Quote from: jgarzik on December 08, 2010, 11:07:22 PM\n> If a past transaction becomes invalid and disappears, the website cannot avoid potential loss, because the user has already received their PayPal-USD or LR-USD or Pecunix GAU and disappeared.\n\nThat's not always the case. Sometimes the customer will have a balance at the website. The operator of the website will certainly want to know if a past transactions becomes invalid and disappears.","Quote from: ribuck on December 09, 2010, 11:48:56 AM"],["t","Sure, and that's easy enough to track with transactions."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28572#msg28572"},{"f":"satoshi","d":1291918088,"b":[["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.","Quote from: jgarzik on December 09, 2010, 12:58:05 AM"],["t","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.\n\nGavin, could listtransactions have an option to list transactions for all accounts?\n\nI'm not sure what the interface could be, maybe:\nlisttransactions <JSON null type> [count]\n\nIt would be hard to do that from the command line though.\n\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 \"*\"."],["q","Sure, and that's easy enough to track with transactions.","Quote from: jgarzik on December 09, 2010, 04:13:50 PM"],["t","I don't get how that's \"easy\" to track with transactions."]],"u":"https://bitcointalk.org/index.php?topic=2151.msg28640#msg28640","s":1,"n":530,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/530/"}]},{"id":"p254","k":"p","s":"bitcointalk","t":"Version 0.3.18","u":"https://bitcointalk.org/index.php?topic=2162","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/254/","m":[{"f":"satoshi","d":1291850364,"b":[["t","Changes:\n- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again\n- IsStandard() check to only include known transaction types in blocks\n- Jgarzik's optimisation to speed up the initial block download a little\n\nThe main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at http://bitcointalk.org/index.php?topic=1886.0).  \n- getaccountaddress\n- sendfrom\n- move\n- getbalance\n- listtransactions\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28302#msg28302","s":1,"n":526,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/526/"},{"f":"RHorning","d":1291851046,"b":[["t","This is the first update to Bitcion that I'm not jumping on and grabbing right away, because I think the choice of checking transaction types in blocks is not necessarily a good thing... at least while the question is undecided in the community.  It does impact the network but in a subtle and political way.\n\nAt the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts \"pure\".  All that has happened here is to simply lay the gauntlet down to get past the \"IsStandard()\" check and find transactions which can pass that test but still contain other data."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28304#msg28304"},{"f":"theymos","d":1291851702,"b":[["q","At the very least I wish that Satoshi would at least express his view on what he thinks about putting extra data into transactions beyond pure financial data into transactions, and I think this is only going to start an arms race for those who want to play with scripts and those who are trying to keep scripts \"pure\".  All that has happened here is to simply lay the gauntlet down to get past the \"IsStandard()\" check and find transactions which can pass that test but still contain other data.","Quote from: RHorning on December 08, 2010, 11:30:46 PM"],["t","Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions?"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28309#msg28309"},{"f":"theymos","d":1291854410,"b":[["t","ArtForz (15+% of the network), tcatm (2Ghash/s), and doublec (pool maintainer) have stated that they will not use IsStandard. Non-standard transactions will therefore still be possible.\n\nWhen I have time, I will produce a patch for Bitcoin that will remove all non-network-enforced restrictions on transactions, so that other miners can easily also be configured to include these transactions."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28317#msg28317"},{"f":"Cdecker","d":1291854951,"b":[["t","I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)\n\nI do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28319#msg28319"},{"f":"jgarzik","d":1291855097,"b":[["t","Please start your own block chain, rather than forking the network like this.\n\nI hope it is clear the havoc that your push to include non-currency data is causing."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28321#msg28321"},{"f":"nelisky","d":1291855553,"b":[["q","Please start your own block chain, rather than forking the network like this.\n\nI hope it is clear the havoc that your push to include non-currency data is causing.","Quote from: jgarzik on December 09, 2010, 12:38:17 AM"],["t","Wrong thread?"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28325#msg28325"},{"f":"Gavin Andresen","d":1291855725,"b":[["q","Yeah; it's pretty pointless. Why on Earth would any miner adopt this change, when it means that they will be getting fewer transaction fees due to the lost non-standard transactions?","Quote from: theymos on December 08, 2010, 11:41:42 PM"],["t","There's been exactly one block with non-standard transactions:\n  http://blockexplorer.com/b/71036\n... and it contained no fees.\n\nHOWEVER:  jgarzik, you're over-reacting, too.  This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid.  Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them.  There will be no havoc."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28326#msg28326"},{"f":"jgarzik","d":1291856230,"b":[["q","HOWEVER:  jgarzik, you're over-reacting, too.  This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid.  Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them.  There will be no havoc.","Quote from: gavinandresen on December 09, 2010, 12:48:45 AM"],["t","I never said it would cause a block chain split.  It's more fundamental: a rules split.\n\nForking the network implied a majority of miners not running mainline bitcoin transaction rules.  theymos appears to be drawing a line in the sand, where he wants to convince most miners to stop paying attention to mainline bitcoin transaction validation rules.  He's free to do that.  And miners are free to validate what they want to.\n\nBut this sort of split will make it more difficult to work on the network in the future, and de facto, opens the door to larding down the block chain with all sorts of non-currency-related data as being discussed in other threads."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28328#msg28328"},{"f":"RHorning","d":1291856362,"b":[["q","HOWEVER:  jgarzik, you're over-reacting, too.  This will not cause a block chain split; all clients will accept blocks containing non-standard transactions as valid.  Most (many?) just won't put non-standard transactions in blocks that they generate, and won't relay them.  There will be no havoc.","Quote from: gavinandresen on December 09, 2010, 12:48:45 AM"],["t","No, this isn't going to cause a block chain split, it is going to cause a fork of Bitcoin.  I just hope that is thought through very well, and I don't think it has been.\n\nSince transactions aren't being forwarded that fail the IsStandard() algorithm, those who want to put \"non-standard\" transactions into a bitcoin chain must either hard-connect to a miner who would accept these transactions or force some sort of ad-hoc way of setting up a second tier in the network to find nodes that will accept these kind of transactions AND likely put them into a future block.\n\nThat only one block may fail at the moment with this test is ignoring the current discussion where conceivably almost every block in the near future may have some form of these \"non-standard\" transactions."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28332#msg28332"},{"f":"slush","d":1291860950,"b":[["q","Please start your own block chain, rather than forking the network like this.\nI hope it is clear the havoc that your push to include non-currency data is causing.","Quote from: jgarzik on December 09, 2010, 12:38:17 AM"],["t","Agree. I don't see any reason why non standard, maybe non-financial transaction should be inside financial block chain. Also don't understand why major miners are going to fork client. I thought this software is about currency. So I'm absolutely OK with last release and I already updated all my miners.\n\nI'm definitely NOT against software based on chains and personally will support any BitDNS effort, but, please, keep bitcoin chain consistent."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28361#msg28361"},{"f":"da2ce7","d":1291862741,"b":[["t","Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped.\n\nEven later in the future, those who include extra things without compensation in their blocks will get their blocks orphaned by the chain.\n\nI for one will upgrade my client to v.18 until their come a time when it is profitable for me to accept non-standard transactions."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28370#msg28370"},{"f":"jgarzik","d":1291862908,"b":[["q","Transaction fees will pay for the generation of the chain in the future, therefore if the BitDNS guys (or any other group) want to include carefully crafted transactions in the chain, then they must include the appropriate compensation for the generators, or likely their transactions will be dropped.","Quote from: da2ce7 on December 09, 2010, 02:45:41 AM"],["t","That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28371#msg28371"},{"f":"jib","d":1291863037,"b":[["q","That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions.","Quote from: jgarzik on December 09, 2010, 02:48:28 AM"],["t","No, it'll disadvantage people who refuse to pay fees. What they're storing in their transactions is irrelevant."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28372#msg28372"},{"f":"da2ce7","d":1291863103,"b":[["q","That will disadvantage people who use bitcoins for reasons unrelated to storing data in the block chain -- ie. as cash as intended -- because the \"appropriate compensation\" will prioritize their non-currency transactions over currency transactions.","Quote from: jgarzik on December 09, 2010, 02:48:28 AM"],["t","No problem with that! It will increase the competitive nature of generation, making Bitcoin harder to attack, and encouraging improvements to the generation network to support more transactions (to maximize profit).\n\nYou've gotta love the free market!"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28373#msg28373"},{"f":"jgarzik","d":1291863461,"b":[["q","No, it'll disadvantage people who refuse to pay fees.","Quote from: jib on December 09, 2010, 02:50:37 AM"],["t","Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28375#msg28375"},{"f":"Judson","d":1291863726,"b":[["t","I applaude this decision.\n\nWhy would anyone want to muddle up their nice distributed currency system, free from complex regulation from governments, and add a DNS system on top of it? How hard would that be to explain to someone's mom, who (conceivably), could be using Bitcoin in the future?\n\nThere is plenty of transaction fees to be had when bitcoin builds a larger user base. We don't need non-standard transactions to make mining worthwhile\n\nThe simpler Bitcoin stays, the better IMO. "]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28376#msg28376"},{"f":"da2ce7","d":1291864152,"b":[["q","Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam.","Quote from: jgarzik on December 09, 2010, 02:57:41 AM"],["t","No, as no generators will want to block fee paying (profitable) transactions.\n\nWhen adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down.\n\nIn the long run, extra data in the chain will _reduce_ the relative cost of a currency-only transaction, because the currency-only transaction uses much less data, compared to the data transactions, per transaction."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28377#msg28377"},{"f":"jgarzik","d":1291864440,"b":[["q","> Quote from: jgarzik on December 09, 2010, 02:57:41 AM\n> Rather, it will increase everybody's fees, and incentivize creation of a currency-only chain without all the data spam.\n\nNo, as no generators will want to block fee paying (profitable) transactions.\n\nWhen adding non-currency data into the block chain becomes common, then the there will become a strong economic incentive to increase the block size as necessary. Thus keeping the transaction cost down.","Quote from: da2ce7 on December 09, 2010, 03:09:12 AM"],["t","Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain.  Increasing the block size does not reduce transaction fees."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28380#msg28380"},{"f":"da2ce7","d":1291865559,"b":[["q","Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain.  Increasing the block size does not reduce transaction fees.","Quote from: jgarzik on December 09, 2010, 03:14:00 AM"],["t","Sorry I have to disagree with you,  the transaction fees are based upon the 'cost' to generator to include the transaction.  The cost is directly related to the amount of data needed to be included.\n\nIn the future there will be no 'hard limits' on block size, only the risk that the block will be rejected and orphaned by the chain as it is to large.\n\nWhen a generator deciding what transactions to include, if the network is already profitable with very large blocks, (eg. 20mb+ as they have much non-currency data in them), then including very small 'currency' transactions have a minute cost. For example, 20,000,000 vs 20,000,010.\n\nIf the block chain is restricted to just currency data, there is much less incentive to improve the efficiency of handling large blocks data.  Therefore the relative cost will be much greater... 500,000 vs 500,010. Therefore the transaction fees required for small amounts of data are likely to be higher on a system that only induces currency data."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28383#msg28383"},{"f":"jgarzik","d":1291866366,"b":[["q","> Quote from: jgarzik on December 09, 2010, 03:14:00 AM\n> Currency transactions would have to fight harder -- pay more fees -- to make sure they're processed in a timely fashion, due to all the non-currency data in the block chain.  Increasing the block size does not reduce transaction fees.\n\nSorry I have to disagree with you,  the transaction fees are based upon the 'cost' to generator to include the transaction.  The cost is directly related to the amount of data needed to be included.","Quote from: da2ce7 on December 09, 2010, 03:32:39 AM"],["t","This is not an opinion; read the source.  Transaction fees vary on total block size, not just transaction size.\n\nThus, larger blocks == higher fees.\n\nThus, more data spam, or more overall network traffic (currency or not) == higher fees."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28387#msg28387"},{"f":"da2ce7","d":1291867628,"b":[["q","This is not an opinion; read the source.  Transaction fees vary on total block size, not just transaction size.","Quote from: jgarzik on December 09, 2010, 03:46:06 AM"],["t","Yes, that is what the source says for the moment, in the future I do not expect the generators to just arbitrarily follow the current rules, rather I expect the generators to be quite discerning in what rules they enforce or ignore.\n\nYes, larger block will be more expensive, (eg. bandwidth, and risk of rejection costs), but as the average amount of data in the blocks increase, the _relative_ cost per data amount will go down."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28391#msg28391"},{"f":"jgarzik","d":1291868994,"b":[["t","These experiments are better suited for an alternate network and block chain.  Leave the currency as a currency, and preserve the investments that many have already made in bitcoin.\n\nIt could be as simple as a patch that accepts \"-datanet\" and non-standard transactions, such as\nhttp://yyz.us/bitcoin/patch.bitcoin-datanet-fork\n\n(warning: demonstration patch, do not use; you would want a real genesis block for a production network)"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28397#msg28397"},{"f":"nanotube","d":1291875545,"b":[["t","consider also that it's possible to encode data into the bitcoin blockchain already, merely by specially crafting the transaction. (See the 'first' option on http://privwiki.dreamhosters.com/wiki/Bitcoin_DNS_System_Proposal#Overcoming_potential_resistance_bitcoin_developers.2Fcommunity ).\n\nalternatively, only timestamping and proof of expense (i.e., a regular transaction with a fee) may be used, pushing off the actual data storage off to external service (see 'third' option, ibid.)\n\nbut why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28434#msg28434"},{"f":"davout","d":1291878630,"b":[["q","I guess we have the first official release that is disputed by the majority of computation power, Bitcoin's coming off age :-)\n\nI do however like that the changes are communicated in an open and unbiased way. One thing that would be nice is to have links to the particular Threads, Checkins, whatever to be able to track/understand changes more easily.","Quote from: Cdecker on December 09, 2010, 12:35:51 AM"],["t","You already have that"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28447#msg28447"},{"f":"chaord","d":1291879032,"b":[["q","but why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction? it seems that in the net, these side-band uses of bitcoin will only serve to increase the security of the network, by increasing the mining incentive, and bringing on more generation power.","Quote from: nanotube on December 09, 2010, 06:19:05 AM"],["t","I personally agree with nanotube's point here, especially in light of the fact that arbitrary data can already be disguised in standard transactions if a person is motivated enough.  I have not looked at the source code, but from what I understand I think that a much more pleasant (politically and technically speaking) solution would be to:\n\nby default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?\n\nI would like to hear why the above option was thrown out by the developers.\n\nWhile I agree that bitcoin transactions themselves should be the primary use of the blockchain,  a good currency need not ostracize itself either."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28448#msg28448"},{"f":"theymos","d":1291882639,"b":[["q","by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?","Quote from: chaord on December 09, 2010, 07:17:12 AM"],["t","I would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to \"legislate\" any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to:\n- Remove the restrictions to get more fees\n- Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections.\n\nThe restriction on relaying these transactions should be removed, at the very least."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28456#msg28456"},{"f":"jgarzik","d":1291883907,"b":[["q","> Quote from: chaord on December 09, 2010, 07:17:12 AM\n> by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?\n\nI would be happy with 128 bytes of arbitrary data. But it seems pointless for the official Bitcoin client to attempt to \"legislate\" any restrictions of this type when all miners have an interest in including any and all fee-carrying transactions. As long as these restrictions exist, miners are incentivized to:\n- Remove the restrictions to get more fees\n- Connect to as many peers as possible to get a higher chance of catching any non-standard transactions that would be produced, further increasing the load on those few nodes accepting incoming connections.","Quote from: theymos on December 09, 2010, 08:17:19 AM"],["t","...unless the use of bitcoin for non-currency purposes discourages currency use.  Some uses of the network can act as an overall disincentive against mainstream use.  If people see that miners care little for currency transactions on the bitcoin network, or all the data spam increases TX fees to annoying levels, currency users will find a new network elsewhere.  If people find out law-enforcement-objectionable data such as \"kiddie-pr0n.p2p DNS data\" is being managed on this network, that increases the incentive for currency users to go elsewhere.\n\nMaybe that makes some miners happy in the short term, and you happy, but I'm here for the revolutionary new type of digital cash.\n\nAnd this generalized data timestamping/notary service seems like it has the distinct probability of degrading service for digital cash, if it is even remotely successful."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28458#msg28458"},{"f":"sturle","d":1291884905,"b":[["q","> Quote from: chaord on December 09, 2010, 07:17:12 AM\n> by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?\nI would be happy with 128 bytes of arbitrary data.","Quote from: theymos on December 09, 2010, 08:17:19 AM"],["t","I introduced six persons to bitcoins yesterday, and one so far today, by giving them 20 BTC each for a promise to put the coins into circulation.  They all had the same complaint:  It took ages, for one of them almost two hours, to download the initial blocks!\n\nIt doesn't get any faster by adding junk to the blocks.  I don't get it?  Why is it so important for people here to make Bitcoins slow and inefficient?\n\nFees?  Come on, miners!  How much do you make from fees?"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28460#msg28460"},{"f":"da2ce7","d":1291886161,"b":[["q","Fees?  Come on, miners!  How much do you make from fees?","Quote from: sturle on December 09, 2010, 08:55:05 AM"],["t","Not much,  Grin  I've made about 0.5 BTC from fees.  It is just too profitable to just mine for the hell of it, I get 50 BTC each time I make a block, and (if I'm very lucky, I make 0.05 BTC from fees).\n\nAbout the large chain size, this isn't a issue, in the future it will be possible to 'prune' the chain with balances. This will reduced the size by a vast amount.  When extra data is included in the chain, it is likely to be forgotten by (most) the network if it stops being important.\n\nFor example, the BitDns guys will keep a relocation of a the DNS data for ages, however the banks are likely to just keep the bitcoin currency transfer data and drop the rest."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28465#msg28465"},{"f":"m0mchil","d":1291886436,"b":[["t","There are many questions still unclear about bitcoin. We have yet to see a lightweight client, freed of the block chain's burden. We still have to see how the TX fee market will develop. There is uncertainty about what the average number of transactions per minute would be in, say, two years.\n\nDistributed DNS using bitcoin concepts is really cool. But isn't this a separate currency/commodity? Why not create a separate chain for it? Why force bitcoin users to support services they aren't aware of?\n\nWhat if I want only BitDNS? And I don't need the payments stuff?"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28466#msg28466"},{"f":"Timo Y","d":1291886466,"b":[["q","You've gotta love the free market!","Quote from: da2ce7 on December 09, 2010, 02:51:43 AM"],["t","We should not trust the \"free market\" blindly.\n\nThe problem is that including a lot of data in a block creates costs, not just for the miner who includes the data, but for all other miners and all other users, for all eternity.\n\nIn the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee only compensates the miner's costs.\n\nAs long as this tragedy of the commons situation hasn't been sorted out, the free market won't fix anything."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28467#msg28467"},{"f":"da2ce7","d":1291888952,"b":[["q","In the current implementation, the user is passing on the costs to the miner, and the miner is passing on the costs to the rest of the network. However, the user's transaction fee only compensates the miner's costs.","Quote from: forever on December 09, 2010, 09:21:06 AM"],["t","Current implementations, in the future the clients will only keep the stuff they care about.  The DNS client will keep the DNS stuff, the bitcoin currency traders will keep the currency transactions.\n\nLet the generators worry about the chain; if bitcoins become worthless, then they will not have any incentive to generate!\n\nI for one have lots of faith in the free market, after all I'm a laissez-faire capitalist  Grin,  I will be voting will my generation.  I suggest you invest in more that 50% of the generation network (or with like minded people), and ignore my the block I generate if you disagree with the data they contain.  That is the life in a free market.\n\nWhen we all bought into bitcoin, we all knew that then network is dictated by the majority of generation power.  All I'm arguing is that the generators will look out for their best interests, and their interests happen to fit very nicely with bitcoin: A strong bitcoin currency."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28471#msg28471"},{"f":"da2ce7","d":1291889258,"b":[["t","I propose a law:\n\n\"He who makes the chain, gets to decide what it looks like\""]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28473#msg28473"},{"f":"sturle","d":1291892267,"b":[["q","I propose a law:\n\n\"He who makes the chain, gets to decide what it looks like\"","Quote from: da2ce7 on December 09, 2010, 10:07:38 AM"],["t","This could work combined with:\n\"Everyone can choose to accept a block or discard it\"\n\nI don't want everyone to be spammed by blocks full of junk, and prefer to try to nullify it by generating a competing block without including the junk.  The junk will of course make it eventually, unless the majority of miners switch on their spam filters."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28479#msg28479"},{"f":"ShadowOfHarbringer","d":1291902680,"b":[["t","Well I spport Satoshi completely in this matter.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28519#msg28519"},{"f":"satoshi","d":1291905425,"b":[["t","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.\n\nTimestamp hashes are still already possible:\n\ntxin: 0.01\ntxout: 0.00  <appid, hash> OP_CHECKSIG\nfee: 0.01\n\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.\n\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:"],["q","I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.\n\nThe money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file's existence.\n\nI understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.","Quote from: Hal on December 05, 2010, 11:43:56 PM"]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28533#msg28533","s":1,"n":528,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/528/"},{"f":"Gavin Andresen","d":1291906267,"b":[["q","by default disallow non-standard transactions that exceed 128 bytes (or whatever threshold is agreeable)?\n\nI would like to hear why the above option was thrown out by the developers.","Quote from: chaord on December 09, 2010, 07:17:12 AM"],["t","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.\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28539#msg28539"},{"f":"satoshi","d":1291907873,"b":[["t","I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added."],["q","why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?","Quote from: nanotube on December 09, 2010, 06:19:05 AM"],["t","That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2162.msg28549#msg28549","s":1,"n":529,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/529/"}]},{"id":"p255","k":"p","s":"bitcointalk","t":"Fees in BitDNS confusion","u":"https://bitcointalk.org/index.php?topic=2181","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/255/","m":[{"f":"galeru","d":1291923938,"b":[["t","A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that.  How will I, the user, figure out what sort of fees have to go into a transaction?"]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28669#msg28669"},{"f":"jgarzik","d":1291924262,"b":[["q","A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that.  How will I, the user, figure out what sort of fees have to go into a transaction?","Quote from: galeru on December 09, 2010, 07:45:38 PM"],["t","For currency transactions, if you notice your transactions taking a long time to confirm, you increase the TX fee.\n\nFor non-currency transactions, it sounds like there will be some sort of fee schedule.  The software that generates these special, non-currency transactions would likely have a user-friendly interface to indicate the cost."]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28672#msg28672"},{"f":"RHorning","d":1291927860,"b":[["t","It would be nice if there was some way that using the standard client you might be able to adjust the fee schedule for your own purposes and set \"policies\" for mining blocks and including transactions.  I think that is a source of confusion here as no such user interface is currently provided for doing that.\n\nMuch of this is all theoretical at the moment because it is possible to make transactions \"for free\" and generally get them included in the next block at the moment.  I don't see that is going to be sustainable in the long run, but we'll see how that goes.  At the moment, it is important that most people using Bitcoins are simply hoping that the currency succeeds at all and aren't interested in making a killing or even a modest profit at it, which is why transaction fees are still mostly non-existent on the network."]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28693#msg28693"},{"f":"davout","d":1291928935,"b":[["t","Just wondering about the following example :\nI broadcast a transaction, sending X coins to some address.\nDoesn't get included in blocks for a while because I don't include a fee.\n\nDo I have a way to cancel it and broadcast it again with a fee this time ?"]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28699#msg28699"},{"f":"RHorning","d":1291930918,"b":[["q","Just wondering about the following example :\nI broadcast a transaction, sending X coins to some address.\nDoesn't get included in blocks for a while because I don't include a fee.\n\nDo I have a way to cancel it and broadcast it again with a fee this time ?","Quote from: davout on December 09, 2010, 09:08:55 PM"],["t","Yes, although I don't think the canceled transaction protocol is necessarily complete in terms of its current implementation.\n\nSee also: http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1#tx\n\nThe \"version\" field allows somebody to send out a new transaction that effectively replaces an existing transaction with perhaps some new data.  As long as the transaction hasn't been accepted into a block, in theory you can \"recall\" the transaction and modify the transaction in any way.  Like I said, this is incomplete and the exact protocol to pull that off hasn't been included into Bitcoin yet.  But it certainly is a possibility and may be a feature in a future version of Bitcoin.\n\nCertainly the ability to \"recall\" a transaction hasn't been implemented yet in the UI, and once the transaction has been accepted into a block the only hope to really kill a transaction after that is to hope that the block doesn't get accepted into the main block chain.  Then again, if the transaction has been accepted into a block without fees it shouldn't be a problem in terms of recalling the transaction for adding fees either as the issue is moot at that point."]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28704#msg28704"},{"f":"jgarzik","d":1291936024,"b":[["q","Just wondering about the following example :\nI broadcast a transaction, sending X coins to some address.\nDoesn't get included in blocks for a while because I don't include a fee.\n\nDo I have a way to cancel it and broadcast it again with a fee this time ?","Quote from: davout on December 09, 2010, 09:08:55 PM"],["t","See the discussion of locktime <http://bitcointalk.org/index.php?topic=1786.msg22119#msg22119> for transaction replacement."]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28719#msg28719"},{"f":"satoshi","d":1291939134,"b":[["t","Not locktime.\n\nThere's a possible design for far in the future:\n\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.\n\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.\n\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."]],"u":"https://bitcointalk.org/index.php?topic=2181.msg28729#msg28729","s":1,"n":534,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/534/"}]},{"id":"p256","k":"p","s":"bitcointalk","t":"minimalistic bitcoin client on D language?","u":"https://bitcointalk.org/index.php?topic=2188","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/256/","m":[{"f":"bitcoinex","d":1291972953,"b":[["t","I think to start writing a minimalistic bitcoin client on D language. Do you think this makes sense?"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28818#msg28818"},{"f":"grondilu","d":1291973288,"b":[["q","I think to start writing a minimalistic bitcoin client on D language. Do you think this makes sense?","Quote from: bitcoinex on December 10, 2010, 09:22:33 AM"],["t","The more implementations we have, the better.\n\nUnfortunately, writting a client is no easy task.   Satoshi's code is far from from trivial."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28819#msg28819"},{"f":"bitcoinex","d":1291976836,"b":[["t","Maybe then wait bitdns?\n\nI'm just bored and a want to write a code"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28826#msg28826"},{"f":"davout","d":1291977423,"b":[["t","If you're bored you should learn some Ruby it's really sweet !"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28829#msg28829"},{"f":"Cryptoman","d":1291994793,"b":[["t","+1 on Ruby.  Didn't someone recently write a Ruby interface to bitcoind?"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28885#msg28885"},{"f":"davout","d":1291994945,"b":[["t","I wrote a bitcoin daemon wrapper in Ruby\nFully extensible since it's heavily based on method missing\n\nEDIT : Made it for Rails so it includes a lovely initializer and a sweet yml configuration file"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28886#msg28886"},{"f":"bitcoinex","d":1292001071,"b":[["t","I do not like ruby, python, perl or java  Angry"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28906#msg28906"},{"f":"wumpus","d":1292001192,"b":[["t","You want to re-implement the entire client?\n\nWhy make a convenient wrapper around the JSON API? That's much easier and just as useful."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28908#msg28908"},{"f":"Cryptoman","d":1292002041,"b":[["q","I wrote a bitcoin daemon wrapper in Ruby\nFully extensible since it's heavily based on method missing\n\nEDIT : Made it for Rails so it includes a lovely initializer and a sweet yml configuration file","Quote from: davout on December 10, 2010, 03:29:05 PM"],["t","I'll have to spend some time playing with it over the winter break.  Any thoughts on keeping a server running bitcoind relatively secure?  It seems like having a wallet.dat file on a publicly-accessible server is an accident waiting to happen."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28916#msg28916"},{"f":"Cryptoman","d":1292002206,"b":[["q","I do not like ruby, python, perl or java  Angry","Quote from: bitcoinex on December 10, 2010, 05:11:11 PM"],["t","Well, I don't like C or Java or anything else that uses braces.  Tongue"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28918#msg28918"},{"f":"davout","d":1292013235,"b":[["q","python","Quote from: bitcoinex on December 10, 2010, 05:11:11 PM"],["t","I don't like IndentationErrors"],["q","perl","Quote from: bitcoinex on December 10, 2010, 05:11:11 PM"],["t","Not gonna criticize what I don't know"],["q","or java  Angry","Quote from: bitcoinex on December 10, 2010, 05:11:11 PM"],["t","I'll leave you the bob = new InstanceLocatorFactoryProxyWrapper<GenericInstanceBuilder>();\n\nSmiley"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28968#msg28968"},{"f":"bitcoinex","d":1292014416,"b":[["q","You want to re-implement the entire client?\n\nWhy make a convenient wrapper around the JSON API? That's much easier and just as useful.","Quote from: witchspace on December 10, 2010, 05:13:12 PM"],["t","It's pointless, I think. There is may be a \"multidimensional\" result.\n\nUse jsawk:"],["c","$ ./bitcoin listreceivedbylabel | jsawk -n 'out(this.label+\" \"+this.amount+\" \"+this.confirmations)'\nuser_id:1080 106 5189\nuser_id:1081 0.05 5557\nuser_id:1083 2.89 2800\nuser_id:1087 500 5276\nuser_id:1105 0.4 462\nuser_id:1109 0.1 922\nuser_id:1110 0.04 431"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28976#msg28976"},{"f":"davout","d":1292014864,"b":[["q","You want to re-implement the entire client?\n\nWhy make a convenient wrapper around the JSON API? That's much easier and just as useful.","Quote from: witchspace on December 10, 2010, 05:13:12 PM"],["t","It's just not as fun ! Cheesy\nI would love a ruby bitcoin client so much !!"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg28979#msg28979"},{"f":"farmer_boy","d":1292021023,"b":[["t","Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this. "]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29020#msg29020"},{"f":"ribuck","d":1292022281,"b":[["q","Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.","Quote from: farmer_boy on December 10, 2010, 10:43:43 PM"],["t","I bet you're also shocked by what restaurant kitchens look like, and by what goes into sausages."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29025#msg29025"},{"f":"farmer_boy","d":1292023150,"b":[["q","> Quote from: farmer_boy on December 10, 2010, 10:43:43 PM\n> Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.\n\nI bet you're also shocked by what restaurant kitchens look like, and by what goes into sausages.","Quote from: ribuck on December 10, 2010, 11:04:41 PM"],["t","No, I happen to be aware of that, and that's why I usually try to eat at places with a semi-open kitchen.\n\nThe cryptography code that competent people use, doesn't look like a mess, btw. That 99% of the world uses this kind of obfuscated cryptography only shows that users don't know what they use. Have you ever looked at TrueCrypt for example? It's the exact same kind of mess."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29027#msg29027"},{"f":"Cdecker","d":1292030373,"b":[["t","Here we are with the Language war once again. Please just stop!\n\nAs for the topic, yes please get an alternative implementation started, the more the merrier Smiley\nMaybe some good code actually makes it out there, helping future generations of clients to build on top of your code.\n\n+1 on the D implementation (I'm starting a Java one in the holidays)"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29047#msg29047"},{"f":"Hal","d":1292098125,"b":[["q","Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.","Quote from: farmer_boy on December 10, 2010, 10:43:43 PM"],["t","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."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29223#msg29223"},{"f":"wumpus","d":1292098264,"b":[["q","Another client is useful, especially since the current Bitcoin client is a big mess. I was *shocked* that cryptography code looked like this.","Quote from: farmer_boy on December 10, 2010, 10:43:43 PM"],["t","Can you be more specific? What exactly makes it a 'mess'?"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29225#msg29225"},{"f":"chaord","d":1292098288,"b":[["t","+1 on scala if you're bored Wink"]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29226#msg29226"},{"f":"grondilu","d":1292102751,"b":[["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.","Quote from: Hal on December 11, 2010, 08:08:45 PM"],["t","I agree.  Actually I'm amazed this is the product of only one person's work."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29246#msg29246"},{"f":"ribuck","d":1292103974,"b":[["t","It's easy to complain about code. But unless a person can show that they did something better, they have no moral authority to complain."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29253#msg29253"},{"f":"satoshi","d":1292105224,"b":[["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.","Quote from: Hal on December 11, 2010, 08:08:45 PM"],["t","That means a lot coming from you, Hal.  Thanks."]],"u":"https://bitcointalk.org/index.php?topic=2188.msg29259#msg29259","s":1,"n":541,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/541/"}]},{"id":"p257","k":"p","s":"bitcointalk","t":"Accounts example code","u":"https://bitcointalk.org/index.php?topic=2202","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/257/","m":[{"f":"satoshi","d":1292008863,"b":[["t","Some sample pseudocode using the new Accounts based commands in 0.3.18.\n\nprint \"send to \" + getaccountaddress(username) + \" to fund your account\"\nprint \"balance: \" + getbalance(username, 0)\nprint \"available balance: \" + getbalance(username, 6)\n\n// if you make a sale, move the money from their account to your \"\" account\nif (move(username, \"\", amount, 6, \"purchased item\"))\n    SendTheGoods()\n\n// withdrawal\nsendfrom(username, bitcoinaddress, amount, 6, \"withdrawal by user\")\n\nYou can use listtransactions(username) to show them a list of their recent transactions."]],"u":"https://bitcointalk.org/index.php?topic=2202.msg28947#msg28947","s":1,"n":536,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/536/"}]},{"id":"p258","k":"p","s":"bitcointalk","t":"Bitcoin and buffer overflow attacks","u":"https://bitcointalk.org/index.php?topic=2208","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/258/","m":[{"f":"da2ce7","d":1292046562,"b":[["t","I am convinced that the foundation of bitcoin (ie. the block chain) is secure from any non-nationally funded attack.  The only attack that makes me scared is a buffer overflow attack that steals the private keys in the wallet, however doesn't spend them.\n\nIf a significantly large attack happens to the block chain, we can always make a new branch that doesn't include the attack; with the theft of private keys, there is no easy recovery option, save (in the case of a massive attack), starting the block chain from 0 again.\n\nAs I'm not a security expert, I do not know how secure bitcoin is against this sort of attack.  However from my non-expert understanding direct to IP address transfers seems like a obvious surface area to attack.\n\nTwo questions: what attack areas dose the current bitcoin software have that could enable the theft of bitcoin private keys?\nSecondly, what efforts can be taken to minimize the attack surface area of bitcoin?"]],"u":"https://bitcointalk.org/index.php?topic=2208.msg29095#msg29095"},{"f":"grondilu","d":1292046760,"b":[["q","I am convinced that the foundation of bitcoin (ie. the block chain) is secure from any non-nationally funded attack.  The only attack that makes me scared is a buffer overflow attack that steals the private keys in the wallet, however doesn't spend them.\n\nIf a significantly large attack happens to the block chain, we can always make a new branch that doesn't include the attack; with the theft of private keys, there is no easy recovery option, save (in the case of a massive attack), starting the block chain from 0 again.\n\nAs I'm not a security expert, I do not know how secure bitcoin is against this sort of attack.  However from my non-expert understanding direct to IP address transfers seems like a obvious surface area to attack.\n\nTwo questions: what attack areas dose the current bitcoin software have that could enable the theft of bitcoin private keys?\nSecondly, what efforts can be taken to minimize the attack surface area of bitcoin?","Quote from: da2ce7 on December 11, 2010, 05:49:22 AM"],["t","I've always thought that the only known possible attacks could allow double spendin or freeze the whole network.\n\nI doubt any attack could steal private keys, apart from conventionnal attacks to the file system.\n\nBut I'm not an expert at all."]],"u":"https://bitcointalk.org/index.php?topic=2208.msg29096#msg29096"},{"f":"da2ce7","d":1292047418,"b":[["t","this isn't about protocol attacks, eg double spend and freezing.  Rather implementation security weaknesses."]],"u":"https://bitcointalk.org/index.php?topic=2208.msg29097#msg29097"},{"f":"wumpus","d":1292061580,"b":[["t","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#, ...)."]],"u":"https://bitcointalk.org/index.php?topic=2208.msg29124#msg29124"},{"f":"satoshi","d":1292074357,"b":[["q","direct to IP address transfers seems like a obvious surface area to attack.","Quote from: da2ce7 on December 11, 2010, 05:49:22 AM"],["t","If you ever find anyone who turned it on.  It's disabled by default."],["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#, ...).","Quote from: witchspace on December 11, 2010, 09:59:40 AM"],["t","It's all STL.  There are almost no buffers."]],"u":"https://bitcointalk.org/index.php?topic=2208.msg29165#msg29165","s":1,"n":540,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/540/"}]},{"id":"p259","k":"p","s":"bitcointalk","t":"PC World Article on Bitcoin","u":"https://bitcointalk.org/index.php?topic=2216","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/259/","m":[{"f":"Anonymous","d":1292100379,"b":[["t","adg"]],"u":"https://bitcointalk.org/index.php?topic=2216.msg29237#msg29237","sj":"dfg"},{"f":"Bimmerhead","d":1292101771,"b":[["t","I think this must be the highest Alexa ranking site yet to cite bitcoin.\n\nBTW you have a pm."]],"u":"https://bitcointalk.org/index.php?topic=2216.msg29241#msg29241"},{"f":"grondilu","d":1292101865,"b":[["q","It was published right before the forum went down for a few hours haha.","Quote from: davidonpda on December 11, 2010, 08:46:19 PM"],["t","Was it ?   It's certainly correlated, then.  The amount of new visitors blew up the bitcoin website.\n\nThanks for pointing it out."]],"u":"https://bitcointalk.org/index.php?topic=2216.msg29242#msg29242"},{"f":"Timo Y","d":1292107495,"b":[["t","This article is surprisingly balanced and accurate for a mainstream publication.\n\nPC World is a big deal. I am psycheless. Time to restore the Wikipedia article."]],"u":"https://bitcointalk.org/index.php?topic=2216.msg29267#msg29267"},{"f":"satoshi","d":1292110756,"b":[["t","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."]],"u":"https://bitcointalk.org/index.php?topic=2216.msg29280#msg29280","s":1,"n":542,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/542/","qt":["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."],"qc":["general"]}]},{"id":"p260","k":"p","s":"bitcointalk","t":"Added some DoS limits, removed safe mode (0.3.19)","u":"https://bitcointalk.org/index.php?topic=2228","su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/threads/260/","m":[{"f":"satoshi","d":1292178153,"b":[["t","There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas.  The build for this is version 0.3.19.\n\n- Added some DoS controls\nAs Gavin and I have said clearly before, the software is not at all resistant to DoS attack.  This is one improvement, but there are still more ways to attack than I can count.  \n\nI'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.\n\n- Removed \"safe mode\" alerts\n\"safe mode\" alerts was a temporary measure after the 0.3.9 overflow bug.  We can say all we want that users can just run with \"-disablesafemode\", but it's better just not to have it for the sake of appearances.  It was never intended as a long term feature.  Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.\n\nBuilds:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/"]],"u":"https://bitcointalk.org/index.php?topic=2228.msg29479#msg29479","s":1,"n":543,"su":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/543/"}]},{"k":"x","s":"adam-back","t":"Citation of your Hashcash paper","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/1.md","m":[{"f":"Satoshi Nakamoto","d":1219253439,"b":[["t","I’m getting ready to release a paper that references your Hashcash paper and I wanted to make sure I have the citation right.  Here’s what I have:\n\n[5] A. Back, “Hashcash - a denial of service counter-measure,”\nhttp://www.hashcash.org/papers/hashcash.pdf, 2002.\n\nI think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to make e-cash work.  You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-pdf.html  Feel free to forward it to anyone else you think would be interested.  I’m also nearly finished with a C++ implementation to release as open source.\n\nTitle: Electronic Cash Without a Trusted Third Party\nAbstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without the burdens of going through a financial institution.  Digital signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to prevent double-spending.  We propose a solution to the double-spending problem using a peer-to-peer network. 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.  The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.  As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers.  The network itself requires minimal structure. 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.\n\nsatoshi@anonymousspeech.com"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/1.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/1.md","to":"adam@cypherspace.org","fe":"satoshi@anonymousspeech.com","s":1,"od":"Wed 8/20/2008 6:30:39 PM (UTC+01:00); Adam Back's copy, COPA v Wright exhibit AB1"},{"f":"Adam Back","d":1219323359,"b":[["t","Yes citation looks fine, I’ll take a look at your paper.  You maybe aware of the “B-money” proposal, I guess google can find it for you, by Wei Dai which sounds to be somewhat related to your paper.  (The b-money idea is just described concisely on his web page, he didnt write up a paper).\n\nAdam"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/2.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/2.md","to":"satoshi@anonymousspeech.com","fe":"adam@cypherspace.org","sj":"Re: Citation of your Hashcash paper","od":"Thu 8/21/2008 1:55:59 PM (UTC+01:00); Adam Back's copy, COPA v Wright exhibit AB1"},{"f":"Satoshi Nakamoto","d":1219341589,"b":[["t","Thanks, I wasn’t aware of the b-money page, but my ideas start from exactly that point.  I’ll e-mail him to confirm the year of publication so I can credit him.\n\nThe main thing my system adds is to also use proof-of-work to support a distributed timestamp server.  While users are generating proof-of-work to make new coins for themselves, the same proof-of-work is also supporting the network timestamping.  This is instead of Usenet.\n\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/3.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/3.md","to":"adam@cypherspace.org","fe":"satoshi@anonymousspeech.com","s":1,"sj":"RE: Citation of your Hashcash paper","od":"Thu 8/21/2008 6:59:49 PM (UTC+01:00); Adam Back's copy, COPA v Wright exhibit AB1"},{"f":"Adam Back","d":1219342637,"b":[["t","Sorry still not read your paper yet, but another related paper is by Rivest et al called micromint, which uses k-way collisions to create an over-time computational advantage for the bank in creating coins.  What you said about one group of players having an advantage (by compute cycles) reminded me of micromint.  In micromint the bank gets an increasing advantage over time as there is some cumulative build up of advantage in terms of the partial results accumulated helping create further the partial-collisions more cheaply.\n\nAdam"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/4.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/4.md","to":"satoshi@anonymousspeech.com","fe":"adam@cypherspace.org","sj":"Re: Citation of your Hashcash paper","od":"Thu 8/21/2008 7:17:17 PM (UTC+01:00); Adam Back's copy, COPA v Wright exhibit AB1"},{"f":"Satoshi Nakamoto","d":1231613205,"b":[["t","Thanks for the pointers you gave me to Wei Dai’s b-money paper and others.\n\nI just released the open source implementation of my paper, Bitcoin v0.1.  Details, download and screenshots are at www.bitcoin.org\n\nThe main idea of the system is the generation of a chain of hash based proof-of-work to create self evident proof of the majority consensus.  Users get new coins by contributing proof-of-work to the chain.\n\nThere was a discussion of the design on the Cryptography mailing list.  Hal Finney gave a good high-level overview:\n\nOne thing I might mention is that in many ways bitcoin is two independent ideas: a way of solving the kinds of problems James lists here, of creating a globally consistent but decentralized database; and then using it for a system similar to Wei Dai’s b-money (which is referenced in the paper) but transaction/coin based rather than account based. Solving the global, massively decentralized database problem is arguably the harder part, as James emphasizes. The use of proof-of-work as a tool for this purpose is a novel idea well worth further review IMO.\n\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/5.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/adam-back/5.md","to":"adam@cypherspace.org","fe":"satoshi@vistomail.com","s":1,"sj":"Re: Citation of your Hashcash paper","od":"Sat 1/10/2009 6:46:45 PM (UTC); Adam Back's copy, COPA v Wright exhibit AB1"}],"id":"x1"},{"k":"x","s":"wei-dai","t":"Citation of your b-money page","u":"https://www.bitcoin.com/satoshi-archive/emails/wei-dai/1/","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/wei-dai/1.md","m":[{"f":"Satoshi Nakamoto","d":1219423080,"b":[["t","I was very interested to read your b-money page.  I’m getting ready to release a paper that expands on your ideas into a complete working system.  Adam Back (hashcash.org) noticed the similarities and pointed me to your site.\n\nI need to find out the year of publication of your b-money page for the citation in my paper.  It’ll look like:\n[1] W. Dai, “b-money,” http://www.weidai.com/bmoney.txt, (2006?).\n\nYou can download a pre-release draft at\nhttp://www.upload.ae/file/6157/ecash-pdf.html  Feel free to forward it to anyone else you think would be interested.\n\nTitle: Electronic Cash Without a Trusted Third Party\n\nAbstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without the burdens of going through a financial institution.  Digital signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to prevent double-spending.  We propose a solution to the double-spending problem using a peer-to-peer network.  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.  The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power.  As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers.  The network itself requires minimal structure.  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.\n\nSatoshi"]],"u":"https://www.bitcoin.com/satoshi-archive/emails/wei-dai/1/","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/wei-dai/1.md","to":"\"Wei Dai\" <weidai@ibiblio.org>","fe":"satoshi@anonymousspeech.com","s":1,"dp":"local","od":"Friday, August 22, 2008 4:38 PM; Wei Dai's copy"},{"f":"Wei Dai","d":1219423140,"b":[["t","Hi Satoshi. b-money was announced on the cypherpunks mailing list in 1998. Here’s the archived post:\nhttps://cypherpunks.venona.com/date/1998/11/msg00941.html\n\nThere are some discussions of it at\nhttps://cypherpunks.venona.com/date/1998/12/msg00194.html.\n\nThanks for letting me know about your paper. I’ll take a look at it and let you know if I have any comments or questions."]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/wei-dai/2.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/wei-dai/2.md","to":"\"Satoshi Nakamoto\" <satoshi@anonymousspeech.com>","fe":"weidai@ibiblio.org","dp":"inferred","sj":"Re: Citation of your b-money page"},{"f":"Satoshi Nakamoto","d":1231586220,"b":[["t","I wanted to let you know, I just released the full implementation of the paper I sent you a few months ago, Bitcoin v0.1.  Details, download and screenshots are at www.bitcoin.org\n\nI think it achieves nearly all the goals you set out to solve in your b-money paper.\n\nThe system is entirely decentralized, without any server or trusted parties.  The network infrastructure can support a full range of escrow transactions and contracts, but for now the focus is on the basics of money and transactions.\n\nThere was a discussion of the design on the Cryptography mailing list.  Hal Finney gave a good high-level overview:\n\nOne thing I might mention is that in many ways bitcoin is two independent ideas: a way of solving the kinds of problems James lists here, of creating a globally consistent but decentralized database; and then using it for a system similar to Wei Dai’s b-money (which is referenced in the paper) but transaction/coin based rather than account based. Solving the global, massively decentralized database problem is arguably the harder part, as James emphasizes. The use of proof-of-work as a tool for this purpose is a novel idea well worth further review IMO.\n\nSatoshi"]],"u":"https://www.bitcoin.com/satoshi-archive/emails/wei-dai/2/","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/wei-dai/3.md","to":"weidai@weidai.com","fe":null,"s":1,"dp":"local","sj":"Re: Citation of your b-money page","od":"Saturday, January 10, 2009 11:17 AM; Wei Dai's copy"}],"id":"x2"},{"k":"x","s":"hal-finney","t":"Re: Bitcoin source files attached","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/1.md","m":[{"f":"Hal Finney","d":1227108046,"b":[["t","Ah, I see, thanks for the corrections.\n\nSome of the discussion and concern over performance may relate to the eventual size of the P2P node network. How large do you envision it becoming? Tens of nodes? Thousands?  Millions?\n\nAnd for clients, do you think this could scale to be usable for close to 100% of world financial transactions? Or would you see it as mostly being used for some “core” subset of transactions that have special requirements, with other transactions using a different payment system that perhaps is based on Bitcoin?\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/1.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/1.md","to":"hal@finney.org, satoshi@vistomail.com","fe":"hal@finney.org"},{"f":"Satoshi Nakamoto","d":1227108046,"b":[["t","100,000 block generating nodes is a good ballpark large-scale size to think about.  Propagating a transaction across the whole network twice would consume a total of US$ 0.02 of bandwidth at today’s prices.  In practice, many would be burning off excess allocated bandwidth or unlimited plans with one of the cheaper backbones.  There could be millions of SPV clients.  They only matter in how many transactions they generate.  If they pay 1 or 2 cents transaction fees, they pay for themselves.  I’ve coded it so you can pay any optional amount of transaction fees you want.  When the incentive subsidy eventually tapers off, it may be necessary to put a market-determined transaction fee on your transactions to make sure nodes process them promptly.\n\nTo think about what a really huge transaction load would look like, I look at the existing credit card network.  I found some more estimates about how many transactions are online purchases.  It’s about 15 million tx per day for the entire e-commerce load of the Internet worldwide.  At 1KB per transaction, that would be 15GB of bandwidth for each block generating node per day, or about two DVD movies worth.  Seems do-able even with today’s technology.\n\nImportant to remember, even if Bitcoin caught on at dot-com rates of growth, it would still take years to become any substantial fraction of all transactions.  I believe hardware has already recently become strong enough to handle large scale, but if there’s any doubt about that, bandwidth speeds, prices, disk space and computing power will be much greater by the time it’s needed.\n\nSatoshi"]],"u":"https://mmalmi.github.io/satoshi/#email-3","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/2.md","to":null,"fe":null,"s":1,"dp":"inferred"}],"id":"x3"},{"k":"x","s":"hal-finney","t":"Bitcoin v0.1","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/3.md","m":[{"f":"Satoshi Nakamoto","d":1231478464,"b":[["t","Thought you’d like to know, the Bitcoin v0.1 release with EXE and full sourcecode is up on Sourceforge:\nhttp://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar\n\nwww.bitcoin.org has release notes and screenshots.\n\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/3.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/3.md","to":"hal@finney.org","fe":"satoshi@vistomail.com","s":1},{"f":"hal@finney.org","d":1231478464,"b":[["t","Hi, Satoshi, thanks very much for that information! I should have a chance to look at that this weekend. I am looking forward to learning more about the code -\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/4.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/4.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal@finney.org","dp":"day-inferred","sj":"Re: Bitcoin v0.1"},{"f":"Satoshi Nakamoto","d":1231519381,"b":[["t","Sure thing.  If you have any questions, feel free.\n\nHi, Satoshi, thanks very much for that information! I should have a chance to look at that this weekend. I am looking forward to learning more about the code -\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/5.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/5.md","to":"hal@finney.org","fe":"satoshi@vistomail.com","s":1,"sj":"Re: Bitcoin v0.1"}],"id":"x4"},{"k":"x","s":"hal-finney","t":"Crash in bitcoin 0.1.0","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/6.md","m":[{"f":"Hal Finney","d":1231614798,"b":[["t","Hi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and it crashed. I am running on an up to date version of XP, SP3. The debug.log output is attached. There was also a file db.log but it was empty.\n\nThe crash allowed me to start up a debugger, but there were no symbols. The exception was at address 00930AF7. The displayed call stack was 942316 called by 508936.\n\nWhen I have a chance, I’ll try building it, although it looks like it would take me a while to acquire all the dependencies.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/6.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/6.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com"},{"f":"Satoshi Nakamoto","d":1231588320,"b":[["t","Normally I would keep the symbols in, but they increased the size of the EXE from 6.5MB to 50MB so I just couldn’t justify not stripping them.  I guess I made the wrong decision, at least for this early version.  I’m kind of surprised there was a crash, I’ve tested heavily and haven’t had an outright exception for a while.  Come to think of it, there isn’t even an exception print at the end of debug.log.  I’ve been testing on XP SP2, maybe SP3 is something.\n\nI’ve attached bitcoin.exe with symbols.  (gcc symbols for gdb, if you’re using MSVC I can send you an MSVC build with symbols)\n\nThanks for your help!\n\nHi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and it crashed. I am running on an up to date version of XP, SP3. The debug.log output is attached. There was also a file db.log but it was empty.\n\nThe crash allowed me to start up a debugger, but there were no symbols. The exception was at address 00930AF7. The displayed call stack was 942316 called by 508936.\n\nWhen I have a chance, I’ll try building it, although it looks like it would take me a while to acquire all the dependencies.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/7.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/7.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: Crash in bitcoin 0.1.0"},{"f":"hal.finney@gmail.com","d":1231588320,"b":[["t","Yes, actually the version with MSVC symbols would be better, that is the one I am using.\n\nI found that if I launched this one from a cygwin shell, it does not crash. But if I launch it from Windows, double-clicking on the file, it does crash similarly to the previous version. However, I am pretty sure that the previous version did crash even when I launched it from cygwin.\n\nI have to go out but I’ll leave this version running for a while.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/8.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/8.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com","dp":"day-inferred","sj":"Re: Crash in bitcoin 0.1.0"},{"f":"Satoshi Nakamoto","d":1231599540,"b":[["t","I was temporarily able to reproduce the bug and narrowed it down to the “mapAddresses.count” in the following code.  It was absolutely the last piece of code to go in and mainly only got tested with the MSVC build.  It’s not essential and I’m inclined to turn off optimization and delete the section of code until I figure out what’s going on.\n\nI’m attaching a dbg exe you can try that deletes the line of code and turns off optimization.  I’m not able to reproduce it anymore at the moment.\n\nirc.cpp:\nif (pszName[0] == ‘u’)\n{\n    CAddress addr;\n    if (DecodeAddress(pszName, addr))\n    {\n        CAddrDB addrdb;\n        if (AddAddress(addrdb, addr))\n            printf(\"new \");\n        else\n        {\n            // make it try connecting sooner\n            CRITICAL_BLOCK(cs_mapAddresses)\n                if (mapAddresses.count(addr.GetKey()))\n                    mapAddresses[addr.GetKey()].nLastFailed = 0;\n        }\n        addr.print();\n    }\n    else\n    {\n        printf(“decode failed\\n”);\n    }\n}\n\nYes, actually the version with MSVC symbols would be better, that is the one I am using.\n\nI found that if I launched this one from a cygwin shell, it does not crash. But if I launch it from Windows, double-clicking on the file, it does crash similarly to the previous version. However, I am pretty sure that the previous version did crash even when I launched it from cygwin.\n\nI have to go out but I’ll leave this version running for a while.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/9.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/9.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: Crash in bitcoin 0.1.0"},{"f":"Satoshi Nakamoto","d":1231613700,"b":[["t","I isolated the problem.  If I spawn a thread and do mapAddresses.count, even as the very first thing in the program, it segfaults.  The workaround is to needlessly call mapAddresses.count in the main thread once and it’s fine from then on.  I hate to blame the compiler, and I’ve never had a GCC compiler bug before, but this feels like one.  Maybe some bit of init code it tries to optimize out if it’s not called at least once in the same thread, or some STL optimization that’s not thread friendly.  I’m really dismayed to have this botch up the release after all that stress testing.\n\nThe attached file: bitcoin-0.1.1.rar (filesize 2,132,686) is the version where I deleted the mapAddresses.count line, and that should be the safest version.  (that was the only use of mapAddresses.count)  If you could try this version and confirm that the crash is fixed, I’d appreciate it.\n\nThanks,\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/10.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/10.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: Crash in bitcoin 0.1.0"},{"f":"hal.finney@gmail.com","d":1231613700,"b":[["t","Hi Satoshi - The version with the .pdb file did not run for me, I got an error about MSVCP60D.DLL not being found. I imagine this is due to the version incompatibility you were worried about.\n\nThe next version, that deleted the questionable line of code and turned off optimization, seems to run fine for me. So the problem may be related to that bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/11.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/11.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com","dp":"day-inferred","sj":"Re: Crash in bitcoin 0.1.0"},{"f":"Satoshi Nakamoto","d":1231614660,"b":[["t","OK, thanks.  The one in bitcoin-0.1.1-exe-dbg.rar is the same build as in bitcoin-0.1.1.rar.  I forgot, when you build debug on MSVC, it uses the debug versions of the runtime DLLs, which aren’t included with Windows distributions.  Actually, MSVC 6.0’s runtime (MSVC60.DLL) is the last version that shipped preinstalled on Windows, which is why the continued interest in that ancient version of the compiler.  Later Visual C versions can’t create a standalone EXE that doesn’t require additional runtime packages installed.\n\nI can’t use MSVC 6.0 for the release because its optimization of the SHA-256 routines is too slow.\n\nI’ve attached a copy of the debug runtime DLLs.  (They’re redistributable)\n\nHi Satoshi - The version with the .pdb file did not run for me, I got an error about MSVCP60D.DLL not being found. I imagine this is due to the version incompatibility you were worried about.\n\nThe next version, that deleted the questionable line of code and turned off optimization, seems to run fine for me. So the problem may be related to that bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/12.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/12.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: Crash in bitcoin 0.1.0"}],"id":"x5"},{"k":"x","s":"hal-finney","t":"Re: How's v0.1.2 going?","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/13.md","m":[{"f":"Satoshi Nakamoto","d":1231691760,"b":[["t","Well this doesn’t look good. After you upgraded to 0.1.2, your node responded to one or two messages and then stopped replying to messages.  It’s still accepting connections and seems to be alive on IRC.  That could happen if ThreadSocketHandler or ThreadMessageHandler is hung or crashed or blocked.  Usually when there’s an exception or other problem, it only stops the affected thread and everything else keeps running.\n\nI’m attaching the msvc debug version in case you need it.\n\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/13.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/13.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x6"},{"k":"x","s":"hal-finney","t":"v0.1.2 gcc debug build attached","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/14.md","m":[{"f":"Satoshi Nakamoto","d":1231692540,"b":[["t","Could you send me your debug.log?\n\nThe gcc debug version is attached.\n\ngdb is easier to use than you’d think. gdb.exe is the only file. You run\ngdb bitcoin.exe\nthen type “run”\nthen if it crashes, type “backtrace” for a stack dump, or it may do it automatically.  (The stack trace doesn’t always go far enough back unfortunately)"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/14.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/14.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x7"},{"k":"x","s":"hal-finney","t":"select failed 10038 fix","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/17.md","m":[{"f":"Satoshi Nakamoto","d":1231709460,"b":[["t","I believe I’ve fixed the bug related to “select failed: 10038” (error WSAENOTSOCK).  The select error is not a big deal, but it led the communications thread to get blocked on a socket that should have been in non-blocking mode but wasn’t.  It never came up until now because as long as select never failed, receive would never be called unless there was data.\n\nWithout this fix, your node’s communication sometimes goes dead.  Connections are still made, but no data is passed.  Any generated blocks would probably not be accepted since you can’t broadcast them and other nodes will leave your branch behind.  That’s why Generate doesn’t run when you’re not connected.\n\nThis could also have caused bitcoin.exe to fail to exit.  There’s no reason for shutdown to wait for the com thread, so I made it only wait for the message processing thread.  I’ll do a more thorough forced shutdown later.\n\nLooks like your node’s com thread just now got blocked on this bug again.  It went for a few hours this time before it did.\n\nVersion 0.1.3 exe attached."]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/17.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/17.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"},{"f":"hal.finney@gmail.com","d":1231718400,"b":[["t","Thanks, Satoshi, this new version seems to be running much better. I’ve got 8 connections, and watching debug.log there seems to be quite a bit of activity. I see you sent me a payment, thanks! Let me know your address and I will try sending one to you. I managed to generate a block yesterday and the coins are about to mature, if I understand it correctly.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/18.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/18.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com","dp":"day","sj":"Re: select failed 10038 fix"},{"f":"Satoshi Nakamoto","d":1231749660,"b":[["t","It definitely looks like 0.1.3 solved it.  It was getting so there were so many zombie nodes, I was having a hard time getting a reply to any of my messages.  Now, four inventory messages go out, four getdata messages come back.\n\nDid you get any “not accepted” blocks?  The connectivity bug could have caused a generated block not to be accepted if the node wasn’t able to broadcast at the time.  Once the status is above 5 or so it’s safely accepted.\n\nUnfortunately, I can’t receive incoming connections from where I am, which has made things more difficult.  Your node receiving incoming connections was the main thing keeping the network going the first day or two.\n\nYou can send to my Bitcoin address if you want to, but you won’t get to see the full transfer sequence:\n1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD\n\nYou could always findstr /c:“version message” debug.log and send a test to some random person you’re connected to near the end of the list.  The ones ending in port 8333 can receive connections.\n\nI just thought of something.  Eventually there’ll be some interest in brute force scanning bitcoin addresses to find one with the first few characters customized to your name, kind of like getting a phone number that spells out something.  Just by chance I have my initials.\n\nSatoshi\n\nThanks, Satoshi, this new version seems to be running much better. I’ve got 8 connections, and watching debug.log there seems to be quite a bit of activity. I see you sent me a payment, thanks! Let me know your address and I will try sending one to you. I managed to generate a block yesterday and the coins are about to mature, if I understand it correctly.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/19.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/19.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: select failed 10038 fix"},{"f":"hal.finney@gmail.com","d":1231749660,"b":[["t","Looks like 0.1.3 crashed during the night, unfortunately. Next time I will try running the debug version. Today I am working and will need to take this computer up and down quite a bit, so I won’t be able to run it for most of the day. Tonight I will try to look at it a little bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/20.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/20.md","to":null,"fe":"hal.finney@gmail.com","dp":"day-inferred","sj":"Re: select failed 10038 fix"},{"f":"Satoshi Nakamoto","d":1231757400,"b":[["t","Could you send me the debug.log from the 0.1.3 crash?\nI can usually get a lot just from that.\n\nI’ll send you the debug builds shortly.\n\nLooks like 0.1.3 crashed during the night, unfortunately. Next time I will try running the debug version. Today I am working and will need to take this computer up and down quite a bit, so I won’t be able to run it for most of the day. Tonight I will try to look at it a little bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/21.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/21.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: select failed 10038 fix"},{"f":"hal.finney@gmail.com","d":1231804800,"b":[["t","Hi Satoshi - Sorry I have not been able to do more today, this looks like a busy week for me. I started 0.1.3 again under the MSVC debugger this time so if it crashes tonight I may be able to get some more information.\n\nI remember now that last night, my disk filled up. I had downloaded a bunch of the dependencies (boost, etc) with an eye towards trying to build it myself, and my disk was already pretty full. I’m pretty sure this is what caused 0.1.3 to crash. I’ve attached the debug.log, which also includes some other runs. The error is about 1/3 of the way down and says,\n\nEXCEPTION: NSt8ios_base7failureE\nCAutoFile::read : end of file\n\nNormally this should be a rare occurrence with the large disk sizes people have today.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/24.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/24.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com","dp":"day","sj":"Re: select failed 10038 fix"},{"f":"Satoshi Nakamoto","d":1231804740,"b":[["t","Definitely the disk full.  I completely put off disk full handling until a later version.  Probably about time I did it now.\n\nWell, that’s a relief.\n\nSatoshi\n\nHi Satoshi - Sorry I have not been able to do more today, this looks like a busy week for me. I started 0.1.3 again under the MSVC debugger this time so if it crashes tonight I may be able to get some more information.\n\nI remember now that last night, my disk filled up. I had downloaded a bunch of the dependencies (boost, etc) with an eye towards trying to build it myself, and my disk was already pretty full. I’m pretty sure this is what caused 0.1.3 to crash. I’ve attached the debug.log, which also includes some other runs. The error is about 1/3 of the way down and says,\n\nEXCEPTION: NSt8ios_base7failureE\nCAutoFile::read : end of file\n\nNormally this should be a rare occurrence with the large disk sizes people have today.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/25.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/25.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local","sj":"Re: select failed 10038 fix"}],"id":"x8"},{"k":"x","s":"hal-finney","t":"Re: v0.1.2 debug.log","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/15.md","m":[{"f":"hal.finney@gmail.com","d":1231718400,"b":[["t","Hi Satoshi - debug.log attached. When I started 0.1.2 this afternoon, I first quit the previous version which was running. However, 0.1.2 would not start up. Looking at the debug log, it said “Existing instance found”. I ran task manager, and found two processes called bitcoin.exe running. I killed them both and started up the new one, and it seemed to run OK. It says at the bottom “3 connections”. I haven’t tried the debug version, I’m not sure what I would look for.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/15.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/15.md","to":"Satoshi Nakamoto <satoshi@vistomail.com>","fe":"hal.finney@gmail.com","dp":"day"},{"f":"Satoshi Nakamoto","d":1231694700,"b":[["t","OK, so no crash or exception window or anything.  debug.log is all I need then.\n\nIt looks like there’s a “select failed: 10038” error (the sockets select function failed) and then network communication goes quiet after that (except for IRC which is still working).  I’ve never had select fail before.  It looks like sockets is somehow partially hosed.  At least now I know what’s wrong now.\n\nYou should restart it. It’s not doing anything right now.  I don’t know if it’ll just get the “select failed” error again, or be fine for a while.\n\nIf I can’t think of anything else, I can always shut down and restart sockets if it gets hosed like that.  I’m sure everyone who’s written an internet app like a browser or p2p app had to slog through all the ways the Internet can trash you.  The Internet is a brutal, rough and tumble place.\n\nThe issue of bitcoin.exe still running after you close it is a known issue.  It does a careful shutdown of everything to be extra safe, in case some important transaction is in progress, but it’s completely fine and totally safe to just kill it if it doesn’t exit on its own.  I’ll have to work on figuring out what’s getting hung up.  I may just have it kill itself after a timeout.\n\nThanks!\n\nHi Satoshi - debug.log attached. When I started 0.1.2 this afternoon, I first quit the previous version which was running. However, 0.1.2 would not start up. Looking at the debug log, it said “Existing instance found”. I ran task manager, and found two processes called bitcoin.exe running. I killed them both and started up the new one, and it seemed to run OK. It says at the bottom “3 connections”. I haven’t tried the debug version, I’m not sure what I would look for.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/16.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/16.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x9"},{"k":"x","s":"dustin-trammell","t":"Re: Bitcoin v0.1 released","u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","m":[{"f":"Dustin D. Trammell","d":1231737244,"b":[["q","Announcing the first release of Bitcoin, a new electronic cash\r\nsystem that uses a peer-to-peer network to prevent double-spending.\r\nIt's completely decentralized with no server or central authority.\r","On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:"],["t","\r\nI'm currently reading through your paper.  At the timestamp server\r\nsection you mention newspapers and usenet, so I thought you might be\r\ninterested in this if you have not seen it already:\r\n\r\nhttp://www.publictimestamp.org/\r\n\r\nBy the way, I'm also currently running the alpha code on one of my\r\nworkstations.  So far it has two \"Generated\" messages, however the\r\n\"Credit\" field for those is 0.00 and the balance hasn't changed.  Is\r\nthis due to the age/maturity requirement for a coin to be valid?\r\n\r\nCheers,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Dustin D. Trammell","d":1231737244,"b":[["q","Announcing the first release of Bitcoin, a new electronic cash\r\nsystem that uses a peer-to-peer network to prevent double-spending.\r\nIt's completely decentralized with no server or central authority.\r","On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:"],["t","\r\nI'm currently reading through your paper.  At the timestamp server\r\nsection you mention newspapers and usenet, so I thought you might be\r\ninterested in this if you have not seen it already:\r\n\r\nhttp://www.publictimestamp.org/\r\n\r\nBy the way, I'm also currently running the alpha code on one of my\r\nworkstations.  So far it has two \"Generated\" messages, however the\r\n\"Credit\" field for those is 0.00 and the balance hasn't changed.  Is\r\nthis due to the age/maturity requirement for a coin to be valid?\r\n\r\nCheers,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1231785208,"b":[["q","I'm currently reading through your paper.  At the timestamp server\nsection you mention newspapers and usenet, so I thought you might be\ninterested in this if you have not seen it already:\n\nhttp://www.publictimestamp.org/"],["t","Thanks, I hadn't seen that yet.  It looks very well presented.\nThere was an older one that's been running for a long time that\npublishes its hashes to Usenet.  I'm surprised this one isn't\nusing Usenet, although it is kind of difficult to get access to\npost to Usenet in an automated way these days.  If they can get a\nmagazine or newspaper to publish their hashes, it would work a lot\neasier in court for their purposes.  Bitcoin and all timestamp\nservers share the basic functionality of periodically collecting\nthings into blocks and hashing them into a chain."],["q","By the way, I'm also currently running the alpha code on one of my\nworkstations.  So far it has two \"Generated\" messages, however the\n\"Credit\" field for those is 0.00 and the balance hasn't changed.  Is\nthis due to the age/maturity requirement for a coin to be valid?"],["t","Right, the credit field stays 0.00 until it matures, then it'll be\n50.00.  Do you think it would be clearer if I left the credit\nfield blank until it matures?  I should put some text in the\ntransaction details (when you double click on it) explaining how\nit works.  (was it obvious you can doubleclick on a line for\ndetails?)\n\nBe sure to upgrade to v0.1.3 if you haven't already.  This version\nhas really stabilized things.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1},{"f":"Dustin D. Trammell","d":1231817392,"b":[["q","Thanks, I hadn't seen that yet.  It looks very well presented.\r\nThere was an older one that's been running for a long time that\r\npublishes its hashes to Usenet.  I'm surprised this one isn't\r\nusing Usenet, although it is kind of difficult to get access to\r\npost to Usenet in an automated way these days.  If they can get a\r\nmagazine or newspaper to publish their hashes, it would work a lot\r\neasier in court for their purposes.  Bitcoin and all timestamp\r\nservers share the basic functionality of periodically collecting\r\nthings into blocks and hashing them into a chain.\r","On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:"],["t","\r\nIt actually posts the hash blocks to a Google Group called\r\n'proof-hashes', so similar result as if it were posting to Usenet.\r\n\r\nhttp://groups.google.com/group/proof-hashes\r\n\r\nSince I run that group, and it's sole purpose is to archive\r\nproof-of-work hashes, feel free to join an account to have your system\r\npost there as well if you like.\r\n\r"],["q","Right, the credit field stays 0.00 until it matures, then it'll be\r\n50.00.  Do you think it would be clearer if I left the credit\r\nfield blank until it matures?  I should put some text in the\r\ntransaction details (when you double click on it) explaining how\r\nit works.  (was it obvious you can doubleclick on a line for\r\ndetails?)\r"],["t","\r\nNo, I think having $0.00 there is more appropriate than being blank.\r\nThe entries in my BitCoin software (4 of them now) all say 'unconfirmed'\r\nhowever, so I'm not sure what that means, but I did grok that the coins\r\nwere generated and just not 'mature' yet, but I had also read your\r\nwhitepaper so I may have understood that concept from there.  When the\r\ncoins mature, will that generate a new 'credit' transaction, or will the\r\nexisting generation transaction line's credit field be updated?\r\n\r\nNo, I was unaware that you could double-click a transaction line for\r\nfurther details...  I just did that and it currently just has the same\r\ninformation there that is in the transaction line.  Putting more\r\ninformation there would definitely be useful.\r\n\r"],["q","Be sure to upgrade to v0.1.3 if you haven't already.  This version\r\nhas really stabilized things.\r"],["t","\r\nI was running 0.1.1... I will update now.  Perhaps a new version\r\nnotification or auto-update feature is in order? (:\r\n\r\nElectronic currency and cryptography are two things that I am very\r\ninterested in so as you would assume I was drawn to this project\r\nimmediately when I saw it posted to the Cryptography email list.  Feel\r\nfree to ping me for feedback or to test out new features, I'll be happy\r\nto help out.\r\n\r\nCheers,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Dustin D. Trammell","d":1231818058,"b":[["q","Be sure to upgrade to v0.1.3 if you haven't already.  This version\r\nhas really stabilized things.\r","On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:"],["t","\r\nTwo issues with upgrading:\r\n\r\nWhen closing my previous version (help said 0.1.1 but I think it was\r\nreally 0.1.0), the process did not exit.  The UI exited but the process\r\nremained.  I had to manually kill the process before I was able to start\r\nversion 0.1.3.\r\n\r\nUpon opening version 0.1.3, all four of my transaction entries still say\r\n'unconfirmed', but now the Descriptions say 'Generated (not accepted)'.\r\nDoes this mean that some other node had extended the chain first and my\r\ncoins were generated in a dead branch?  If so, why did the previous\r\ninstance of the software not detect this immediately and begin\r\ngenerating coins in the winning branch?  Bug in 0.1.0?\r\n\r\nI'll watch this instance and see how it goes...\r\n\r\nThanks,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1231832371,"b":[["q","It actually posts the hash blocks to a Google Group called\n'proof-hashes', so similar result as if it were posting to Usenet.\n\nhttp://groups.google.com/group/proof-hashes\n\nSince I run that group, and it's sole purpose is to archive\nproof-of-work hashes, feel free to join an account to have your system\npost there as well if you like."],["t","Sweet, I was looking for a group like that on Usenet at one point to see\nwhat I would use if I needed, and nothing really fit.  I'm sure Google\ngroups is a lot easier to post to.\n\nThere are some scenarios where a Usenet or Google group could be used as\na supplemental defence.  Bitcoin is at its most vulnerable in the\nbeginning when the total network CPU power is small.  That's offset by\nthe fact that the incentive to attack it is also low when it's small.\nHopefully the easy solution of just growing up and getting past that\nstage will work.  If not, there are ways a Google group could help, if\nit really came to that."],["q","Electronic currency and cryptography are two things that I am very\ninterested in so as you would assume I was drawn to this project\nimmediately when I saw it posted to the Cryptography email list. Feel\nfree to ping me for feedback or to test out new features, I'll be happy\nto help out."],["t","We definitely have similar interests!\n\nYou know, I think there were a lot more people interested in the 90's,\nbut after more than a decade of failed Trusted Third Party based systems\n(Digicash, etc), they see it as a lost cause.  I hope they can make the\ndistinction, that this is the first time I know of that we're trying a\nnon-trust based system."],["q","When the\ncoins mature, will that generate a new 'credit' transaction, or will the\nexisting generation transaction line's credit field be updated?"],["t","The existing transaction line will change."],["q","Upon opening version 0.1.3, all four of my transaction entries still say\n'unconfirmed', but now the Descriptions say 'Generated (not accepted)'.\nDoes this mean that some other node had extended the chain first and my\ncoins were generated in a dead branch? If so, why did the previous\ninstance of the software not detect this immediately and begin\ngenerating coins in the winning branch? Bug in 0.1.0?"],["t","You're right, sorry about that.  It's the bug that was fixed in 0.1.3.\nThe communications thread would get blocked, so you would make\nconnections, but they would go silent after a while.  When you found a\nblock, you couldn't broadcast it to the network, so it didn't get into\nthe chain.  You weren't receiving anything either to know that the\nnetwork had gone on without you, until you restarted it.\n\nThe bug is also what caused bitcoin.exe to fail to exit.  The\ncommunications thread was blocked and failed to exit.  Bitcoin does a\ncareful shutdown in case it might be in the middle of an important\ntransaction, but actually it's completely safe to kill it.\n\nThis is all fixed in 0.1.3.  If you give me your IP, I'll send you some\ncoins."],["q","One other question I had... What prevents the single node with the most\nCPU power from generating and retaining the majority of the BitCoins?\nIf every node is working independently of all others, if one is\nsignificantly more powerful than the others, isn't it probable that this\nnode will reach the proper conclusion before other nodes? An\nunderpowered node may get lucky once in a while, but if they are at a\nsignificant horsepower advantage I would expect the majority of BitCoins\nto be generated by the most powerful node."],["t","It's not like a race where if one car is twice as fast, it'll always\nwin.  It's an SHA-256 that takes less than a microsecond, and each guess\nhas an independent chance of success.  Each computer's chance of finding\na hash collision is linearly proportional to it's CPU power.  A computer\nthat's half as fast would get half as many coins."],["q","I'll watch this instance and see how it goes..."],["t","Let me know how it goes.  If you have any trouble with it, send me your\ndebug.log file.  I can often figure out what went wrong just from that.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1},{"f":"Dustin D. Trammell","d":1231893628,"b":[["q","Sweet, I was looking for a group like that on Usenet at one point to see\r\nwhat I would use if I needed, and nothing really fit.  I'm sure Google\r\ngroups is a lot easier to post to.\r","On Tue, 2009-01-13 at 15:39 +0800, Satoshi Nakamoto wrote:"],["t","\r\nYea, that particular group is completely open, you don't have to join to\r\npost (in fact I think I made it difficult for people to actually join),\r\nyou just email proof-hashes@googlegroups.com and the content of the\r\nemail gets posted to the group.\r\n\r"],["q","There are some scenarios where a Usenet or Google group could be used as\r\na supplemental defence.  Bitcoin is at its most vulnerable in the\r\nbeginning when the total network CPU power is small.  That's offset by\r\nthe fact that the incentive to attack it is also low when it's small.\r\nHopefully the easy solution of just growing up and getting past that\r\nstage will work.  If not, there are ways a Google group could help, if\r\nit really came to that.\r"],["t","\r\nYea, I was thinking you could have a client post the current block chain\r\nevery 10k blocks or something, just to occasionally document the current\r\nwinning proof-of-work chain.\r\n\r"],["q","We definitely have similar interests!\r"],["t","\r\nIndeed.\r\n\r"],["q","You know, I think there were a lot more people interested in the 90's,\r\nbut after more than a decade of failed Trusted Third Party based systems\r\n(Digicash, etc), they see it as a lost cause.  I hope they can make the\r\ndistinction, that this is the first time I know of that we're trying a\r\nnon-trust based system. \r"],["t","\r\nYea, that was the primary feature that caught my eye.  The real trick\r\nwill be to get people to actually value the BitCoins so that they become\r\ncurrency.  Currently, they're just collections of bits...\r\n\r"],["q","This is all fixed in 0.1.3.  If you give me your IP, I'll send you some\r\ncoins.\r"],["t","\r\nI'm currently at 24.28.79.95, but that's dynamic so it may change.  I've\r\nhad that address for a while though so hopefully my dhcp client is being\r\nsuccessful at renewing and not losing my address.  It does change from\r\ntime to time, but that address should be good for a while.\r\n\r"],["q","It's not like a race where if one car is twice as fast, it'll always\r\nwin.  It's an SHA-256 that takes less than a microsecond, and each guess\r\nhas an independent chance of success.  Each computer's chance of finding\r\na hash collision is linearly proportional to it's CPU power.  A computer\r\nthat's half as fast would get half as many coins.\r"],["t","\r\nAhh I see... So each guess is like the spin of a roulette wheel,\r\ncompletely independent from all other guesses and the extra CPU power\r\njust translates to more successful guesses than anyone else.\r\nUnfortunately my ability to understand complex mathematics is conversely\r\nproportional to how interested I am in cryptography (:\r\n\r"],["q","Let me know how it goes.  If you have any trouble with it, send me your\r\ndebug.log file.  I can often figure out what went wrong just from that.\r"],["t","\r\nWill do...\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1232046644,"b":[["q","I've had that address for a while though so hopefully my dhcp\nclient is being successful at renewing and not losing my address.\nIt does change from time to time, but that address should be good\nfor a while."],["t","There's at least one node who's inbound IP keeps changing all the\ntime within the same class B.  Maybe every time the program is\nrun.  I wasn't expecting that.\n\nDo you mind if I CC the rest of this to bitcoin-list or\nCryptography?\n\nBTW, bitcoin-list is:\nbitcoin-list@lists.sourceforge.net\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list\nArchives:\nhttp://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list"],["q","Dustin D. Trammell wrote:\n> Satoshi Nakamoto wrote:\n> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based systems\n> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the BitCoins so that they become\ncurrency."],["t","Hal sort of alluded to the possibility that it could be seen as a\nlong-odds investment.  I would be surprised if 10 years from now\nwe're not using electronic currency in some way, now that we know\na way to do it that won't inevitably get dumbed down when the TTP\ngets cold feet.\n\nEven if it doesn't take off straight away, it's now available for\nuse by the next guy who comes up with a plan that needs some kind\nof token or electronic currency.  It could get started in a closed\nsystem or narrow niche like reward points, donation tokens,\ncurrency for a game or micropayments for adult sites.  Once it\ngets bootstrapped, there are so many applications if you could\neffortlessly pay a few cents to a website as easily as dropping\ncoins in a vending machine.\n\nIt can already be used for pay-to-send e-mail.  The send dialog is\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1},{"f":"Dustin D. Trammell","d":1232068467,"b":[["q","There's at least one node who's inbound IP keeps changing all the\r\ntime within the same class B.  Maybe every time the program is\r\nrun.  I wasn't expecting that.\r","On Fri, 2009-01-16 at 03:10 +0800, Satoshi Nakamoto wrote:"],["t","\r\nPretty sure that's not me.  My BitCoin application at work should be\r\ncoming from our static NAT address and my connection at home has had the\r\nIP that I gave you for at least 3 days now (that I've been transferring\r\ncoins between them for test purposes).\r\n\r"],["q","Do you mind if I CC the rest of this to bitcoin-list or\r\nCryptography?\r"],["t","\r\nSure, no problem.\r\n\r"],["q","BTW, bitcoin-list is:\r\nbitcoin-list@lists.sourceforge.net\r\nSubscribe/unsubscribe page:\r\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list\r\nArchives:\r\nhttp://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list\r"],["t","\r\nI'll join right now, thanks (:\r\n\r"],["q","Hal sort of alluded to the possibility that it could be seen as a\r\nlong-odds investment.  I would be surprised if 10 years from now\r\nwe're not using electronic currency in some way, now that we know\r\na way to do it that won't inevitably get dumbed down when the TTP\r\ngets cold feet.\r"],["t","\r\nYes, I saw that message and was one of the other reasons I started up a\r\nnode so quickly.  My systems aren't doing much of anything else while\r\nidle, so why not create BitCoins?  And if they're worth something\r\nsomeday...? Bonus!\r\n\r"],["q","Even if it doesn't take off straight away, it's now available for\r\nuse by the next guy who comes up with a plan that needs some kind\r\nof token or electronic currency.  It could get started in a closed\r\nsystem or narrow niche like reward points, donation tokens,\r\ncurrency for a game or micropayments for adult sites.  Once it\r\ngets bootstrapped, there are so many applications if you could\r\neffortlessly pay a few cents to a website as easily as dropping\r\ncoins in a vending machine. \r"],["t","\r\nI can see how various types of sites that have a need for micropayments\r\ncould use them, however I also see an impedement to adoption if they\r\nwant to use an existing BitCoin peer group rather than a closed system\r\nsince they would first have to generate enough coins to support what\r\nthey intend to do (or buy them from someone else).  A closed system\r\nobviously doesn't have that problem.\r\n\r"],["q","It can already be used for pay-to-send e-mail.  The send dialog is\r\nresizeable and you can enter as long of a message as you like.\r\nIt's sent directly when it connects.  The recipient doubleclicks\r\non the transaction to see the full message.  If someone famous is\r\ngetting more e-mail than they can read, but would still like to\r\nhave a way for fans to contact them, they could set up Bitcoin and\r\ngive out the IP address on their website.  \"Send X bitcoins to my\r\npriority hotline at this IP and I'll read the message personally.\"\r"],["t","\r\nInteresting application (:\r\n\r"],["q","Subscription sites that need some extra proof-of-work for their\r\nfree trial so it doesn't cannibalize subscriptions could charge\r\nbitcoins for the trial.\r"],["t","\r\nAnother good idea.\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1232121794,"b":[["q","Dustin D. Trammell wrote:\n> Satoshi Nakamoto wrote:\n> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based systems\n> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the BitCoins so that they become\ncurrency."],["t","I would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites.  Initially it can be used in proof-of-work applications\nfor 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\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on.  If\nenough people think the same way, that becomes a self fulfilling\nprophecy.  Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1},{"f":"Satoshi Nakamoto","d":1232121794,"b":[["q","Dustin D. Trammell wrote:\n> Satoshi Nakamoto wrote:\n> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based systems\n> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the BitCoins so that they become\ncurrency."],["t","I would be surprised if 10 years from now we're not using\nelectronic currency in some way, now that we know a way to do it\nthat won't inevitably get dumbed down when the trusted third party\ngets cold feet.\n\nIt could get started in a narrow niche like reward points,\ndonation tokens, currency for a game or micropayments for adult\nsites.  Initially it can be used in proof-of-work applications\nfor 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\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\nIt might make sense just to get some in case it catches on.  If\nenough people think the same way, that becomes a self fulfilling\nprophecy.  Once it gets bootstrapped, there are so many\napplications if you could effortlessly pay a few cents to a\nwebsite as easily as dropping coins in a vending machine.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org"],["f","The Cryptography Mailing List\nUnsubscribe by sending \"unsubscribe cryptography\" to majordomo@metzdowd.com"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1},{"f":"Satoshi Nakamoto","d":1232898430,"b":[["q","> * Spammer botnets could burn through pay-per-send email filters\n>   trivially\nIf POW tokens do become useful, and especially if they become money,\nmachines will no longer sit idle. Users will expect their computers to\nbe earning them money (assuming the reward is greater than the cost to\noperate). A computer whose earnings are being stolen by a botnet will\nbe more noticeable to its owner than is the case today, hence we might\nexpect that in that world, users will work harder to maintain their\ncomputers and clean them of botnet infestations.","Hal Finney wrote:"],["t","Another factor that would mitigate spam if POW tokens have value:\nthere would be a profit motive for people to set up massive\nquantities of fake e-mail accounts to harvest POW tokens from\nspam.  They'd essentially be reverse-spamming the spammers with\nautomated mailboxes that collect their POW and don't read the\nmessage.  The ratio of fake mailboxes to real people could become\ntoo high for spam to be cost effective.\n\nThe process has the potential to establish the POW token's value\nin the first place, since spammers that don't have a botnet could\nbuy tokens from harvesters.  While the buying back would\ntemporarily let more spam through, it would only hasten the\nself-defeating cycle leading to too many harvesters exploiting the\nspammers.\n\nInterestingly, one of the e-gold systems already has a form of\nspam called \"dusting\".  Spammers send a tiny amount of gold dust\nin order to put a spam message in the transaction's comment field.\n If the system let users configure the minimum payment they're\nwilling to receive, or at least the minimum that can have a\nmessage with it, users could set how much they're willing to get\npaid to receive spam.\n\nSatoshi Nakamoto"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1}],"id":"x10"},{"k":"x","s":"hal-finney","t":"Re: v0.1.3 msvc debug build","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/22.md","m":[{"f":"Satoshi Nakamoto","d":1231759560,"b":[["t","Here’s the 0.1.3 MSVC debug build\n\nLooks like 0.1.3 crashed during the night, unfortunately. Next time I will try running the debug version. Today I am working and will need to take this computer up and down quite a bit, so I won’t be able to run it for most of the day. Tonight I will try to look at it a little bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/22.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/22.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x11"},{"k":"x","s":"hal-finney","t":"Re: v0.1.3 gcc debug build","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/23.md","m":[{"f":"Satoshi Nakamoto","d":1231760340,"b":[["t","and the gcc debug build w/gdb.exe\n\nLooks like 0.1.3 crashed during the night, unfortunately. Next time I will try running the debug version. Today I am working and will need to take this computer up and down quite a bit, so I won’t be able to run it for most of the day. Tonight I will try to look at it a little bit.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/23.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/23.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x12"},{"k":"x","s":"dustin-trammell","t":"One Other Question","u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","m":[{"f":"Dustin D. Trammell","d":1231818542,"b":[["t","One other question I had... What prevents the single node with the most\r\nCPU power from generating and retaining the majority of the BitCoins?\r\nIf every node is working independently of all others, if one is\r\nsignificantly more powerful than the others, isn't it probable that this\r\nnode will reach the proper conclusion before other nodes?  An\r\nunderpowered node may get lucky once in a while, but if they are at a\r\nsignificant horsepower advantage I would expect the majority of BitCoins\r\nto be generated by the most powerful node.\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"}],"id":"x13"},{"k":"x","s":"hal-finney","t":"Re: disk full","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/26.md","m":[{"f":"Satoshi Nakamoto","d":1231857720,"b":[["t","If you build the dependencies, let me know how that goes.  Everything is always harder to build on Windows than Linux.  I’ve always hated projects with a lot of big dependencies, but there’s no avoiding it, each one is essential.\n\nI still haven’t figured out how you managed to get a read exception rather than a write exception when your disk filled up. It’s unlikely but maybe possible that the incident could have messed up your block data file.  In that case, it might manifest as a similar exception again, or if your block count in the status bar stopped going up, that would also indicate a problem.  As of this moment it’s at 375 blocks.\n\nIf there is a problem, it could easily be solved by deleting your block files, as follows:\n\n(exit Bitcoin and make sure it’s stopped)\ncd /d “%appdata%\\bitcoin”\n(backup this directory first)\ndel blk0001.dat\ndel blkindex.dat\n\nIt’ll then re-download the block chain.  Your transactions and generated blocks show as 0/unconfirmed until it’s done downloading.\n\nThe crucial file to backup is wallet.dat.  If bitcoin is running then you have to backup the whole %appdata%\\bitcoin directory including the database subdirectory, but even if it’s not running it certainly feels safer to always backup the whole directory.\n\nThe database unfortunately names its files “log.0000000001”.  To the rest of the world, “log” means delete-at-will, but to database people it means delete-and-lose-everything-in-your-other-files.  I tried to put them out of harm’s way by putting them in the database subdirectory.  Later I’ll write code to flush the logs after every wallet change so wallet.dat will be standalone safe almost all the time.\n\nSatoshi\n\nHi Satoshi - Sorry I have not been able to do more today, this looks like a busy week for me. I started 0.1.3 again under the MSVC debugger this time so if it crashes tonight I may be able to get some more information.\n\nI remember now that last night, my disk filled up. I had downloaded a bunch of the dependencies (boost, etc) with an eye towards trying to build it myself, and my disk was already pretty full. I’m pretty sure this is what caused 0.1.3 to crash. I’ve attached the debug.log, which also includes some other runs. The error is about 1/3 of the way down and says,\n\nEXCEPTION: NSt8ios_base7failureE\nCAutoFile::read : end of file\n\nNormally this should be a rare occurrence with the large disk sizes people have today.\n\nHal"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/26.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/26.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"},{"f":"Satoshi Nakamoto","d":1232815620,"b":[["t","I hate duplicating code, but the compiler forces us. Copy the body of the function above it, like this:\n\n    void insert(iterator it, const_iterator first, const_iterator last)\n    {\n        if (it == vch.begin() + nReadPos && last - first <= nReadPos)\n        {\n            // special case for inserting at the front when there’s room\n            nReadPos -= (last - first);\n            memcpy(&vch[nReadPos], &first[0], last - first);\n        }\n        else\n            vch.insert(it, first, last);\n    }\n\n#if !defined(_MSC_VER) || _MSC_VER >= 1300\n    void insert(iterator it, const char* first, const char* last)\n    {\n        if (it == vch.begin() + nReadPos && last - first <= nReadPos)\n        {\n            // special case for inserting at the front when there’s room\n            nReadPos -= (last - first);\n            memcpy(&vch[nReadPos], &first[0], last - first);\n        }\n        else\n            vch.insert(it, first, last);\n    }\n#endif\n\nThe modified version of serialize.h is attached.\n\nBTW, in my tests, VC8 produced an EXE that would only run on systems that had VC8 installed on them.  The error it gives is extremely vague.  I think they expect you to install a package during setup, but bitcoin doesn’t have a setup.\n\nMy testing has been with MSVC 6.0 SP6 and GCC 3.4.5.  GCC is the release build.  There’s nothing wrong with the MSVC 6.0 build other than its optimization of the SHA routines for generating blocks is slow.\n\nSatoshi"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/27.md","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/doc/hal-finney/27.md","to":"hal.finney@gmail.com","fe":"satoshi@vistomail.com","s":1,"dp":"local"}],"id":"x14"},{"k":"x","s":"dustin-trammell","t":"A few thoughts...","u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","m":[{"f":"Dustin D. Trammell","d":1231999515,"b":[["t","I'm glad to see you considered the possibility of a BitCoin client\r\nmaking a payment to itself and have an appropriate description in the\r\ntransaction log (:\r\n\r\nI did this primarily so that I could get a packet capture of the network\r\ntraffic during a transaction to analyze.  Without knowing your packet\r\nstructure, I only see a bit of cleartext information in the packets,\r\nmostly just what is shown in the transaction detail such as name and\r\ncomments.  There are a couple of other strings that show upon the wire\r\nsuch as 'version' and 'reply', but the rest is pretty cryptic.\r\n\r\nWhile pondering transactions, I realized that there is no identifiable\r\ninformation involved other than an IP address or a BitCoin address.  In\r\nthe case of the IP transaction, the BitCoin client seems to trust that\r\nthe IP that it has connected to really is the intended recipient of the\r\ntransaction.  It is fairly trivial to launch a man-in-the-middle attack\r\nand steal incoming transactions.  Consider the scenario where a\r\nco-worker and myself have our workstations on the same LAN.  Being\r\nnefarious, I could be ARP poisoning the local broadcast domain and\r\nrouting all traffic destined for his workstation through my workstation\r\nas an intermediary.  Both of us, not being good employees, play the\r\nMMORPG-du-jour and like to buy and sell game items using BitCoins.  I\r\ncould easily watch for incoming connections on TCP port 8333 and\r\nterminate them at my workstation rather than passing those particular\r\nconnections on to his workstation.  A bit convoluted, yes, but it\r\nillustrates the point.  This type of attack could be performed at any\r\nhop along the route between the two transacting parties.  If I were an\r\nevil admin at Big ISP USA, well, you get the idea.\r\n\r\nI would recommend not allowing the use of network addresses as the\r\naddress of an intended recipient.  I would think it would be a bit more\r\nsecure to always require a BitCoin address and do transactions that way.\r\nIf I understand how that is done correctly, you just compute the\r\ntransaction into the block chain and let the intended recipient\r\n'discover' it, correct?  An alternative could be to allow the network\r\nnodes to provide a resolution service, where they ask around for the\r\nnetwork address of a BitCoin address, and if that node is online, once a\r\nconsensus is agreed upon by the network for that address the sending\r\nBitCoin application connects directly there.  Because the BitCoin\r\naddresses are tied to the keys of the node, I would think that some\r\nmethod could be devised to prove ownership of that BitCoin address by\r\nthe sending node and not to proceed with the transaction if so.  At the\r\nvery least I would recommend, if you intend to retain the recipient\r\naddressing by IP method is to allow for matching a hash of a shared\r\nsecret between the parties or something that an intermediary would not\r\nknow, but since you have the crypto in place, keys generated, etc.\r\nanyhow, using that would be a much stronger solution.\r\n\r\nOr am I over-thinking this and the network connection is just to send\r\nimmediate notification of the transaction and context information such\r\nas the comment?  The BitCoin application mentioned getting the\r\nrecipient's public key and a few other things, and there seems to be a\r\nlot more going on in the network traffic than what would be required for\r\na simple notification.\r\n\r\nTalk to you soon,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1232048520,"b":[["t","I group attacks into two classes:\n1) Attacks that can only be done by someone actually in the chain\n    of communication\n2) Attacks that can be done by anyone on the Internet from anywhere\n\nType 1 exposes you to people in your house or company on your\nlocal LAN, admins at ISPs in between, and the LAN on the\nrecipient's side.  Type 2 exposes you to a billion people who can\nself-select to be attackers and get economy of scale when they\ndevelop one technique to attack multiple victims.\n\nSending by IP requests a new public key, so yes, it's vulnerable\nto type 1 man-in-the-middle.  If that's a concern, sending to a\nBitcoin address doesn't have that vulnerability, although there's\na small privacy tradeoff.  I have a feeling most of the time\npeople will get Bitcoin addresses off of non-SSL websites and\nunsigned cleartext e-mail, which is already vulnerable to type 1\nand type 2 through DNS poisoning.\n\nOne solution would be to use both the IP and Bitcoin addresses\nwhen sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses\nthe public key of the Bitcoin address to sign the new public key\nto prove that you're sending to who you think you are.  If the\nsystem starts to be used for real business purposes, I will\ncertainly implement that.  Another solution is to use SSL.\n\nFor now, it's pretty obvious that if you send to an IP, you didn't\ngive any other identifying information about the recipient, so\nyou're blindly sending to whoever answers that IP.\n\nAnother feature for later is an option to encrypt your wallet.\n "],["q","If I understand how that is done correctly, you just compute the\ntransaction into the block chain and let the intended recipient\n'discover' it, correct? "],["t","That's correct."],["q","An alternative could be to allow the network\nnodes to provide a resolution service, where they ask around for the\nnetwork address of a BitCoin address, and if that node is online, once a\nconsensus is agreed upon by the network for that address the sending\nBitCoin application connects directly there."],["t","It would be nice to only need the Bitcoin address and have the IP\nworked out behind the scenes.  Might have privacy or denial of\nservice issues.  Certainly before another sending method is\nimplemented, there's plenty of time now to fully think through the\ndesign and make sure it's the best way.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1,"sj":"Re: A few thoughts..."},{"f":"Dustin D. Trammell","d":1232067814,"b":[["q","Sending by IP requests a new public key, so yes, it's vulnerable\r\nto type 1 man-in-the-middle.  If that's a concern, sending to a\r\nBitcoin address doesn't have that vulnerability, although there's\r\na small privacy tradeoff.  I have a feeling most of the time\r\npeople will get Bitcoin addresses off of non-SSL websites and\r\nunsigned cleartext e-mail, which is already vulnerable to type 1\r\nand type 2 through DNS poisoning.\r","On Fri, 2009-01-16 at 03:42 +0800, Satoshi Nakamoto wrote:"],["t","\r\nTrue, but the upside to using the BitCoin address is that two people can\r\ncommunicate via a number of different channels to verify the address.\r\nIf my friend gets my address off my website, and thinks something fishy\r\nis going on, he can call me, or IM me, or email me, etc. to verify the\r\naddress.  An attacker would then have to basically be replacing my\r\naddress with the malicious one in every possible communications channel,\r\nincluding voice, which is a difficult feat.  MITMing the direct\r\ncommunication via network addresses doesn't have that benefit because\r\nthe attacker is spoofing the address or intercepting.  My friend can\r\nverify what my address is with me in the same ways, however verifying\r\nthe address doesn't actually improve the situation.\r\n\r"],["q","One solution would be to use both the IP and Bitcoin addresses\r\nwhen sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses\r\nthe public key of the Bitcoin address to sign the new public key\r\nto prove that you're sending to who you think you are.  If the\r\nsystem starts to be used for real business purposes, I will\r\ncertainly implement that.  Another solution is to use SSL.\r"],["t","\r\nThat is a good solution.  If you transact regularly you probably already\r\nhave the other person's BitCoin address in your address book.\r\n\r"],["q","Another feature for later is an option to encrypt your wallet.\r"],["t","\r\nOne thing that came to mind on this topic is the potential for BitCoin\r\nloss if you have a system failure.  The application doesn't seem to\r\nstore any data in the directory that it runs in, so I assume it's stored\r\nin the registry and other places (haven't cracked out ProcessExplorer\r\nyet to check myself), so it may be a good idea to have the application\r\nbe able to export everything that it needs for recovery to a file that\r\ncould be backed up off of the system.\r\n \r"],["q","It would be nice to only need the Bitcoin address and have the IP\r\nworked out behind the scenes.  Might have privacy or denial of\r\nservice issues.  Certainly before another sending method is\r\nimplemented, there's plenty of time now to fully think through the\r\ndesign and make sure it's the best way.\r"],["t","\r\nYou could always make that optional, such as a toggle that says\r\n'Advertise my BitCoin address to the network' that the user could turn\r\non or off.  If you're not found on the network when searched for by\r\nBitCoin address, the transaction is inserted into the block-chain as\r\nnormal.  If you are, the transaction meta-data could be communicated to\r\nthe network address.\r\n\r\nOne other thing I noticed today is that if you close the application it\r\ndoesn't appear to cleanly close it's network sockets (TCP RST's start\r\nflying).  Probably an item for the low-priority todo list (:\r\n\r\nTalk to you later,\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com","sj":"Re: A few thoughts..."},{"f":"Satoshi Nakamoto","d":1232131308,"b":[["q","One thing that came to mind on this topic is the potential for BitCoin\nloss if you have a system failure. The application doesn't seem to\nstore any data in the directory that it runs in, so I assume it's stored\nin the registry and other places (haven't cracked out ProcessExplorer\nyet to check myself), so it may be a good idea to have the application\nbe able to export everything that it needs for recovery to a file that\ncould be backed up off of the system."],["t","The files are in \"%appdata%\\Bitcoin\", that's the directory to\nbackup.  The data is stored in a transactional database DBM, so\nit should be safe from loss if there's a crash or power failure.\n\n%appdata% is per-user access privilege.  Most new programs like\nFirefox store their settings files there, despite the headwind of\nMicrosoft changing the directory name with every Windows release\nand being full of spaces and so long it runs off the screen."],["q","One other thing I noticed today is that if you close the application it\ndoesn't appear to cleanly close it's network sockets (TCP RST's start\nflying). Probably an item for the low-priority todo list (:"],["t","Just now added code to the next release for that.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1,"sj":"Re: A few thoughts..."}],"id":"x15"},{"k":"x","s":"dustin-trammell","t":"BitCoin Transfer","u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","m":[{"f":"Dustin D. Trammell","d":1232292182,"b":[["t","Hey Satoshi,\r\n\r\nAfter that first transfer of 25.00, you didn't send me another 100.00\r\ndid you?  I sent myself 100.00 from my BitCoin application at work to my\r\none at home using the BitCoin address rather than by IP.  My application\r\nat home has a 100.00 transfer received, however it's transaction details\r\nsay \"Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv\".  That\r\nis not my BitCoin address from work, so I assume this means that I\r\nreceived the payment encoded with a block that was computed by your\r\nclient?  If so, how did it know your name in addition to the BitCoin\r\naddress that generated it?  I don't recall there being a place in my\r\napplication to even put my name.\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com"},{"f":"Satoshi Nakamoto","d":1232297672,"b":[["t","It should be your Bitcoin address at home that you received it\nwith.  There's no way for it to know who it's from, so the best\nit can do is tell which of your addresses it was received on.\nYou can create multiple addresses and give a different address\nto each person and label them to help figure out who's sending\nto you.\n\nIt doesn't know any names other than what you tell it.  The name\nprinted there is what's associated in your address book for that\naddress, either under the Address Book button or the \"Change...\"\nbutton to the right of your Bitcoin address."],["q","Hey Satoshi,\n\nAfter that first transfer of 25.00, you didn't send me another 100.00\ndid you?  I sent myself 100.00 from my BitCoin application at work to my\none at home using the BitCoin address rather than by IP.  My application\nat home has a 100.00 transfer received, however it's transaction details\nsay \"Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv\".  That\nis not my BitCoin address from work, so I assume this means that I\nreceived the payment encoded with a block that was computed by your\nclient?  If so, how did it know your name in addition to the BitCoin\naddress that generated it?  I don't recall there being a place in my\napplication to even put my name.\n\n--\nDustin D. Trammell\ndtrammell@dustintrammell.com\nhttp://www.dustintrammell.com"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1,"sj":"Re: Bitcoin Transfer"},{"f":"Dustin D. Trammell","d":1232323772,"b":[["q","It should be your Bitcoin address at home that you received it\r\nwith.  There's no way for it to know who it's from, so the best\r\nit can do is tell which of your addresses it was received on.\r\nYou can create multiple addresses and give a different address\r\nto each person and label them to help figure out who's sending\r\nto you.\r","On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:"],["t","\r\nAh!  I didn't even notice it was my address at home, you're right (:  I\r\ndo have multiple addresses created at home so I didn't make the\r\nconnection.\r\n\r"],["q","It doesn't know any names other than what you tell it.  The name\r\nprinted there is what's associated in your address book for that\r\naddress, either under the Address Book button or the \"Change...\"\r\nbutton to the right of your Bitcoin address.\r"],["t","\r\nAhh you're right, 'Satoshi' is associated with the address that received\r\nthe payment under the Change button's addresses.  I don't recall setting\r\nthat value though, is that the default or something? (this is the first,\r\ndefault, address that the application generated itself when I first ran\r\nit)\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com","sj":"Re: Bitcoin Transfer"},{"f":"Satoshi Nakamoto","d":1232383445,"b":[["q","On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:\n> It should be your Bitcoin address at home that you received it\n> with.  There's no way for it to know who it's from, so the best\n> it can do is tell which of your addresses it was received on.\n> You can create multiple addresses and give a different address\n> to each person and label them to help figure out who's sending\n> to you.\n\nAh!  I didn't even notice it was my address at home, you're right (:  I\ndo have multiple addresses created at home so I didn't make the\nconnection.\n\n> It doesn't know any names other than what you tell it.  The name\n> printed there is what's associated in your address book for that\n> address, either under the Address Book button or the \"Change...\"\n> button to the right of your Bitcoin address.\n\nAhh you're right, 'Satoshi' is associated with the address that received\nthe payment under the Change button's addresses.  I don't recall setting\nthat value though, is that the default or something? (this is the first,\ndefault, address that the application generated itself when I first ran\nit)"],["t","The first default one is labelled \"Your Address\" when it's created.\n\nAll the places where address book labels are set are where the user manually sets it.  The only time it automatically adds a label is a blank one when you send to a new address.  I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.\n\nAddress book labels for receiving addresses is confusing but I'm not sure what else to do.  Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them.  That concept doesn't have much analogy in the real world.\n\nSatoshi"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"dtrammell@dustintrammell.com","fe":"satoshi@vistomail.com","s":1,"sj":"Re: Bitcoin Transfer"},{"f":"Dustin D. Trammell","d":1232416703,"b":[["q","The first default one is labelled \"Your Address\" when it's created.\r\n\r\nAll the places where address book labels are set are where the user manually sets it.  The only time it automatically adds a label is a blank one when you send to a new address.  I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.\r","On Tue, 2009-01-20 at 00:44 +0800, Satoshi Nakamoto wrote:"],["t","\r\nThat would make sense, I bet that's what happened.\r\n\r"],["q","Address book labels for receiving addresses is confusing but I'm not sure what else to do.  Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them.  That concept doesn't have much analogy in the real world.\r"],["t","\r\nI think had it said \"Received with address: X\" rather than just\r\n\"Received with: X\" I think I would have understood, although I'm sure\r\nthat address being mislabeled 'Satoshi' was the primary reason for my\r\ninitial confusion.  You're right though, there's really nothing\r\ncomparable in the current financial system that people are used to other\r\nthan maybe being able to use multiple recipient email addresses for\r\nPayPal.  Perhaps it could say \"Received payment to: X\"?\r\n\r\n-- \r\nDustin D. Trammell\r\ndtrammell@dustintrammell.com\r\nhttp://www.dustintrammell.com\r"]],"u":"https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/Satoshi_Nakamoto.zip","to":"satoshi@vistomail.com","fe":"dtrammell@dustintrammell.com","sj":"Re: Bitcoin Transfer"}],"id":"x16"},{"k":"x","s":"mike-hearn","t":"Questions about BitCoin","u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","m":[{"f":"Mike Hearn","d":1239540360,"b":[["t","Hi Satoshi,\n\nI read your paper on BitCoin with great interest. I found it a bit\nconfusing though - I believe it may be easier to follow if you provide\nsome examples.\n\nSpecifically, it's not quite clear to me what blocks contain. If I\nunderstand correctly, there is only one (or maybe a few) global\nchain[s] into which all transactions are hashed. If there is only one\nchain recording \"the story of the economy\" so to speak, how does this\nscale? In an imaginary planet-wide deployment there would be millions\nof even billions of transactions per hour being hashed into the chain.\nI realize that each PoW can wrap many transactions in one block,\nnonetheless, that's a large amount of data to hash. If there are many\nchains, how are transactions assigned to each chain such that it is\nstill difficult to overpower the network? Eg, if there are 10 global\nchains, the amount of cpu power you need to beat the system is only\n10% of what it was previously.\n\nI also wonder if the assumption of 1 core = 1 vote is sound. If the\nmajority of nodes are on standard computers, it seems likely that an\nattacker could use FPGA or custom ASICs to get significantly better\nperformance. What are your thoughts on using custom hardware to beat\nthe chain?\n\nI found the section on incentives hard to follow. In particular, I'm\nnot clear on what triggers the transition from minting new coins as a\nreason to run a node, to charging transaction fees (isn't the point of\nBitCoin largely to zero transaction costs anyway?). Presumably there's\nsome human in charge of the system - eg, you decided somehow that 24\nmillion coins was a good number to have, and would distribute some\nkind of rules file saying \"coins minted after this timestamp must have\nan N+1 zero bits prefix\", which honest nodes enforce.\n\nHow did you decide on the inflation schedule for v1? Where did 24\nmillion coins come from? What denominations are these coins? You\nmention a way to combine and split value but I'm not clear on how this\nworks. For instance are bitcoins always denominated by an integer or\ncan you have fractional bitcoins?\n\nSo many questions :) But it's rare that I encounter truly\nrevolutionary ideas. The last time I was this excited about a new\nmonetary scheme was when I discovered Ripple. If you have any thoughts\non Ripple, I'd also love to hear them.\n\nthanks -mike"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"satoshin@gmx.com","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1239576240,"b":[["t","Hi Mike,\n\nI'm glad to answer any questions you have.  If I get time, I ought to write a FAQ to supplement the paper.\n\nThere is only one global chain.\n\nThe existing Visa credit card network processes about 15 million Internet purchases per day worldwide.  Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost.  It never really hits a scale ceiling.  If you're interested, I can go over the ways it would cope with extreme size.\n\nBy Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10.  Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.\n\nI don't anticipate that fees will be needed anytime soon, but if it becomes too burdensome to run a node, it is possible to run a node that only processes transactions that include a transaction fee.  The owner of the node would decide the minimum fee they'll accept.  Right now, such a node would get nothing, because nobody includes a fee, but if enough nodes did that, then users would get faster acceptance if they include a fee, or slower if they don't.  The fee the market would settle on should be minimal.  If a node requires a higher fee, that node would be passing up all transactions with lower fees.  It could do more volume and probably make more money by processing as many paying transactions as it can.  The transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces.\n\nEventually, most nodes may be run by specialists with multiple GPU cards.  For now, it's nice that anyone with a PC can play without worrying about what video card they have, and hopefully it'll stay that way for a while.  More computers are shipping with fairly decent GPUs these days, so maybe later we'll transition to that.\n\nA key aspect of Bitcoin is that the security of the network grows as the size of the network and the amount of value that needs to be protected grows.  The down side is that it's vulnerable at the beginning when it's small, although the value that could be stolen should always be smaller than the amount of effort required to steal it.  If someone has other motives to prove a point, they'll just be proving a point I already concede.\n\nMy choice for the number of coins and distribution schedule was an educated guess.  It was a difficult choice, because once the network is going it's locked in and we're stuck with it.  I wanted to pick something that would make prices similar to existing currencies, but without knowing the future, that's very hard.  I ended up picking something in the middle.  If Bitcoin remains a small niche, it'll be worth less per unit than existing currencies.  If you imagine it being used for some fraction of world commerce, then there's only going to be 21 million coins for the whole world, so it would be worth much more per unit.  Values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000.  There's plenty of granularity if typical prices become small.  For example, if 0.001 is worth 1 Euro, then it might be easier to change where the decimal point is displayed, so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is displayed as 1.\n\nRipple is interesting in that it's the only other system that does something with trust besides concentrate it into a central server.\n\nSatoshi\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1239629940,"b":[["t","Thanks Satoshi,\n\nI tried the app yesterday. It seems to work pretty well running on\nWine (I tried it on MacOS but it should run on Linux too, and will try\nthat next week when I am back at work).\n\nIn the lower right hand corner it has a block count which increases\nrapidly and then stops. Is this the length of the global chain? It\nseems to advance far too fast for that. Or is this the number of\ngenesis blocks that have been tried but did not result in a partial\ncollision? I'm not sure if the way it stops and starts is expected, or\nsome glitch caused by it running under emulation. My best guess - it\nis the length of the global chain, and the rapid advance at the start\nis as the software downloads and verifies the preceding blocks in the\nchain as being valid.\n\nWith regards to the buyer/seller experience, I understand that the\nglobal chain advances at about 6-7 blocks per hour under the current\nsettings. If we assume that 0.1% is a good risk rate, then z=5 thus\nany transaction must wait a bit less than an hour before being\nsolidified in the chain. As micropayments for things like web content\nor virtual goods are by definition something that requires low\noverhead, waiting an hour seems like quite a significant hurdle.\n\nI understand that nodes attempt to find a POW to advance the global\nchain in an uncoordinated fashion. This sentence however:\n\n    \"If a majority of CPU power is controlled by honest nodes, the\nhonest chain will grow the  fastest and outpace any competing chains.\"\n\nis confusing for me, because it appears the only way the honest chain\ncan grow faster than a chain worked on by 1 attacking cpu is if the\nkeyspace to scan looking for a partial collision is sharded evenly\namongst the participating honest nodes. That way the speed at which\ncollisions are found would be proportional to the number of nodes. Yet\nI don't see any discussion of such work sharding, which obviously adds\ncomplexity. Likewise:\n\n   \"To compensate for increasing hardware speed and varying interest\nin running nodes over time,\nthe proof-of-work difficulty is determined by a moving average\ntargeting an average number of\nblocks per hour.  If they're generated too fast, the difficulty increases.\"\n\nHow is the required difficulty of each block communicated through the\nnetwork and agreed upon?\n\nThanks once again. I have yet more questions but this is enough for\none email :) I will be happy to summarize these discussions into an\nFAQ-like document at some point. Apologies if the questions seem\ntrivial.\n\n-mike\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Mike Hearn","d":1239663060,"b":[["t","Something else that isn't clear to me - does the global chain only get\nextended when there is actual work to do? Currently it seems to grow\nall the time, although there are only a few people in the network. So\npresumably it gets extended with null blocks. Is this actually\nrequired? The timestamping doesn't have to be actually in parallel\nwith real time does it ... it's merely establishing an ordering of\nevents.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1239663600,"b":[["t","Mike Hearn wrote:\n\nMy best guess - it\nis the length of the global chain, and the rapid advance at the start\nis as the software downloads and verifies the preceding blocks in the\nchain as being valid.\n\nRight.  I'm trying to think of more clear wording for that, maybe \"%d network blocks\" or \"%d block chain\".\n\nIf we assume that 0.1% is a good risk rate, then z=5 thus\nany transaction must wait a bit less than an hour before being\nsolidified in the chain. As micropayments for things like web content\nor virtual goods are by definition something that requires low\noverhead, waiting an hour seems like quite a significant hurdle.\n\nFor the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers.\n\nFor micropayments, you can safely accept the payment immediately.  The size of the payment is too small for the effort to steal it. Micropayments are almost always for intellectual property, where there's no physical loss to the merchant.  Anyone trying to steal a micropayment would probably not be a paying customer anyway, and if they want to steal intellectual property they can use the file sharing networks.\n\nCurrently, businesses accept a certain chargeoff rate.  I believe the risk with 1 or even 0 confirming blocks will be much less than the rate of chargebacks on verified credit card transactions.\n\nThe usual scam against a merchant that doesn't wait for confirming blocks would be to send a payment to a merchant, then quickly try to propagate a double-spend to the network before the merchant's copy. What the merchant can do is broadcast his transaction and then monitor the network for any double-spend copies.  The thief would not be able to broadcast during the monitoring period or else the merchant's node would receive a copy.  The merchant would only have to monitor for a minute or two until most of the network nodes have his version and it's too late for the thief's version to catch up and reach many nodes.  With just a minute or two delay, the chance of getting away without paying could be made much too low to scam.  A thief usually needs a high probability of getting an item for free to make it worthwhile.  Using a lot of CPU power to do the brute force attack discussed in the paper in addition to the above scam would not increase the thief's chances very much.\n\nAnything that grants access to something, like something that takes a while to download, access to a website, web hosting, a subscription or service, can be cancelled a few minutes later if the transaction is rejected.\n\nis confusing for me, because it appears the only way the honest chain\ncan grow faster than a chain worked on by 1 attacking cpu is if the\nkeyspace to scan looking for a partial collision is sharded evenly\namongst the participating honest nodes. That way the speed at which\ncollisions are found would be proportional to the number of nodes. Yet\nI don't see any discussion of such work sharding, which obviously adds\ncomplexity.\n\nThe keyspace is huge, 2^256.  The thing being hashed includes the node's public key and a random nonce, so the chance of any two nodes duplicating work on the same space is negligible.\n\nHow is the required difficulty of each block communicated through the\nnetwork and agreed upon?\n\nIt's not communicated.  The formula is hardcoded in the program and every node does the same calculation to know what difficulty is required for the next block.  If someone diverged from the formula, their block would not be accepted by the majority.\n\nThanks once again. I have yet more questions but this is enough for\none email :) I will be happy to summarize these discussions into an\nFAQ-like document at some point. Apologies if the questions seem\ntrivial.\n\nNo problem, thanks for testing it on Mac Wine.\n\nSatoshi\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Satoshi Nakamoto","d":1239664260,"b":[["t","It keeps getting extended all the time.  If it stopped, an attacker would have time to catch up.  Don't worry, empty blocks aren't very big.\n\nAs you say, it's the order of events that matters.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1239664680,"b":[["t","Oh yes, of course, that's fundamental. Silly me. Thanks for your\nanswers. I'd recommend being over-explicit for early versions of the\nsoftware, something like  \"Global chain is currently %d blocks long\".\n\nI guess the key problem right now is that once you generate coins,\nthere's nobody to test it with, even for dummy transactions. Is there\na plan for a mailing list or some kind of trivial marketplace to give\npeople something to do with their newly minted bitcoins?"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1239738060,"b":[["t","I started implementing a marketplace feature earlier that facilitates offering things for sale and taking orders, it's only half done though.  A bit like e-bay but without auctions, just \"buy now\".  Among other things, it would make it easy for anyone to offer currency exchange.\n\nIf you send to 1PhUXucRd8FzQved2KGK3g1eKfTHPGjgFu and e-mail me your bitcoin address, or IP if you can accept incoming connections, I'll send back the same amount +50.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1240067280,"b":[["t","Hi Satoshi,\n\nI sent you 32.51 coins, my bitcoin address is 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7rnj5n\n\nMy IP is currently 84.73.233.199, however, it's a laptop so may or may\nnot be online at the time you act on this mail. I suggest using the\nbitcoin address instead. It'd be convenient if the same comment\nfunctionality was available via indirect transfer. Can the comment be\nencrypted using the public key of the receiver and placed into a\nblock?\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1240078560,"b":[["t","I sent back 32.51 and 50.00.\n\nI badly wanted to find some way to include a comment with indirect transfers, but there just wasn't a way to do it.  Bitcoin uses EC-DSA, which was essential for making the block chain compact enough to be practical with today's technology because its signatures are an order of magnitude smaller than RSA.  But EC-DSA can't encrypt messages like RSA, it can only be used to verify signatures.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1240089900,"b":[["t","Thanks. I sent you back 50, so now we're even.\n\nFor some reason your transfer to me shows up as \"From: unknown\" even\nthough I added you to my address book.\n\nI have a \"Generated (not accepted)\" line in my transaction list, it\nseems like an attempt to generate a coin went wrong somehow. Not sure\nwhat happened here - presumably my node successfully solved a block\nbut then I went offline before it was sent to the network?\n\nI suppose for sending metadata with a transaction some other mechanism\nwill be needed, for instance, broadcast of encrypted messages\nassociated with a transaction that persist for (say) a month, with\nsome kind of budget on how much storage a node can use for messages.\nAlternatively, a payee could generate some reference number which is\nof some significance to themselves but otherwise opaque, and give it\nto the payer, thus it does not need to be encrypted and can be put\ninto the block directly.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1240095120,"b":[["t","Got the 50.\n\nTransactions sent to a bitcoin address will always say \"from: unknown\".  The transaction only tells who it's to.  Sending by bitcoin address has a number of problems, but it's so nice having the fallback option to be able to send to anyone whether they're online or not.  There are a number of ideas to try to improve things later.  For now, if things work out like the real world where the vast majority of transactions are with merchants, they'll pretty much always make sure to set up to receive by IP.  The P2P file sharing networks seem fairly successful at getting a large percentage of their users to set up their firewalls to forward a port.\n\nThe \"Generated (not accepted)\" normally happens if two nodes find a block at close to the same time, one of them will not be accepted.  It's normal and unavoidable.  I plan in v0.1.6 to hide those, since they're just confusing and annoying and there's no reason for users to have to see them.  While the network is still small like it is now, if you can't receive incoming connections you're at more of a disadvantage because you can't receive block announcements as directly.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1240096980,"b":[["t","Yes, I believe most P2P clients use the UPnP protocol to get routers\nto open up the port automatically. That would probably improve the\nlisten rate significantly. I just discovered DMZ wasn't enabled on my\nrouter, though I thought it was. That's now fixed.\n\nIs there a way to be told of new versions? Does the app auto update\nitself? Again, some kind of mailing list would be excellent.\n\nI was thinking through how a practical micropayment implementation for\nthe web might work in the last few days. One key issue is ensuring\nmicropayments are fully automatic, yet can't be easily abused to drain\nthe users account. I think the right approach would be to allow any\nwebsite that presents an EV SSL cert to automatically request a\nmicropayment, by default the browser always accepts as long as the\ncharge is \"low\" and displays a small notification of what has\noccurred. Sites can then show that content requires payment in any way\nthat suits their site design. Abusive sites that don't meet some\nsimple guidelines (eg, showing unambiguously that clicking a link will\ntrigger payment, or taking payment from direct search engine links)\nwould simply have their SSL cert blacklisted, much like anti-phishing\nfilters work today.\n\nThe protocol could be very straightforward and implemented by a\nFirefox extension or an IE BHO. Some static file (eg, a protocol\nbuffer) is hosted on the site. It specifies the charge, a transaction\ndescription, the target IP and a URL for the browser to load after the\ntransaction was accepted by the target node, to which the user\nidentifier is sent in a URL parameter.  The site can then give back a\ncookie and the paywalled content. The entire process is automatic and\nsimply results in, say, a little coin animation in the URL bar. Thus\nit's as convenient as regular web browsing. The users software would\nhave some limit on what payments are automatically accepted.\n\nThe main problem with this approach is that somebody has to decide\nwhat the user interface guidelines are, then enforce them via\nblacklisting, as well as decide what payment requirements are low\nenough to be automatic vs requiring a user prompt. This introduces a\ntrusted authority back into the system. However, it's one that the\nuser can choose in an open market.\n\nBy the way, if you're not already using protocol buffers for the\nnode-to-node traffic, I recommend them. We use them here at Google for\neverything, they solve a lot of versioning problems simply and\nefficiently."]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1240107240,"b":[["t","The list is:\nbitcoin-list@lists.sourceforge.net\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list\nArchives:\nhttp://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list\n\nI'll always announce new versions there.  Automatic update, or at least notification of new versions, is definitely on the list.  There could potentially be necessary changes in the future where nobody will want to talk to you until you upgrade, and there needs to be code in the older version to convey that to the user.  This is all the harder in the context of not trusting anyone.\n\nYour approach to micropayments sounds right.  At first, it might be a good idea to default to asking permission until the user gets comfortable and is ready to set it to automatic.  The end goal though should get to something like you describe, where it's similar to using your cell phone without really having to think about the per minute charges.\n\nI looked at Google protocol buffers when they were released last year, but I had already written everything by then.  What I did was something similar to Boost Serialisation.  For this application, where I was parsing messages from strangers who might have extreme incentive to hack the protocol, it was necessary to make it as basic as possible so I could crawl over every line of code to convince myself it was airtight.  It became clear that any unnecessary degrees of freedom in the binary format multiplied the potential angles of attack.  You guys are so right though to standardize across the company on protocol buffers.  I think you've got the optimal solution in the general case."]],"u":"https://plan99.net/~mike/satoshi-emails/thread1.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread1.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"}],"id":"x17"},{"k":"x","s":"mike-hearn","t":"Lack of chargeback support","u":"https://plan99.net/~mike/satoshi-emails/thread2.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread2.html","m":[{"f":"Mike Hearn","d":1240695000,"b":[["t","Hi Satoshi,\n\nI just read the following wiki page:\n\nhttp://en.wikipedia.org/wiki/Chargeback\n\nwhich claims that \"U.S. debit card holders are guaranteed reversal\nrights by Federal Reserve Regulation E under the Electronic Funds\nTransfer Act. Similar rights extend globally pursuant to the rules\nestablished by the corresponding card association or bank network.\"\n\nThe \"Electronic Funds Transfer Act\" sounds awfully generic, do you\nthink it'd apply to BitCoin? If so, would the inability to do\nchargebacks risk making it illegal?"]],"u":"https://plan99.net/~mike/satoshi-emails/thread2.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread2.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1240791060,"b":[["t","I am not a lawyer and I can't possibly answer that.  I suppose if the law applies to a bank or financial institution or other intermediary, then it would not apply since there is no bank involved, only two parties trading directly with each other, as they would in person with cash or barter with physical commodities.\n\nBitcoin is fundamentally designed to be able to do non-reversible transactions, and there certainly are applications that need that.\n\nIf someone wants the possibility of chargeback, they can use an escrow transaction, which isn't implemented yet but will be one of the next things.  For instance, a transaction can be written to designate a third party to decide whether it is returned if the payer does not release it, with auto-release after a number of days.  I'll implement a more basic form of escrow first, but the network infrastructure includes a predicate language that can express any number of options."]],"u":"https://plan99.net/~mike/satoshi-emails/thread2.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread2.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"}],"id":"x18"},{"k":"x","s":"martti-malmi","t":"Re: Bitcoin","u":"https://mmalmi.github.io/satoshi/#email-1","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1241284018,"b":[["t","Thanks for starting that topic on ASC, your understanding of bitcoin is\nspot on.  Some of their responses were rather Neanderthal, although I\nguess they're so used to being anti-fiat-money that anything short of\ngold isn't good enough.  They concede that something is flammable, but\nargue that it'll never burn because there'll never be a spark.  Once\nit's backed with cash, that might change, but I'd probably better\nrefrain from mentioning that in public anymore until we're closer to\nready to start.  I think we'll get flooded with newbies and we need to\nget ready first.\n\nWhat we need most right now is website writing.  My writing is not that\ngreat, I'm a much better coder.  Maybe you could create the website on\nsourceforge, which is currently blank.  If you can write a FAQ, I can\ngive you a compilation of my replies to questions in e-mail and forums\nfor facts and details and ideas.\n\nCodewise, there's not much that's easy right now.  One thing that's\nneeded is an interface for server side scripting languages such as Java,\nPython, PHP, ASP, etc.  Bitcoin would be running on the web server, and\nserver side script could call it to do transactions.  It's Windows, so I\nguess OLE/COM is the interface.\n\nOne easy thing that really helps is to run a node that can accept\nincoming connections (forward port 8333 on your firewall) to make sure\nthat new users who try it out have someone to connect to.  If they run\nit and get no connections, they'll probably just give up.\n\nSatoshi"],["q","Message body follows:\n\nHello,\n\nI'm Trickstern from the anti-state.com forum, and I would\nlike to help with Bitcoin, if there's something I can do.\n\nI have a good touch on Java and C languages from school\ncourses (I'm studying CS), but not so very much development\nexperience yet. I think I could learn the C++ tricks quite\neasily on that basis. I could also do testing or\ndocumentation.\n\nBest regards,\nMartti Malmi\n\n--\nThis message has been sent to you, a registered SourceForge.net user,\nby another site user, through the SourceForge.net site.  This message\nhas been delivered to your SourceForge.net mail alias.  You may reply\nto this message using the \"Reply\" feature of your email client, or\nusing the messaging facility of SourceForge.net at:\nhttps://sourceforge.net/sendmessage.php?touser=2495503","Martti Malmi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-1","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <sirius-m@users.sourceforge.net>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1241327316,"b":[["t","All right, I can do the website and the FAQ. I'll start writing the\nFAQ now with the questions that I can think of.\n\nI have a feature suggestion for the program: a UI tool for creating\npassword protected private keys and saving them into a custom\nlocation. Backups of the key will be needed to be safe from losing the\ncontrol of your coins, and for using the coins on more than one\ncomputers. Password protection would be needed to make using your\nmoney more difficult for someone who happens to find your key file.\n\nMaybe a bug/feature tracker could be set up at the Sourceforge project page?\n\nI'm running a bitcoin node always when my PC is powered on, which\nmeans about 24/7. Bitcoin is a great project, and it's really cool to\nparticipate!\n\n-Martti Malmi\n\nQuoting Satoshi Nakamoto <satoshin@gmx.com>:"],["q","Thanks for starting that topic on ASC, your understanding of bitcoin is\nspot on.  Some of their responses were rather Neanderthal, although I\nguess they're so used to being anti-fiat-money that anything short of\ngold isn't good enough.  They concede that something is flammable, but\nargue that it'll never burn because there'll never be a spark.  Once\nit's backed with cash, that might change, but I'd probably better\nrefrain from mentioning that in public anymore until we're closer to\nready to start.  I think we'll get flooded with newbies and we need to\nget ready first.\n\nWhat we need most right now is website writing.  My writing is not that\ngreat, I'm a much better coder.  Maybe you could create the website on\nsourceforge, which is currently blank.  If you can write a FAQ, I can\ngive you a compilation of my replies to questions in e-mail and forums\nfor facts and details and ideas.\n\nCodewise, there's not much that's easy right now.  One thing that's\nneeded is an interface for server side scripting languages such as\nJava, Python, PHP, ASP, etc.  Bitcoin would be running on the web\nserver, and server side script could call it to do transactions.  It's\nWindows, so I guess OLE/COM is the interface.\n\nOne easy thing that really helps is to run a node that can accept\nincoming connections (forward port 8333 on your firewall) to make sure\nthat new users who try it out have someone to connect to.  If they run\nit and get no connections, they'll probably just give up.\n\nSatoshi\n\nMartti Malmi wrote:\n> Message body follows:\n>\n> Hello,\n>\n> I'm Trickstern from the anti-state.com forum, and I would like to\n> help with Bitcoin, if there's something I can do.\n>\n> I have a good touch on Java and C languages from school courses\n> (I'm studying CS), but not so very much development experience yet.\n>  I think I could learn the C++ tricks quite easily on that basis. I\n>  could also do testing or documentation.\n>\n> Best regards,\n> Martti Malmi\n>\n> --\n> This message has been sent to you, a registered SourceForge.net user,\n> by another site user, through the SourceForge.net site.  This message\n> has been delivered to your SourceForge.net mail alias.  You may reply\n> to this message using the \"Reply\" feature of your email client, or\n> using the messaging facility of SourceForge.net at:\n> https://sourceforge.net/sendmessage.php?touser=2495503\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-2","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1241389946,"b":[["q","All right, I can do the website and the FAQ. I'll start writing the FAQ\nnow with the questions that I can think of.","mmalmi@cc.hut.fi wrote:"],["t","That would be great!  I added you (dmp1ce) as a dev to the sourceforge\nproject and gave you access to edit the web space and everything."],["q","I have a feature suggestion for the program: a UI tool for creating\npassword protected private keys and saving them into a custom location.\nBackups of the key will be needed to be safe from losing the control of\nyour coins, and for using the coins on more than one computers. Password\nprotection would be needed to make using your money more difficult for\nsomeone who happens to find your key file."],["t","Definitely.  This will be an absolutely essential feature once things\nget going, making it so you can lock your wealth up with strong\nencryption and back it up more securely than any physical safe.  So far\nI've been putting it off in favour of other features because it's not\ncrucial yet until bitcoins start to have value.\n\nI plan to work on the escrow feature next, which is needed to make\nactual trades for physical stuff safer and before backing the currency\nwith fiat money can begin."],["q","I'm running a bitcoin node always when my PC is powered on, which means\nabout 24/7. Bitcoin is a great project, and it's really cool to\nparticipate!"],["t","Thanks!  Right now there are a lot of people on the network who can't\nreceive incoming connections, so every node that can really helps.\nHaving more helps keep down the \"(not accepted)\" issue for now until I\nreduce the chances of that happening in v0.1.6.\n\nI guess one answer for the FAQ should be how to set up your firewall to\nforward port 8333 so you can receive incoming connections.  The question\ncould be something like \"what if I have 0 connections\" and that could be\nthe answer that it might be because the nodes you can connect with is\nlimited if you don't set that up.\n\nHere's a compilation of questions I've answered in forums and e-mail\nthat should help you see what questions are frequently asked and some\nanswers I've used.  It's not intended to use all or most of the material\nhere, just pick and choose.  This is just a dump of everything I've\nanswered.\n\nSome issues that we don't have easy answers for are best not to bring\nup.  Casual users seems content to assume that the system works as\nstated (which it does), and getting into the design details just opens a\ncan of worms that can't be answered without a deep understanding of the\nsystem.  The advanced questions I've received have mostly been unique\nper person and best answered individually.\n\n**** QUESTION AND ANSWER DUMP ****\n\nAny questions used for the FAQ should probably be rephrased.\n\nquestions:"],["q","The bottom of the UI shows:\n\nGenerating        4 connections     4024 blocks     164 transactions\n\nI understand \"generating\"; I assume I am connected to 4 other nodes; and\nI know I have recorded 164 transactions (including failed generation\nattempts).  I'm not clear what the \"blocks\" figure describes.  It's much\nsmaller than the total of all the blocks shown against all my "],["t","transactions."],["t","It's the total number of blocks in the block chain, meaning the\nnetwork's block chain, which everyone has a copy of.  Every Bitcoin node\ndisplays the same number and it goes up about every 10 minutes whenever\nsomeone generates a block.  When you haven't had it running for a while,\nonce you're connected it spins up rapidly as it downloads what was\ngenerated while you were gone to catch up.  I'm not sure exactly how to\ndescribe it (that would fit on the status bar in 1 word, maybe 2 words\nmax), any ideas?\n\nThe blocks number in the status column next to your transactions is the\nnumber of blocks that have come after that transaction.  Your\ntransaction is essentially \"in\" that many blocks.\n\nSatoshi"],["q","My best guess - it\nis the length of the global chain, and the rapid advance at the start\nis as the software downloads and verifies the preceding blocks in the\nchain as being valid."],["t","Right.  I'm trying to think of more clear wording for that, maybe \"%d\nnetwork blocks\" or \"%d block chain\"."],["q","I'm having an unusual run of (block not-accepted) failures, and "],["t","thought I'd let you know in"],["q","case this was of any significance."],["t","What rate of not-accepted did you see?  I didn't see anything unusual on\nmy end.  If you had more than, say, 4 in a row, that would be abnormal\nand probably a loss of network communication.  If it's scattered and\nless than 25%, just random bad luck.  It's normal and harmless to\nrandomly get some per cent of not-accepted, and of course randomness can\nsometimes bunch up and look like a pattern.\n\nThe idea of an option to View/Hide unaccepted blocks is a good one, as\nwell as View/Hide all generated blocks so you can more easily see\nincoming transactions.  Seeing the unaccepted blocks is just annoying\nand frustrating.  Everyone faces the same rate of unaccepted, it's just\na part of the process.  It would probably be best to default to hide\nunaccepted blocks, so as not to show giving and taking away something\nthat never was, and not show new generated blocks at all until they have\nat least one confirmation.  It would only mean finding out you have a\ngenerated block 15 minutes later than normal, and then you still have\n119 blocks to go before it matures anyway.  This is on the to-do list\nfor v0.1.6.\n\nSatoshi\n\n[note: I have some improvements in 0.1.6 to reduce this problem somewhat,\nand it'll also improve when the network is larger]"],["q","For some reason your transfer to me shows up as \"From: unknown\" even\nthough I added you to my address book.\n\nI have a \"Generated (not accepted)\" line in my transaction list, it\nseems like an attempt to generate a coin went wrong somehow. Not sure\nwhat happened here - presumably my node successfully solved a block\nbut then I went offline before it was sent to the network?"],["t","Transactions sent to a bitcoin address will always say \"from: unknown\".\n  The transaction only tells who it's to.  Sending by bitcoin address\nhas a number of problems, but it's so nice having the fallback option to\nbe able to send to anyone whether they're online or not.  There are a\nnumber of ideas to try to improve things later.  For now, if things work\nout like the real world where the vast majority of transactions are with\nmerchants, they'll pretty much always make sure to set up to receive by\nIP.  The P2P file sharing networks seem fairly successful at getting a\nlarge percentage of their users to set up their firewalls to forward a port.\n\nI badly wanted to find some way to include a comment with indirect\ntransfers, but there just wasn't a way to do it.  Bitcoin uses EC-DSA, which\nwas essential for making the block chain compact enough to be practical with\ntoday's technology because its signatures are an order of magnitude smaller\nthan RSA.  But EC-DSA can't encrypt messages like RSA, it can only be used\nto verify signatures.\n\nThe \"Generated (not accepted)\" normally happens if two nodes find a\nblock at close to the same time, one of them will not be accepted.  It's\nnormal and unavoidable.  I plan in v0.1.6 to hide those, since they're\njust confusing and annoying and there's no reason for users to have to\nsee them.  While the network is still small like it is now, if you can't\nreceive incoming connections you're at more of a disadvantage because\nyou can't receive block announcements as directly."],["q","...So far it has two \"Generated\" messages, however the\n\"Credit\" field for those is 0.00 and the balance hasn't changed.  Is\nthis due to the age/maturity requirement for a coin to be valid?"],["t","Right, the credit field stays 0.00 until it matures, then it'll be\n50.00.  BTW, you can doubleclick on a line for details."],["q","...understand correctly, there is only one (or maybe a few) global\nchain[s] into which all transactions are hashed. If there is only one\nchain recording \"the story of the economy\" so to speak, how does this\nscale? In an imaginary planet-wide deployment there would be millions\nof even billions of transactions per hour being hashed into the chain..."],["q","...I found the section on incentives hard to follow. In particular, I'm\nnot clear on what triggers the transition from minting new coins as a\nreason to run a node, to charging transaction fees (isn't the point of\nBitCoin largely to zero transaction costs anyway?). Presumably there's\nsome human in charge of the system..."],["q","...How did you decide on the inflation schedule for v1? Where did 21\nmillion coins come from? What denominations are these coins? You\nmention a way to combine and split value but I'm not clear on how this\nworks. For instance are bitcoins always denominated by an integer or\ncan you have fractional bitcoins?..."],["q","...it's rare that I encounter truly\nrevolutionary ideas. The last time I was this excited about a new\nmonetary scheme was when I discovered Ripple. If you have any thoughts\non Ripple, I'd also love to hear them."],["t","There is only one global chain.\n\nThe existing Visa credit card network processes about 15 million\nInternet purchases per day worldwide.  Bitcoin can already scale much\nlarger than that with existing hardware for a fraction of the cost.  It\nnever really hits a scale ceiling.  If you're interested, I can go over\nthe ways it would cope with extreme size.\n\nBy Moore's Law, we can expect hardware speed to be 10 times faster in 5\nyears and 100 times faster in 10.  Even if Bitcoin grows at crazy\nadoption rates, I think computer speeds will stay ahead of the number of\ntransactions.\n\nI don't anticipate that fees will be needed anytime soon, but if it\nbecomes too burdensome to run a node, it is possible to run a node that\nonly processes transactions that include a transaction fee.  The owner\nof the node would decide the minimum fee they'll accept.  Right now,\nsuch a node would get nothing, because nobody includes a fee, but if\nenough nodes did that, then users would get faster acceptance if they\ninclude a fee, or slower if they don't.  The fee the market would settle\non should be minimal.  If a node requires a higher fee, that node would\nbe passing up all transactions with lower fees.  It could do more volume\nand probably make more money by processing as many paying transactions\nas it can.  The transition is not controlled by some human in charge of\nthe system though, just individuals reacting on their own to market forces.\n\nA key aspect of Bitcoin is that the security of the network grows as the\nsize of the network and the amount of value that needs to be protected\ngrows.  The down side is that it's vulnerable at the beginning when it's\nsmall, although the value that could be stolen should always be smaller\nthan the amount of effort required to steal it.  If someone has other\nmotives to prove a point, they'll just be proving a point I already concede.\n\nMy choice for the number of coins and distribution schedule was an\neducated guess.  It was a difficult choice, because once the network is\ngoing it's locked in and we're stuck with it.  I wanted to pick\nsomething that would make prices similar to existing currencies, but\nwithout knowing the future, that's very hard.  I ended up picking\nsomething in the middle.  If Bitcoin remains a small niche, it'll be\nworth less per unit than existing currencies.  If you imagine it being\nused for some fraction of world commerce, then there's only going to be\n21 million coins for the whole world, so it would be worth much more per\nunit.  Values are 64-bit integers with 8 decimal places, so 1 coin is\nrepresented internally as 100000000.  There's plenty of granularity if\ntypical prices become small.  For example, if 0.001 is worth 1 Euro,\nthen it might be easier to change where the decimal point is displayed,\nso if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is\ndisplayed as 1.\n\nRipple is interesting in that it's the only other system that does\nsomething with trust besides concentrate it into a central server.\n\nSatoshi"],["q","If we assume that 0.1% is a good risk rate, then z=5 thus\nany transaction must wait a bit less than an hour before being\nsolidified in the chain. As micropayments for things like web content\nor virtual goods are by definition something that requires low\noverhead, waiting an hour seems like quite a significant hurdle."],["t","For the actual risk, multiply the 0.1% by the probability that the buyer\nis an attacker with a huge network of computers.\n\nFor micropayments, you can safely accept the payment immediately.  The\nsize of the payment is too small for the effort to steal it.\nMicropayments are almost always for intellectual property, where there's\nno physical loss to the merchant.  Anyone trying to steal a micropayment\nwould probably not be a paying customer anyway, and if they want to\nsteal intellectual property they can use the file sharing networks.\n\nCurrently, businesses accept a certain chargeoff rate.  I believe the\nrisk with 1 or even 0 confirming blocks will be much less than the rate\nof chargebacks on verified credit card transactions.\n\nThe usual scam against a merchant that doesn't wait for confirming\nblocks would be to send a payment to a merchant, then quickly try to\npropagate a double-spend to the network before the merchant's copy. What\nthe merchant can do is broadcast his transaction and then monitor the\nnetwork for any double-spend copies.  The thief would not be able to\nbroadcast during the monitoring period or else the merchant's node would\nreceive a copy.  The merchant would only have to monitor for a minute or\ntwo until most of the network nodes have his version and it's too late\nfor the thief's version to catch up and reach many nodes.  With just a\nminute or two delay, the chance of getting away without paying could be\nmade much too low to scam.  A thief usually needs a high probability of\ngetting an item for free to make it worthwhile.  Using a lot of CPU\npower to do the brute force attack discussed in the paper in addition to\nthe above scam would not increase the thief's chances very much.\n\nAnything that grants access to something, like something that takes a\nwhile to download, access to a website, web hosting, a subscription or\nservice, can be cancelled a few minutes later if the transaction is\nrejected."],["q","How is the required difficulty of each block communicated through the\nnetwork and agreed upon?"],["t","It's not communicated.  The formula is hardcoded in the program and\nevery node does the same calculation to know what difficulty is required\nfor the next block.  If someone diverged from the formula, their block\nwould not be accepted by the majority."],["q","Is the code free/open source or just open source?"],["t","It's free open source.  It's the MIT license, which just requires some\ndisclaimer text be kept with the source code, other than that you can do\njust about anything you want with it.  The source is included in the\nmain download.\n\nSatoshi"],["q","Is there a way to be told of new versions? Does the app auto update\nitself?  Some kind of mailing list would be excellent."],["t","The list is:\nbitcoin-list@lists.sourceforge.net\nSubscribe/unsubscribe page:\nhttp://lists.sourceforge.net/mailman/listinfo/bitcoin-list\nArchives:\nhttp://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list\n\nI'll always announce new versions there.  Automatic update, or at least\nnotification of new versions, is definitely on the list.\n\n[this inflation discussion was before the transaction fee mechanism and\nfixed plan of 21 million coins was posted, so it may not be as\napplicable anymore]"],["q","Since they can be created for free (or at the cost\nof computer power people have anyway for other reasons),\nmonetizing them means simply giving away money."],["t","You're still thinking as if the difficulty level will be so easy that\npeople will be able to generate all the bitcoins they want.\n\nImagine you have to run your computer 24/7 for a month to generate 1\ncent.  After a year, you could generate 12 cents.  That's not going to\nmake it so people can just generate all the bitcoin they want for spending.\n\nThe value of bitcoins would be relative to the electricity consumed to\nproduce them.  All modern CPUs save power when they're idle.  If you run\na computational task 24/7, not letting it idle, it uses significantly\nmore power, and you'll notice it generates more heat.  The extra wattage\nconsumed goes straight to your power bill, and the value of the bitcoins\nyou produce would be something less than that."],["q","Why would they, when they make money by generating\nnew ones"],["t","No, they can't make money that way.  It would cost them more in\nelectricity than they'd be selling the bitcoins for.\n\nHistorically, people have taken up scarce commodities as money, if\nnecessary taking up whatever is at hand, such as shells or stones.  Each\nhas a kernel of usefulness that helped bootstrap the process, but the\nmonetary value ends up being much more than the functional value alone.\n  Most of the value comes from the value that others place in it.  Gold,\nfor instance, is pretty, non-corrosive and easily malleable, but most of\nits value is clearly not from that.  Brass is shiny and similar in\ncolour.  The vast majority of gold sits unused in vaults, owned by\ngovernments that could care less about its prettiness.\n\nUntil now, no scarce commodity that can be traded over a communications\nchannel without a trusted third party has been available.  If there is a\ndesire to take up a form of money that can be traded over the Internet\nwithout a TTP, then now that is possible.\n\nSatoshi"],["q","As more capable\ncomputer hardware comes out, the natural supply per user\ndoubles at every cycle of Moore's law."],["t","Actually, that is handled.  There's a moving average that compensates\nfor the total effort being expended so that the total production is a\nconstant.  As computers get more powerful, the difficulty increases to\ncompensate."],["q","I do not recall any economic history of a commodity subject\nto natural inflation ever being used as money"],["t","There's gold for one.  The supply of gold increases by about 2%-3% per\nyear.  Any fiat currency typically averages more inflation than that."],["q","Won't there be massive inflation as computers get faster and are able "],["t","to solve the proof-of-work problem faster?\n\nThe difficulty is controlled by a moving average that compensates for\nthe total effort being expended to keep the total production constant.\nAs computers get more powerful, the difficulty increases to compensate."],["q","If someone double spends, then the transaction record\ncan be unblinded revealing the identity of the cheater?"],["t","Identities are not used, and there's no reliance on recourse.  It's all\nprevention."],["q","...You're saying\nthere's no effort to identify and exclude nodes that don't\ncooperate? I suspect this will lead to trouble and possible DOS\nattacks."],["t","There is no reliance on identifying anyone.  As you've said, it's\nfutile and can be trivially defeated with sock puppets.\n\nThe credential that establishes someone as real is the ability to\nsupply CPU power."],["q","But in the absence of identity, there's no downside to them\nif spends become invalid, if they've already received the\ngoods they double-spent for (access to website, download,\nwhatever). The merchants are left holding the bag with\n\"invalid\" coins, unless they wait that magical \"few blocks\"\n(and how can they know how many?) before treating the spender\nas having paid.\n\nThe consumers won't do this if they spend their coin and it takes\nan hour to clear before they can do what they spent their coin on.\nThe merchants won't do it if there's no way to charge back a\ncustomer when they find the that their coin is invalid because\nthe customer has doublespent."],["t","This is a version 2 problem that I believe can be solved fairly\nsatisfactorily for most applications.\n\nThe race is to spread your transaction on the network first.  Think 6\ndegrees of freedom -- it spreads exponentially.  It would only take\nsomething like 2 minutes for a transaction to spread widely enough\nthat a competitor starting late would have little chance of grabbing\nvery many nodes before the first one is overtaking the whole network.\nDuring those 2 minutes, the merchant's nodes can be watching for a\ndouble-spent transaction.  The double-spender would not be able to\nblast his alternate transaction out to the world without the merchant\ngetting it, so he has to wait before starting.\n\nIf the real transaction reaches 90% and the double-spent tx reaches\n10%, the double-spender only gets a 10% chance of not paying, and 90%\nchance his money gets spent.  For almost any type of goods, that's\nnot going to be worth it for the scammer.\n\nInformation based goods like access to website or downloads are\nnon-fencible.  Nobody is going to be able to make a living off\nstealing access to websites or downloads.  They can go to the file\nsharing networks to steal that.  Most instant-access products aren't\ngoing to have a huge incentive to steal.\n\nIf a merchant actually has a problem with theft, they can make the\ncustomer wait 2 minutes, or wait for something in e-mail, which many\nalready do.  If they really want to optimize, and it's a large\ndownload, they could cancel the download in the middle if the\ntransaction comes back double-spent.  If it's website access,\ntypically it wouldn't be a big deal to let the customer have access\nfor 5 minutes and then cut off access if it's rejected.  Many such\nsites have a free trial anyway.\n\nSatoshi\n\n[in response to a question about scale]\n\n100,000 block generating nodes is a good ballpark large-scale size\nto think about.  Propagating a transaction across the whole network\ntwice would consume a total of US$ 0.02 of bandwidth at today's\nprices.  In practice, many would be burning off excess allocated\nbandwidth or unlimited plans with one of the cheaper backbones.\nThere could be millions of SPV clients.  They only matter in how\nmany transactions they generate.  If they pay 1 or 2 cents\ntransaction fees, they pay for themselves.  I've coded it so you\ncan pay any optional amount of transaction fees you want.  When the\nincentive subsidy eventually tapers off, it may be necessary to put\na market-determined transaction fee on your transactions to make\nsure nodes process them promptly.\n\nTo think about what a really huge transaction load would look like,\nI look at the existing credit card network.  I found some more\nestimates about how many transactions are online purchases.  It's\nabout 15 million tx per day for the entire e-commerce load of the\nInternet worldwide.  At 1KB per transaction, that would be 15GB of\nbandwidth for each block generating node per day, or about two DVD\nmovies worth.  Seems do-able even with today's technology.\n\nImportant to remember, even if Bitcoin caught on at dot-com rates\nof growth, it would still take years to become any substantial\nfraction of all transactions.  I believe hardware has already\nrecently become strong enough to handle large scale, but if there's\nany doubt about that, bandwidth speeds, prices, disk space and\ncomputing power will be much greater by the time it's needed.\n\nSatoshi"],["q","One other question I had... What prevents the single node with the most\nCPU power from generating and retaining the majority of the BitCoins?\nIf every node is working independently of all others, if one is\nsignificantly more powerful than the others, isn't it probable that this\nnode will reach the proper conclusion before other nodes? An\nunderpowered node may get lucky once in a while, but if they are at a\nsignificant horsepower advantage I would expect the majority of BitCoins\nto be generated by the most powerful node."],["t","It's not like a race where if one car is twice as fast, it'll always\nwin.  It's an SHA-256 that takes less than a microsecond, and each guess\nhas an independent chance of success.  Each computer's chance of finding\na hash collision is linearly proportional to it's CPU power.  A computer\nthat's half as fast would get half as many coins.\n\n[question about what to backup]\n\nThe files are in \"%appdata%\\Bitcoin\", that's the directory to\nbackup.\n\n%appdata% is per-user access privilege.  Most new programs like\nFirefox store their settings files there, despite the headwind of\nMicrosoft changing the directory name with every Windows release\nand being full of spaces and so long it runs off the screen.\n\n[question about what to backup]\n\nThe directory is \"%appdata%\\Bitcoin\"\nIt has spaces in it so you need the quotes\ncd \"%appdata%\\bitcoin\"\n\nOn XP it would typically be:\nC:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\n\nBackup that whole directory.  All data files are in that\ndirectory.  There are no temporary files.\n\n[question about what to backup]\n\nThe crucial file to backup is wallet.dat.  If bitcoin is running\nthen you have to backup the whole %appdata%\\bitcoin directory\nincluding the database subdirectory, but even if it's not running\nit certainly feels safer to always backup the whole directory.\n\nThe database unfortunately names its files \"log.0000000001\".  To\nthe rest of the world, \"log\" means delete-at-will, but to database\npeople it means delete-and-lose-everything-in-your-other-files.  I\ntried to put them out of harm's way by putting them in the\ndatabase subdirectory.  Later I'll write code to flush the logs\nafter every wallet change so wallet.dat will be standalone safe\nalmost all the time."],["q","> You know, I think there were a lot more people interested in the 90's,\n> but after more than a decade of failed Trusted Third Party based "],["t","systems"],["q","> (Digicash, etc), they see it as a lost cause. I hope they can make the\n> distinction that this is the first time I know of that we're trying a\n> non-trust-based system.\n\nYea, that was the primary feature that caught my eye. The real trick\nwill be to get people to actually value the Bitcoins so that they become\ncurrency."],["t","Hal sort of alluded to the possibility that it could be seen as a\nlong-odds investment.  I would be surprised if 10 years from now\nwe're not using electronic currency in some way, now that we know\na way to do it that won't inevitably get dumbed down when the\ntrusted third party gets cold feet.\n\nOnce it gets bootstrapped, there are so many applications if you\ncould effortlessly pay a few cents to a website as easily as dropping\ncoins in a vending machine.\n\n[this next bit turned out to be very controversial.  there is extreme\nprejudice against spam solutions, especially proof-of-work.]\n\nIt can already be used for pay-to-send e-mail.  The send dialog is\nresizeable and you can enter as long of a message as you like.\nIt's sent directly when it connects.  The recipient doubleclicks\non the transaction to see the full message.  If someone famous is\ngetting more e-mail than they can read, but would still like to\nhave a way for fans to contact them, they could set up Bitcoin and\ngive out the IP address on their website.  \"Send X bitcoins to my\npriority hotline at this IP and I'll read the message personally.\"\n\nSubscription sites that need some extra proof-of-work for their\nfree trial so it doesn't cannibalize subscriptions could charge\nbitcoins for the trial.\n\n[again, I don't know why I'm including this, as it's best to stay\naway from claims about spam.  people automatically react violently\nagainst any suggestion of a spam solution.]"],["q","Spammer botnets could burn through pay-per-send email filters\ntrivially (as usual, the costs would fall on people other than the\nbotnet herders & spammers)."],["t","Then you could earn a nice profit by setting up pay-per-send\ne-mail addresses and collecting all the spam money.  You could\nsell it back to spammers who don't have big enough botnets to\ngenerate their own, helping bootstrap the currency's value.  As\nmore people catch on, they'll set up more and more phony addresses\nto harvest it.  By the time the book \"How I got rich exploiting\nspammers and you can too\" is coming out, there'll be too many fake\naddresses and the spammers will have to give up."],["q","> * Spammer botnets could burn through pay-per-send email filters\n>   trivially\nIf POW tokens do become useful, and especially if they become money,\nmachines will no longer sit idle. Users will expect their computers to\nbe earning them money (assuming the reward is greater than the cost to\noperate). A computer whose earnings are being stolen by a botnet will\nbe more noticeable to its owner than is the case today, hence we might\nexpect that in that world, users will work harder to maintain their\ncomputers and clean them of botnet infestations."],["t","One more factor that would mitigate spam if POW tokens have value:\nthere would be a profit motive for people to set up massive\nquantities of fake e-mail accounts to harvest POW tokens from\nspam.  They'd essentially be reverse-spamming the spammers with\nautomated mailboxes that collect their POW and don't read the\nmessage.  The ratio of fake mailboxes to real people could become\ntoo high for spam to be cost effective.\n\nThe process has the potential to establish the POW token's value\nin the first place, since spammers that don't have a botnet could\nbuy tokens from harvesters.  While the buying back would\ntemporarily let more spam through, it would only hasten the\nself-defeating cycle leading to too many harvesters exploiting the\nspammers.\n\nInterestingly, one of the e-gold systems already has a form of\nspam called \"dusting\".  Spammers send a tiny amount of gold dust\nin order to put a spam message in the transaction's comment field.\n  If the system let users configure the minimum payment they're\nwilling to receive, or at least the minimum that can have a\nmessage with it, users could set how much they're willing to get\npaid to receive spam."],["q","The last thing we need is to deploy a system designed to burn all\navailable cycles, consuming electricity and generating carbon dioxide,\nall over the Internet, in order to produce small amounts of bitbux to\nget emails or spams through.\n\nCan't we just convert actual money in a bank account into bitbux --\ncheaply and without a carbon tax?  Please?"],["t","Ironic if we end up having to choose between economic liberty and\nconservation.\n\nUnfortunately, proof of work is the only solution I've found to\nmake p2p e-cash work without a trusted third party.  Even if I\nwasn't using it secondarily as a way to allocate the initial\ndistribution of currency, PoW is fundamental to coordinating the\nnetwork and preventing double-spending.\n\nIf it did grow to consume significant energy, I think it would\nstill be less wasteful than the labour and resource intensive\nconventional banking activity it would replace.  The cost would be\nan order of magnitude less than the billions in banking fees that\npay for all those brick and mortar buildings, skyscrapers and junk\nmail credit card offers.\n\nSatoshi"],["q","BTW I don't remember if we talked about this, but the other day some\npeople were mentioning secure timestamping. You want to be able to\nprove that a certain document existed at a certain time in the past.\nSeems to me that bitcoin's stack of blocks would be perfect for this."],["t","Indeed, Bitcoin is a distributed secure timestamp server for\ntransactions.  A few lines of code could create a transaction with\nan extra hash in it of anything that needs to be timestamped.\nI should add a command to timestamp a file that way.\n\n From a thread on p2presearch which starts with my rant about trust\nbeing the root weakness of all conventional financial systems.\nhttp://listcultures.org/pipermail/p2presearch_listcultures.org/2009-February/thread.html\n\nI've developed a new open source P2P e-cash system called Bitcoin.  It's\ncompletely decentralized, with no central server or trusted parties,\nbecause everything is based on crypto proof instead of trust.  Give it a\ntry, or take a look at the screenshots and design paper:\n\nDownload Bitcoin v0.1 at http://www.bitcoin.org\n\nThe root problem with conventional currency is all the trust that's\nrequired to make it work.  The central bank must be trusted not to\ndebase the currency, but the history of fiat currencies is full of\nbreaches of that trust.  Banks must be trusted to hold our money and\ntransfer it electronically, but they lend it out in waves of credit\nbubbles with barely a fraction in reserve.  We have to trust them with\nour privacy, trust them not to let identity thieves drain our accounts.\nTheir massive overhead costs make micropayments impossible.\n\nA generation ago, multi-user time-sharing computer systems had a similar\nproblem.  Before strong encryption, users had to rely on password\nprotection to secure their files, placing trust in the system\nadministrator to keep their information private.  Privacy could always\nbe overridden by the admin based on his judgment call weighing the\nprinciple of privacy against other concerns, or at the behest of his\nsuperiors.  Then strong encryption became available to the masses, and\ntrust was no longer required.  Data could be secured in a way that was\nphysically impossible for others to access, no matter for what reason,\nno matter how good the excuse, no matter what.\n\nIt's time we had the same thing for money.  With e-currency based on\ncryptographic proof, without the need to trust a third party middleman,\nmoney can be secure and transactions effortless.\n\nOne of the fundamental building blocks for such a system is digital\nsignatures.  A digital coin contains the public key of its owner.  To\ntransfer it, the owner signs the coin together with the public key of\nthe next owner.  Anyone can check the signatures to verify the chain of\nownership.  It works well to secure ownership, but leaves one big\nproblem unsolved: double-spending.  Any owner could try to re-spend an\nalready spent coin by signing it again to another owner.  The usual\nsolution is for a trusted company with a central database to check for\ndouble-spending, but that just gets back to the trust model.  In its\ncentral position, the company can override the users, and the fees\nneeded to support the company make micropayments impractical.\n\nBitcoin's solution is to use a peer-to-peer network to check for\ndouble-spending.  In a nutshell, the network works like a distributed\ntimestamp server, stamping the first transaction to spend a coin.  It\ntakes advantage of the nature of information being easy to spread but\nhard to stifle.  For details on how it works, see the design paper at\nhttp://www.bitcoin.org/bitcoin.pdf\n\nThe result is a distributed system with no single point of failure.\nUsers hold the crypto keys to their own money and transact directly with\neach other, with the help of the P2P network to check for double-spending.\n\nSatoshi Nakamoto\nhttp://www.bitcoin.org\n\nMartien van Steenbergen Martien at AardRock.COM\nThu Feb 12 08:40:53 CET 2009\n\nVery interesting. Is this akin to David Chaum's anonymous digital\nmoney? His concept makes sure money is anonymous unless it is\ncompromised, i.e. the same money spent more than once. As soon as it's\ncompromised, the ‘counterfeiter’ is immediately publicly exposed.\n\nAlso, in bitcoin, is there a limited supply of money (that must be\nmanaged)? Or is money created exaclty at the moment of transaction?\n\nSucces en plezier,\n\nMartien."],["q","Very interesting. Is this akin to David Chaum's anonymous digital money?\nHis concept makes sure money is anonymous unless it is compromised, i.e.\nthe same money spent more than once. As soon as it's compromised, the\n‘counterfeiter’ is immediately publicly exposed.","Martien van Steenbergen wrote:"],["t","It's similar in that it uses digital signatures for coins, but different\nin the approach to privacy and preventing double-spending.  The\nrecipient of a Bitcoin payment is able to check whether it is the first\nspend or not, and second-spends are not accepted.  There isn't an\noff-line mode where double-spenders are caught and shamed after the\nfact, because that would require participants to have identities.\n\nTo protect privacy, key pairs are used only once, with a new one for\nevery transaction.  The owner of a coin is just whoever has its private key.\n\nOf course, the biggest difference is the lack of a central server.  That\nwas the Achilles heel of Chaumian systems; when the central company shut\ndown, so did the currency."],["q","Also, in bitcoin, is there a limited supply of money (that must be\nmanaged)? Or is money created exaclty at the moment of transaction?"],["t","There is a limited supply of money.  Circulation will be 21,000,000\ncoins.  Transactions only transfer ownership.\n\nThank you for your questions,\n\nSatoshi"],["q","Reminds me of:\n\n    * AardRock » Wizard Rabbit Treasurer\n      <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and\n    * AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>","Martien van Steenbergen wrote:"],["t","Indeed, it is much like Pekunio in the concept of spraying redundant\ncopies of every transaction to a number of peers on the network, but the\nimplementation is not a reputation network like Wizard Rabbit Treasurer.\n   In fact, Bitcoin does not use reputation at all.  It sees the network\nas just a big crowd and doesn't much care who it talks to or who tells\nit something, as long as at least one of them relays the information\nbeing broadcast around the network.  It doesn't care because there's no\nway to lie to it.  Either you tell it crypto proof of something, or it\nignores you."],["q","Are you familiar with Ripple?"],["t","As trust systems go, Ripple is unique in spreading trust around rather\nthan concentrating it.\n\n[I've been asked at least 4 other times \"have you heard of Ripple?\"]"],["q","how operational is your project? how soon do you think people will be\nable to use it in real life?","Michel Bauwens wrote:"],["t","It's fully operational and the network is growing.  If you try the\nsoftware, e-mail me your Bitcoin address and I'll send you a few coins.\n\nWe just need to spread the word and keep getting more people interested.\n\nHere's a link to the original introduction of the paper on the\nCryptography mailing list.  (Inflation issues were superseded by changes\nI made later to support transaction fees and the limited circulation\nplan.  This link is a moving target, this archive page is just a certain\nnumber of days back and the discussion will keep scrolling off to the\nnext page.)\nhttp://www.mail-archive.com/cryptography@metzdowd.com/mail3.html\n\nA little follow up when the software was released.\nhttp://www.mail-archive.com/cryptography@metzdowd.com/mail2.html\n\nMy description of how Bitcoin solves the Byzantine Generals' problem:\nhttp://www.bitcoin.org/byzantine.html"]],"u":"https://mmalmi.github.io/satoshi/#email-3","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1241396242,"b":[["t","Quoting Satoshi Nakamoto <satoshin@gmx.com>:"],["q","That would be great!  I added you (dmp1ce) as a dev to the sourceforge\nproject and gave you access to edit the web space and everything."],["t","Oh, that's not me but another guy who wanted to help. I've seen him on\nthe Freedomain Radio forum. My name is Martti Malmi and my Sourceforge\naccount is sirius-m. No problem!\n\nThanks for your answered questions, I'll add them to the faq. Here's\nwhat I've done so far:\n\n**** Bitcoin FAQ ****\n\nGeneral Questions\n\n1 What is bitcoin?\n\nBitcoin is a peer-to-peer network based anonymous digital\ncurrency. Peer-to-peer (P2P) means that there is no central\nauthority to issue new money or to keep track of the\ntransactions. Instead, those tasks are managed collectively by\nthe nodes of the network. Anonymity means that the real world\nidentity of the parties of a transaction can be kept hidden from\nthe public or even from the parties themselves.\n\n2 How does bitcoin work?\n\nBitcoin utilizes public/private key cryptography. When a coin is\ntransfered from user A to user B, A adds B's public key to the\ncoin and signs it with his own private key. Now B owns the coin\nand can transfer it further. To prevent A from transfering the\nalready used coin to another user C, a public list of all the\nprevious transactions is collectively maintained by the network\nof bitcoin nodes, and before each transaction the coin's\nunusedness will be checked.\n\nFor details, see chapter Advanced Questions.\n\n3 What is bitcoin's value backed by?\n\nBitcoin is valued for the things it can be exchanged to, just\nlike all the traditional paper currencies are.\n\nWhen the first user publicly announces that he will make a pizza\nfor anyone who gives him a hundred bitcoins, then he can use\nbitcoins as payment to some extent - as much as people want pizza\nand trust his announcement. A pizza-eating hairdresser who trusts\nhim as a friend might then announce that she starts accepting\nbitcoins as payment for fancy haircuts, and the value of the\nbitcoin would be higher - now you could buy pizzas and haircuts\nwith them. When bitcoins have become accepted widely enough, he\ncould retire from his pizza business and still be able to use his\nbitcoin-savings.\n\n4 How are new bitcoins created?\n\nNew coins are generated by a network node each time it finds the\nsolution to a certain calculational problem. In the first 4 years\nof the bitcoin network, amount X of coins will be created. The\namount is halved each 4 years, so it will be X/2 after 4 years,\nX/4 after 8 years and so on. Thus the total number of coins will\napproach 2X.\n\n5 Is bitcoin safe?\n\nYes, as long as you make backups of your coin keys, protect them\nwith strong passwords and keep keyloggers away from your\ncomputer. If you lose your key or if some unknown attacker\nmanages to unlock it, there's no way to get your coins back. If\nyou have a large amount of coins, it is recommended to distribute\nthem under several keys. You propably wouldn't either keep all\nyour dollars or euros as paper in a single wallet and leave it\nunguarded.\n\n6 Why should I use bitcoin?\n\n• Transfer money easily through the internet, without having to\n   trust third parties.\n\n• Third parties can't prevent or control your transactions.\n\n• Be safe from the unfair monetary policies of the monopolistic\n   central banks and the other risks of centralized power over a\n   money supply. The limited inflation of the bitcoin system's\n   money supply is distributed evenly (by CPU power) throughout\n   the network, not monopolized to a banking elite.\n\n• Bitcoin's value is likely to increase as the growth of the\n   bitcoin economy exceeds the inflation rate - consider bitcoin\n   an investment and start running a node today!\n\n7 Where can I get bitcoins?\n\nFind a bitcoin owner and sell her something - MMORPG equipement,\nIT support, lawn mowing, dollars or whatever you can trade with\nher. You can also generate new bitcoins for yourself by running a\nbitcoin network node."]],"u":"https://mmalmi.github.io/satoshi/#email-4","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1241452260,"b":[["t","Oh crap, I got your sourceforge usernames mixed up, sorry about that.  I\nclicked on the wrong e-mail when I was looking for your username.  You\nnow have access.\n\nYour FAQ looks good so far!\n\nYou can create whatever you want on bitcoin.sourceforge.net.  Something\nto get new users up to speed on what Bitcoin is and how to use it and\nwhy, and clean and professional looking would help make it look well\nestablished.  The site at bitcoin.org was designed in a more\nprofessorial style when I was presenting the design paper on the\nCryptography list, but we're moving on from that phase.\n\nYou should probably change the part about \"distribute them under several\nkeys\".  When the paper says that it means for the software to do it, and\nit does.  For privacy reasons, the software already uses a different key\nfor every transaction, so every piece of money in your wallet is already\non a different key.  The exception is when using a bitcoin address,\neverything sent to the same bitcoin address is on the same key, which is\na privacy risk if you're trying to be anonymous.  The EC-DSA key size is\nvery strong (sized for the future), we don't practically have to worry\nabout a key getting broken, but if we did there's the advantage that\nsomeone expending the massive computing resources would only break one\nsingle transaction's worth of money, not someone's whole account.  The\ndetails about how to backup your wallet files is in the Q&A dump and\nalso it's explained in readme.txt and definitely belongs in the FAQ.\n\nOh I see, you're trying to address byronm's concern on freedomainradio.\n  I see what you mean about the password feature being useful to address\nthat argument.  Banks let anyone who has your name and account number\ndrain your account, and you're not going to get it back from Nigeria.\nIf someone installs a keylogger on your computer, they could just as\neasily get your bank password and transfer money out of your account.\nOnce we password encrypt the wallet, we'll be able to make a clearer\ncase that we're much more secure than banks.  We use strong encryption,\nwhile banks still let anyone who has your account info draw money from\nyour account."],["q","Quoting Satoshi Nakamoto <satoshin@gmx.com>:\n\n> That would be great!  I added you (dmp1ce) as a dev to the sourceforge\n> project and gave you access to edit the web space and everything.\n\nOh, that's not me but another guy who wanted to help. I've seen him on\nthe Freedomain Radio forum. My name is Martti Malmi and my Sourceforge\naccount is sirius-m. No problem!\n\nThanks for your answered questions, I'll add them to the faq. Here's\nwhat I've done so far:\n\n**** Bitcoin FAQ ****\n\nGeneral Questions\n\n1 What is bitcoin?\n\nBitcoin is a peer-to-peer network based anonymous digital\ncurrency. Peer-to-peer (P2P) means that there is no central\nauthority to issue new money or to keep track of the\ntransactions. Instead, those tasks are managed collectively by\nthe nodes of the network. Anonymity means that the real world\nidentity of the parties of a transaction can be kept hidden from\nthe public or even from the parties themselves.\n\n2 How does bitcoin work?\n\nBitcoin utilizes public/private key cryptography. When a coin is\ntransfered from user A to user B, A adds B's public key to the\ncoin and signs it with his own private key. Now B owns the coin\nand can transfer it further. To prevent A from transfering the\nalready used coin to another user C, a public list of all the\nprevious transactions is collectively maintained by the network\nof bitcoin nodes, and before each transaction the coin's\nunusedness will be checked.\n\nFor details, see chapter Advanced Questions.\n\n3 What is bitcoin's value backed by?\n\nBitcoin is valued for the things it can be exchanged to, just\nlike all the traditional paper currencies are.\n\nWhen the first user publicly announces that he will make a pizza\nfor anyone who gives him a hundred bitcoins, then he can use\nbitcoins as payment to some extent - as much as people want pizza\nand trust his announcement. A pizza-eating hairdresser who trusts\nhim as a friend might then announce that she starts accepting\nbitcoins as payment for fancy haircuts, and the value of the\nbitcoin would be higher - now you could buy pizzas and haircuts\nwith them. When bitcoins have become accepted widely enough, he\ncould retire from his pizza business and still be able to use his\nbitcoin-savings.\n\n4 How are new bitcoins created?\n\nNew coins are generated by a network node each time it finds the\nsolution to a certain calculational problem. In the first 4 years\nof the bitcoin network, amount X of coins will be created. The\namount is halved each 4 years, so it will be X/2 after 4 years,\nX/4 after 8 years and so on. Thus the total number of coins will\napproach 2X.\n\n5 Is bitcoin safe?\n\nYes, as long as you make backups of your coin keys, protect them\nwith strong passwords and keep keyloggers away from your\ncomputer. If you lose your key or if some unknown attacker\nmanages to unlock it, there's no way to get your coins back. If\nyou have a large amount of coins, it is recommended to distribute\nthem under several keys. You propably wouldn't either keep all\nyour dollars or euros as paper in a single wallet and leave it\nunguarded.\n\n6 Why should I use bitcoin?\n\n• Transfer money easily through the internet, without having to\n  trust third parties.\n\n• Third parties can't prevent or control your transactions.\n\n• Be safe from the unfair monetary policies of the monopolistic\n  central banks and the other risks of centralized power over a\n  money supply. The limited inflation of the bitcoin system's\n  money supply is distributed evenly (by CPU power) throughout\n  the network, not monopolized to a banking elite.\n\n• Bitcoin's value is likely to increase as the growth of the\n  bitcoin economy exceeds the inflation rate - consider bitcoin\n  an investment and start running a node today!\n\n7 Where can I get bitcoins?\n\nFind a bitcoin owner and sell her something - MMORPG equipement,\nIT support, lawn mowing, dollars or whatever you can trade with\nher. You can also generate new bitcoins for yourself by running a\nbitcoin network node.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-5","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1241485200,"b":[["t","Quoting Satoshi Nakamoto <satoshin@gmx.com>:"],["q","You can create whatever you want on bitcoin.sourceforge.net.  Something\nto get new users up to speed on what Bitcoin is and how to use it and\nwhy, and clean and professional looking would help make it look well\nestablished.  The site at bitcoin.org was designed in a more\nprofessorial style when I was presenting the design paper on the\nCryptography list, but we're moving on from that phase."],["t","Ok. Could you set the project MySQL database passwords so that I can\nset up a CMS on the site? I was thinking about WordPress, as it seems\nsimple and well maintained. I need a password for the read/write\naccount and one database (or the database admin pass to create it\nmyself). This can be done somewhere in the project admin pages, I think."],["q","You should probably change the part about \"distribute them under\nseveral keys\".  When the paper says that it means for the software to\ndo it, and it does.  For privacy reasons, the software already uses a\ndifferent key for every transaction, so every piece of money in your\nwallet is already on a different key.  The exception is when using a\nbitcoin address, everything sent to the same bitcoin address is on the\nsame key, which is a privacy risk if you're trying to be anonymous.\nThe EC-DSA key size is very strong (sized for the future), we don't\npractically have to worry about a key getting broken, but if we did\nthere's the advantage that someone expending the massive computing\nresources would only break one single transaction's worth of money, not\nsomeone's whole account.  The details about how to backup your wallet\nfiles is in the Q&A dump and also it's explained in readme.txt and\ndefinitely belongs in the FAQ."],["t","Ok, that's good to know."],["q","Oh I see, you're trying to address byronm's concern on freedomainradio.\n I see what you mean about the password feature being useful to address\nthat argument.  Banks let anyone who has your name and account number\ndrain your account, and you're not going to get it back from Nigeria.\nIf someone installs a keylogger on your computer, they could just as\neasily get your bank password and transfer money out of your account.\nOnce we password encrypt the wallet, we'll be able to make a clearer\ncase that we're much more secure than banks.  We use strong encryption,\nwhile banks still let anyone who has your account info draw money from\nyour account."],["t","Well, I guess that's true after all."]],"u":"https://mmalmi.github.io/satoshi/#email-6","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1241485661,"b":[["t","Quoting mmalmi@cc.hut.fi:"],["q","> Oh I see, you're trying to address byronm's concern on freedomainradio.\n> I see what you mean about the password feature being useful to address\n> that argument.  Banks let anyone who has your name and account number\n> drain your account, and you're not going to get it back from Nigeria.\n> If someone installs a keylogger on your computer, they could just as\n> easily get your bank password and transfer money out of your account.\n> Once we password encrypt the wallet, we'll be able to make a clearer\n> case that we're much more secure than banks.  We use strong encryption,\n> while banks still let anyone who has your account info draw money from\n> your account.\n\nWell, I guess that's true after all."],["t","...the difference being, though, that not everyone can easily transfer\ntheir regular bank money into an uncontrollable location. In bitcoin\nanyone can do it."]],"u":"https://mmalmi.github.io/satoshi/#email-7","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1241545184,"b":[["q","> You can create whatever you want on bitcoin.sourceforge.net.  Something\n> to get new users up to speed on what Bitcoin is and how to use it and\n> why, and clean and professional looking would help make it look well\n> established.  The site at bitcoin.org was designed in a more\n> professorial style when I was presenting the design paper on the\n> Cryptography list, but we're moving on from that phase.\n\nOk. Could you set the project MySQL database passwords so that I can set\nup a CMS on the site? I was thinking about WordPress, as it seems simple\nand well maintained. I need a password for the read/write account and\none database (or the database admin pass to create it myself). This can\nbe done somewhere in the project admin pages, I think.","mmalmi@cc.hut.fi wrote:"],["t","They have Wordpress built in, you might not need to set up any database\nstuff manually.  I enabled the Wordpress feature and added you as an\nadmin, account sirius-m, e-mail sirius-m@users.sourceforge.net.  I'm not\nsure how it works out the password for access, maybe it's just based on\nbeing logged in to sourceforge.\n\nhttps://apps.sourceforge.net/wordpress/bitcoin/wp-admin/\n\nThey also have support for MediaWiki if you want it.\n\nIn case you still need it, here's the accounts and passwords for mysql.\n\n# Access this project's databases over the Internet\nhttps://apps.sourceforge.net/admin/Bitcoin\n# Documentation: Guide to MySQL Database Services\nhttp://p.sf.net/sourceforge/mysql\n# Hostname: mysql-b   (exactly as shown, with no domain suffix)\n# Database name prefix: b244765_ -- i.e. \"CREATE DATABASE b244765_myapp\"\nas your ADMIN user.\n# RO user: b244765ro (SELECT)\n# RW user: b244765rw (SELECT, INSERT, DELETE, UPDATE)\n# ADMIN user: b244765admin (has RW account privileges, and CREATE, DROP,\nALTER, INDEX, LOCK TABLES)\n# web-access URL: https://mysql-b.sourceforge.net/\npasswords:\nb244765ro       EaG3nHLL\nb244765rw       sNKgyt4W\nb244765admin    Mz589ZKf"],["q","...the difference being, though, that not everyone can easily\ntransfer their regular bank money into an uncontrollable location. In\nbitcoin anyone can do it."],["t","That's true.\n\nWe shouldn't try to use security against identity theft as a selling\npoint, since it leads into these counter arguments.  The current banking\nmodel is already tested and the actual loss percentage is known.  Even\nif ours is probably better, it's an unknown, so people can imagine\nanything.  The uncertainty about what the average loss percentage will\nbe is greater than the likely loss percentage itself."]],"u":"https://mmalmi.github.io/satoshi/#email-8","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1241587901,"b":[["t","Quoting Satoshi Nakamoto <satoshin@gmx.com>:"],["q","They have Wordpress built in, you might not need to set up any database\nstuff manually.\n\nThey also have support for MediaWiki if you want it."],["t","The built-in Wordpress comes with ads, and new plugins and themes need\nto be installed by the Sourceforge staff, so I installed Wordpress at\nhttp://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/,\nwith admin/Wubreches3eS as login. If there's something to add or\nchange, feel free to.\n\nThe current layout is just a quickly applied free theme, but I'll see\nif I can do something more visual myself.\n\nThe MediaWiki might be quite useful for maintaining the FAQ, which\ncould be retrieved from there to the main site somehow. The wiki says\nI need to be an editor or admin to create a new page, which is funny,\nbecause\nhttps://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights says that users can create\npages."]],"u":"https://mmalmi.github.io/satoshi/#email-9","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1241588503,"b":[["t","Lainaus mmalmi@cc.hut.fi:"],["q","The current layout is just a quickly applied free theme, but I'll see\nif I can do something more visual myself."],["t","And of course I'll continue improving the contents also."]],"u":"https://mmalmi.github.io/satoshi/#email-10","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1241663750,"b":[["t","It's already an improvement, and like you say, there must be better\nthemes to choose from.\n\nIt would be good to make the download link go directly to the download area:\nhttps://sourceforge.net/project/showfiles.php?group_id=244765\n\nI haven't found any way to gain admin control over the mediawiki\nfeature.  It thinks I'm a different S_nakamoto from the one that has\nadmin access:\n     User list\n     * S nakamoto  <- it thinks I'm this one\n     * S nakamoto ‎(admin, editor)\n     * Sirius-m\n\nI tried deleting and re-enabling the feature, no help.  Oh well."],["q","Quoting Satoshi Nakamoto <satoshin@gmx.com>:\n\n> They have Wordpress built in, you might not need to set up any database\n> stuff manually.\n>\n> They also have support for MediaWiki if you want it.\n\nThe built-in Wordpress comes with ads, and new plugins and themes need\nto be installed by the Sourceforge staff, so I installed Wordpress at\nhttp://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/,\nwith admin/Wubreches3eS as login. If there's something to add or change,\nfeel free to.\n\nThe current layout is just a quickly applied free theme, but I'll see if\nI can do something more visual myself.\n\nThe MediaWiki might be quite useful for maintaining the FAQ, which could\nbe retrieved from there to the main site somehow. The wiki says I need\nto be an editor or admin to create a new page, which is funny, because\nhttps://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights\nsays that users can create pages.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-11","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1242979556,"b":[["t","Quoting Satoshi Nakamoto <satoshin@gmx.com>:"],["q","I haven't found any way to gain admin control over the mediawiki\nfeature.  It thinks I'm a different S_nakamoto from the one that has\nadmin access:\n    User list\n    * S nakamoto  <- it thinks I'm this one\n    * S nakamoto ‎(admin, editor)\n    * Sirius-m\n\nI tried deleting and re-enabling the feature, no help.  Oh well."],["t","I think this has something to do with the underscore character in your\nusername; MediaWiki handles them as spaces. I could ask SF Support\nabout this."]],"u":"https://mmalmi.github.io/satoshi/#email-12","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1242979723,"b":[["t","Quoting mmalmi@cc.hut.fi:"],["q","Quoting Satoshi Nakamoto <satoshin@gmx.com>:\n\n> I haven't found any way to gain admin control over the mediawiki\n> feature.  It thinks I'm a different S_nakamoto from the one that has\n> admin access:\n>    User list\n>    * S nakamoto  <- it thinks I'm this one\n>    * S nakamoto ‎(admin, editor)\n>    * Sirius-m\n>\n> I tried deleting and re-enabling the feature, no help.  Oh well.\n\nI think this has something to do with the underscore character in your\nusername; MediaWiki handles them as spaces. I could ask SF Support\nabout this."],["t","Or could you control the MediaWiki with your account nakamoto2?"]],"u":"https://mmalmi.github.io/satoshi/#email-13","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1242979961,"b":[["t","Quoting mmalmi@cc.hut.fi:"],["q","Quoting mmalmi@cc.hut.fi:\n\n> Quoting Satoshi Nakamoto <satoshin@gmx.com>:\n>\n>> I haven't found any way to gain admin control over the mediawiki\n>> feature.  It thinks I'm a different S_nakamoto from the one that has\n>> admin access:\n>>   User list\n>>   * S nakamoto  <- it thinks I'm this one\n>>   * S nakamoto ‎(admin, editor)\n>>   * Sirius-m\n>>\n>> I tried deleting and re-enabling the feature, no help.  Oh well.\n>\n> I think this has something to do with the underscore character in your\n> username; MediaWiki handles them as spaces. I could ask SF Support\n> about this.\n\nOr could you control the MediaWiki with your account nakamoto2?"],["t","Oh, sorry for spamming with emails, but the problem is indeed with the\nunderscore character:\nhttp://apps.sourceforge.net/trac/sourceforge/ticket/300"]],"u":"https://mmalmi.github.io/satoshi/#email-14","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1243202618,"b":[["t","You're right, that was it.  I went in and granted us access using the\nalternate account.\n\nI like your idea of at least moving the FAQ into the wiki.  I've seen\nother projects that use the wiki for the FAQ or even the whole site.  If\nyou can figure out how to make it so regular users can edit things, then\nanyone who wants to can help."],["q","Quoting mmalmi@cc.hut.fi:\n\n> Quoting mmalmi@cc.hut.fi:\n>\n>> Quoting Satoshi Nakamoto <satoshin@gmx.com>:\n>>\n>>> I haven't found any way to gain admin control over the mediawiki\n>>> feature.  It thinks I'm a different S_nakamoto from the one that has\n>>> admin access:\n>>>   User list\n>>>   * S nakamoto  <- it thinks I'm this one\n>>>   * S nakamoto ‎(admin, editor)\n>>>   * Sirius-m\n>>>\n>>> I tried deleting and re-enabling the feature, no help.  Oh well.\n>>\n>> I think this has something to do with the underscore character in your\n>> username; MediaWiki handles them as spaces. I could ask SF Support\n>> about this.\n>\n> Or could you control the MediaWiki with your account nakamoto2?\n\nOh, sorry for spamming with emails, but the problem is indeed with the\nunderscore character:\nhttp://apps.sourceforge.net/trac/sourceforge/ticket/300","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-15","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1244352869,"b":[["q","I like your idea of at least moving the FAQ into the wiki.  I've seen\nother projects that use the wiki for the FAQ or even the whole site.\nIf you can figure out how to make it so regular users can edit things,\nthen anyone who wants to can help."],["t","The user group privileges seemingly can't be changed without changing\nthe wiki source files, which can only be done by the SF admins as a\nhosted app is concerned. The hosted apps are also otherwise quite\ninflexible: you can only login with a SF account, you can't change\nthemes by yourself and of course there's the ad-bar above the pages.\n\nI think that replacing the current Wordpress installation at\nbitcoin.sourceforge.net with TikiWiki could be a great solution.\nTikiWiki supports CMS features, forums, wikis, bug trackers, and many\nother features also if needed. Perhaps the best looking example of a\nTikiWiki installation is at http://support.mozilla.com/.\n\nI'll take backup of the current site and see if TikiWiki can be\ninstalled at SF. If it doesn't work, I'll see how wiki/forum features\ncan be integrated with Wordpress or think of something else."]],"u":"https://mmalmi.github.io/satoshi/#email-16","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1244530526,"b":[["t","I couldn't get TikiWiki to work, so I installed Bitweaver, which is a\nlightweight TikiWiki derivative. Its functionality looks good for the\npurpose and it's easy to customize.\n\nThe admin account password is Wubreches3eS again. New users can\nregister to the site and write to the wiki and the forums. Next I'm\ngoing to look into how custom menus and custom layouts are made."]],"u":"https://mmalmi.github.io/satoshi/#email-17","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1244694860,"b":[["t","Now that the project web is up and running, do you think that setting\nup a custom VHOST for the bitcoin.org domain would be a good idea?\nInstructions:\nhttp://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs\n\nAlso, could you please send me a link to a SF Logo for statistics, as\ninstructed at:\nhttp://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking"]],"u":"https://mmalmi.github.io/satoshi/#email-18","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1244755465,"b":[["t","The site layout is looking nicer.  More impressive looking.\n\nThere are a lot of things you can say on the sourceforge site that I\ncan't say on my own site.  Even so, I'm uncomfortable with explicitly\nsaying \"consider it an investment\".  That's a dangerous thing to say and\nyou should delete that bullet point.  It's OK if they come to that\nconclusion on their own, but we can't pitch it as that.\n\nA few details: the FAQ says \"see section 2.3\", but the sections aren't\nnumbered.  Also, could you delete the last sentence on the FAQ \"They are\nplanned to be hidden in v0.1.6, since they're just confusing and\nannoying and there's no reason for users to have to see them.\" -- that's\nnot really something I meant to say publicly.\n\nThe links to sites to help set up 8333 port forwarding is great.\nfavicon is a nice touch.\n\nSomeone came up with the word \"cryptocurrency\"... maybe it's a word we\nshould use when describing Bitcoin, do you like it?\n\nSourceforge is so slow right now I can't even get the login page to\nload.  Maybe due to the site reorg they just did.  I'll keep trying and\ntry to get you that logo stats thing."],["q","Now that the project web is up and running, do you think that setting up\na custom VHOST for the bitcoin.org domain would be a good idea?\nInstructions:\nhttp://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs\n\nAlso, could you please send me a link to a SF Logo for statistics, as\ninstructed at:\nhttp://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-19","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1244798554,"b":[["q","There are a lot of things you can say on the sourceforge site that I\ncan't say on my own site.  Even so, I'm uncomfortable with explicitly\nsaying \"consider it an investment\".  That's a dangerous thing to say\nand you should delete that bullet point.  It's OK if they come to that\nconclusion on their own, but we can't pitch it as that.\n\nA few details: the FAQ says \"see section 2.3\", but the sections aren't\nnumbered.  Also, could you delete the last sentence on the FAQ \"They\nare planned to be hidden in v0.1.6, since they're just confusing and\nannoying and there's no reason for users to have to see them.\" --\nthat's not really something I meant to say publicly."],["t","I made the changes. You could also register to the site or use the\nadmin account to make necessary changes yourself, since the pages are\nlocated in the wiki."],["q","Someone came up with the word \"cryptocurrency\"... maybe it's a word we\nshould use when describing Bitcoin, do you like it?"],["t","It sounds good. \"The P2P Cryptocurrency\" could be considered as the\nslogan, even if it's a bit more difficult to say than \"The Digital P2P\nCash\". It still describes the system better and sounds more\ninteresting, I think.\n\nI could notify the mailing list about the new site and invite them to\nwrite on the forums and to the wiki."]],"u":"https://mmalmi.github.io/satoshi/#email-20","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1245011458,"b":[["q","I made the changes. You could also register to the site or use the admin\naccount to make necessary changes yourself, since the pages are located\nin the wiki.","mmalmi@cc.hut.fi wrote:"],["t","Thanks, I've been really busy lately.\n\nI registered username \"satoshi\".  Since there's no SSL login, I want to\nmainly use that account with sub-admin powers and use the admin account\nas little as possible.  I created a \"Moderators\" group to give my\nsatoshi account as much editing control as possible without the ability\nto overthrow everything.\n\nThere's something weird with the download bar on the right covering\nthings up, like on the new account registration it covers up the entry\nfields unless you make the browser really wide, and the homepage it\ncovers up the screenshots.  (with Firefox)"]],"u":"https://mmalmi.github.io/satoshi/#email-21","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1245688031,"b":[["q","There's something weird with the download bar on the right covering\nthings up, like on the new account registration it covers up the entry\nfields unless you make the browser really wide, and the homepage it\ncovers up the screenshots.  (with Firefox)"],["t","Problem fixed. I switched to a fixed width layout, which is also\neasier to read as the lines are shorter."]],"u":"https://mmalmi.github.io/satoshi/#email-22","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1248137014,"b":[["t","Hi,\n\nI made a post on the Bitcoin developer's forum at SF about a month ago\nand sent you, David and Hal a notification about it to your\nusers.sourceforge.net emails. A few days ago I wondered why no one had\nreplied, and tried if the SF mail aliases even work - and they didn't,\nat least in the case of my account. So could you please forward this\nmessage to the others?\n\nBest regards,\nsirius-m"]],"u":"https://mmalmi.github.io/satoshi/#email-23","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1248146083,"b":[["t","I know this sounds really retarded, but I still haven't been able to get\nthe sourceforge login page to load, so I haven't been able to read it\neither.  https://sourceforge.net/account/login.php\n\nHal isn't currently actively involved.  He helped me a lot defending the\ndesign on the Cryptography list, and with initial testing when it was\nfirst released.  He carried this torch years ago with his Reusable Proof\nOf Work (RPOW).\n\nI'm not going to be much help right now either, pretty busy with work,\nand need a break from it after 18 months development.\n\nIt would help if there was something for people to use it for.  We need\nan application to bootstrap it.  Any ideas?\n\nThere are donors I can tap if we come up with something that needs\nfunding, but they want to be anonymous, which makes it hard to actually\ndo anything with it."],["q","Hi,\n\nI made a post on the Bitcoin developer's forum at SF about a month ago\nand sent you, David and Hal a notification about it to your\nusers.sourceforge.net emails. A few days ago I wondered why no one had\nreplied, and tried if the SF mail aliases even work - and they didn't,\nat least in the case of my account. So could you please forward this\nmessage to the others?\n\nBest regards,\nsirius-m","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-24","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1248257402,"b":[["q","I know this sounds really retarded, but I still haven't been able to\nget the sourceforge login page to load, so I haven't been able to read\nit either.  https://sourceforge.net/account/login.php"],["t","That's strange, I haven't had any problems with that. Clearly the\nbanking establishment got scared and banned your account (and founded\nwww.bitcoin.com in attempt to fetch the trademark), eh. You could ask\nif the SF staff at sfnet_ops@corp.sourceforge.com can help you."],["q","I'm not going to be much help right now either, pretty busy with work,\nand need a break from it after 18 months development."],["t","Oh, that sounds tough. Take your time."],["q","It would help if there was something for people to use it for.  We need\nan application to bootstrap it.  Any ideas?"],["t","I've been thinking about a currency exchange service that sells and\nbuys bitcoins for euros and other currencies. Direct exchangeability\nto an existing currency would give bitcoin the best possible initial\nliquidity and thus the best adoptability for new users. Everyone\naccepts payment in coins that are easily exchangeable for common\nmoney, but not everyone accepts payment in coins that are only\nguaranteed to buy a specific kind of a product.\n\nThe instructional formula for stable pricing in euros would be something like:\n\n(The amount of euros that you're ready to trade for bc + the\neuro-value of goods that other people are selling for bc) /\n(Total number of bc in circulation - own bc assets).\n\nSo if there's a total of 1M bitcoins of which you own 100K, you have\n1000 eur and no one else trades with bitcoin yet, you can safely offer the\nexchange rate of 1 eur / 900 bc, without having to devaluate\neven if everyone sold their coins to you. This could be guaranteed as\nthe minimal exchange rate, but the rate could be also higher when\ndemand is high.\n\nInitially, when others aren't yet offering anything for bitcoins, you\ncan increase your bitcoin assets cheaply - for the minimum price that\npeople bother to do the transaction for. If you had all the existing\ncoins for yourself, you could set the price to whatever you want,\nbecause you wouldn't face the risk of having to buy even a single coin\nwith that price (not counting the new money created by others). So\nit's best to get as much coins as possible before backing bitcoin with\nall your available euros.\n\nProfit can be gained, as usually in trading, by having a margin\nbetween the buying and selling prices. Making Bitcoin as usable as\npossible will make the business run better, as people do not only want\nto sell all their coins to you, but also want to buy them and use them\nas a medium of exchange.\n\nAt its simplest this exchange service could be a website where\ntraders, who can be individual persons, can post their rates, and\nrandom users can leave trade requests. Some kind of an average rate\nestimate could be shown on the site. Small-scale trading by\nindividuals would be outside legal hassle in most countries, and\nputting all the eggs in the same basket would be avoided.\n\nAnother idea, which could be additional to the previous one, would be\nan automated exchange service. The service would automatically\ncalculate the exchange rate and perform the transactions. This would\nbe nicer to the user: completion of the transaction request would be\ncertain and instantaneous. Making this service might actually be quite\neasy if there was a command line interface to Bitcoin: just take any\nweb application framework and use PayPal back-end integration to\nautomatically send euros when Bitcoins are received, and vice versa.\nThis kind of business would also work great on larger scale if you set\nup a company and take care of all the bureaucracy needed to practice\ncurrency exchange. (I actually have a registered company that I've\nused for billing of some IT work, I could use that as a base.)\n\nThis exchange business thing is something that I'd be interested in\ndoing, and I also have the sufficient technical skills to do it.\nAlthough, before this can be done, there should be a non-alpha version\nof Bitcoin (and the command line interface / API)."],["q","There are donors I can tap if we come up with something that needs\nfunding, but they want to be anonymous, which makes it hard to actually\ndo anything with it."],["t","If this gets started, donors / high-risk investors would be very\nwelcome to bring capital for the currency's backup.\n\nSo, what do you think about the idea? Note that this is not something\nthat I'm asking you to do (unless you want to) if you're busy with\nother things. I can do it myself, if I get positive reviews about the\nplan."]],"u":"https://mmalmi.github.io/satoshi/#email-25","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1248880491,"b":[["t","I've had quite a few errors coming up when trying to build the\nthird-party libraries and adding them to the Bitcoin build. Do you\nhappen to have a ready-to-build package that you could upload to the\nCVS or somewhere else? I use mingw + msys, but I guess I could try\nVisual C++ also, if it's easier that way."]],"u":"https://mmalmi.github.io/satoshi/#email-26","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1251085093,"b":[["t","I got it compile with MinGW + MSYS when I used wxPack instead of just\nwxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize\nwas 52MB though, I should see how that can be fixed.\n\nNext I'm going to implement the \"minimize to tray\" feature and the\noption to autostart Bitcoin with Windows, so the number of nodes\nonline would stay higher. After that I could see if I can do a Linux\nport or the command line interface needed for web app frameworks.\n\nDrop by at #bitcoin-dev on FreeNode some time if you use IRC.\n\nAnd again, thanks for the great work you've done with Bitcoin.\n\nQuote mmalmi@cc.hut.fi:"],["q","I've had quite a few errors coming up when trying to build the\nthird-party libraries and adding them to the Bitcoin build. Do you\nhappen to have a ready-to-build package that you could upload to the\nCVS or somewhere else? I use mingw + msys, but I guess I could try\nVisual C++ also, if it's easier that way."]],"u":"https://mmalmi.github.io/satoshi/#email-27","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1251151235,"b":[["t","That's a good point that since you know how many coins exist and how\nfast new ones are created, you could set a support price based on the\namount of legacy currency you have and be sure you'll have enough to\nmeet all demands.  I had imagined an auction, but it would be far\nsimpler and more confidence inspiring to back it at a specific exchange\nrate.\n\nOffering currency to back bitcoins would attract freebie seekers, with\nthe benefit of attracting a lot of publicity.  At first it would mostly\nbe seen as a way to get free money for your computer's idle time.  Maybe\npitched like help support the future of e-commerce and get a little\nmoney for your computer's spare cycles.  As people cash in and actually\nget paid, word would spread exponentially.\n\nIt might help to keep the minimum transaction size above an amount which\na typical user would be able to accumulate with one computer, so that\nusers have to trade with each other for someone to collect enough to\ncash in.  Aggregators would set up shop to buy bitcoins in smaller\nincrements, which would add confidence in users ability to sell bitcoins\nif there are more available buyers than just you.\n\nPeople would obviously be sceptical at first that the backing will hold\nup against an onslaught of people trying to get the free money, but as\nthe competition raises the proof-of-work difficulty, it should become\nclear that bitcoins stay scarce.  People will see that they can't just\nget all the bitcoins they want.  It would establish a minimum value\nunder bitcoins enabling them to be used for other purposes if,\nhopefully, other purposes are waiting for something to use."],["q","> It would help if there was something for people to use it for.  We need\n> an application to bootstrap it.  Any ideas?\n\nI've been thinking about a currency exchange service that sells and\nbuys bitcoins for euros and other currencies. Direct exchangeability\nto an existing currency would give bitcoin the best possible initial\nliquidity and thus the best adoptability for new users. Everyone\naccepts payment in coins that are easily exchangeable for common\nmoney, but not everyone accepts payment in coins that are only\nguaranteed to buy a specific kind of a product."],["t","That would be more powerful if there was also some narrow product market\nto use it for.  Some virtual currencies like Tencent's Q coin have made\nheadway with virtual goods.  It would be sweet if there was some way to\nhorn in on a market like that as the official virtual currency gets\nclamped down on with limitations.  Not saying it can't work without\nsomething, but a ready specific transaction need that it fills would\nincrease the certainty of success."],["q","At its simplest this exchange service could be a website where\ntraders, who can be individual persons, can post their rates, and\nrandom users can leave trade requests. Some kind of an average rate\nestimate could be shown on the site. Small-scale trading by\nindividuals would be outside legal hassle in most countries, and\nputting all the eggs in the same basket would be avoided."],["t","Basically like an eBay site with user reviews to try to establish which\nsellers can be trusted.  The escrow feature will help but not solve\neverything.  It would be far more work to set up such a site than just\nto set up a single exchange site of your own, and there won't be enough\nusers to make it go until later.  I'm thinking it wouldn't make sense to\nmake an eBay type site until later."],["q","Another idea, which could be additional to the previous one, would be\nan automated exchange service. The service would automatically\ncalculate the exchange rate and perform the transactions. This would\nbe nicer to the user: completion of the transaction request would be\ncertain and instantaneous. Making this service might actually be quite\neasy if there was a command line interface to Bitcoin: just take any\nweb application framework and use PayPal back-end integration to\nautomatically send euros when Bitcoins are received, and vice versa.\nThis kind of business would also work great on larger scale if you set\nup a company and take care of all the bureaucracy needed to practice\ncurrency exchange. (I actually have a registered company that I've\nused for billing of some IT work, I could use that as a base.)"],["t","Even if you had automation, you'd probably want to review orders\nmanually before processing them anyway.  It wouldn't be hard to process\norders by hand, especially at first.  You could always set a minimum\norder size to keep orders more infrequent."],["q","This exchange business thing is something that I'd be interested in\ndoing, and I also have the sufficient technical skills to do it.\nAlthough, before this can be done, there should be a non-alpha version\nof Bitcoin (and the command line interface / API).\n\nIf this gets started, donors / high-risk investors would be very\nwelcome to bring capital for the currency's backup.\n\nSo, what do you think about the idea? Note that this is not something\nthat I'm asking you to do (unless you want to) if you're busy with\nother things. I can do it myself, if I get positive reviews about the\nplan."],["t","That's great, I could probably get a donor to send currency to you which\nyou convert to euros and pay out through methods that are convenient for\nusers.  I don't want to do an exchange business myself, but it can be\ndone independently of me.  Like you say, there is more software\ndevelopment to be done first, and also I'd like to keep trying for a\nwhile to think of a bootstrap application to use bitcoins for.  I've had\nsome ideas that could only be done before an exchange exists.\n\nBTW, I tried to buy bitcoin.com before I started but there was no\nchance, it's owned by a professional domain speculator.  It's normal for\nopen source projects to have .org so it's not so bad."]],"u":"https://mmalmi.github.io/satoshi/#email-28","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1251151465,"b":[["t","Glad that worked, it's a pain that the dependencies are so big and hard\nto build.  Some of them give little attention to the Windows build.\nNext time I update to the latest versions, maybe I'll lay everything out\nin one directory tree and bundle the whole thing up into a giant archive.\n\nI'm not sure they had wxPack before.  I'm glad they got that so everyone\ndoesn't have to build wxWidgets themselves.  OpenSSL is the harder one\nto build.\n\nI reduced the EXE size by running strip.exe on it to take out the debug\nsymbols.  That's with mingw.  That's the better compiler, I only used VC\n  for debugging."],["q","I got it compile with MinGW + MSYS when I used wxPack instead of just\nwxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize was\n52MB though, I should see how that can be fixed.\n\nNext I'm going to implement the \"minimize to tray\" feature and the\noption to autostart Bitcoin with Windows, so the number of nodes online\nwould stay higher. After that I could see if I can do a Linux port or\nthe command line interface needed for web app frameworks.\n\nDrop by at #bitcoin-dev on FreeNode some time if you use IRC.\n\nAnd again, thanks for the great work you've done with Bitcoin.\n\nQuote mmalmi@cc.hut.fi:\n\n> I've had quite a few errors coming up when trying to build the\n> third-party libraries and adding them to the Bitcoin build. Do you\n> happen to have a ready-to-build package that you could upload to the\n> CVS or somewhere else? I use mingw + msys, but I guess I could try\n> Visual C++ also, if it's easier that way.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-29","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1251432606,"b":[["q","It might help to keep the minimum transaction size above an amount\nwhich a typical user would be able to accumulate with one computer, so\nthat users have to trade with each other for someone to collect enough\nto cash in.  Aggregators would set up shop to buy bitcoins in smaller\nincrements, which would add confidence in users ability to sell\nbitcoins if there are more available buyers than just you."],["t","That might be a good idea."],["q","That would be more powerful if there was also some narrow product\nmarket to use it for.  Some virtual currencies like Tencent's Q coin\nhave made headway with virtual goods.  It would be sweet if there was\nsome way to horn in on a market like that as the official virtual\ncurrency gets clamped down on with limitations.  Not saying it can't\nwork without something, but a ready specific transaction need that it\nfills would increase the certainty of success."],["t","Bitcoin could be promoted to the users of virtual communities like\nWorld of Warcraft and Second Life, which both have millions of users.\nIt would be great if not only peer-to-peer item traders, but also\nproviders of some existing virtual services that already have a lot of\ncustomers, were to adopt the currency early on.\n\nA programming question: What do you think about using the Boost's\nprogram_options to write settings like the transaction fee into a file\nbitcoin.config? Or is it better to save them in the database as it is\nnow? Having a config file would make it easier to change the settings\nwhen running the program on a remote server with a console access only."]],"u":"https://mmalmi.github.io/satoshi/#email-30","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1251567065,"b":[["q","Next I'm going to implement the \"minimize to tray\" feature and the\noption to autostart Bitcoin with Windows, so the number of nodes online\nwould stay higher. "],["t","Now that I think about it, you've put your finger on the most important\nmissing feature right now that would make an order of magnitude\ndifference in the number of nodes.  Without auto-run, we'll almost never\nretain nodes after an initial tryout interest.  Auto-running as a\nminimized tray icon by default was the key to success for the early file\nsharing networks.  It wouldn't have been appropriate for v0.1.0 when\nstability wasn't a given yet, but now it's good and stable.  This is a\nmust-have feature for the next release so any users that come back to\ntry the new version we hopefully retain this time.\n\nI think the most user friendly way of doing auto-run is putting an icon\nin the Startup folder.  I see OpenOffice.org and a number of other\nthings on my computer do it that way.  The other way, creating a runas\nregistry entry, is not easily visible or editable by users, I've never\nliked that much.  I guess what we want is an auto-run option that's on\nby default, if the option is changed then it creates or deletes the\nstartup icon.\n\nWhile it's tempting to do a Linux port, once we do it we have that extra\nwork with every release from then on.  I'd rather put it off a while\nlonger.  Auto-run might give us 300% more nodes while Linux might give\nus 3% more.  Linux would help server farms, but actually we'd like to\nfavour individual users.  Someone reported that it works fine in WinE."]],"u":"https://mmalmi.github.io/satoshi/#email-31","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1253105682,"b":[["t","Just for information: I committed my working copy to the svn/branches.\nThere's the minimize to tray feature and some other changes. It's\nnicer to run in the background now, but it's still incomplete and I'm\nworking on it. The bugs are listed in bugs.txt.\n\nDid you get your Sourceforge account work yet?"]],"u":"https://mmalmi.github.io/satoshi/#email-32","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1254334349,"b":[["t","That's great, that's a good step forward.\n\nYes, I worked out the sourceforge login problem, it was some tricky\nthing on the login page that exposed a quirky bug in a browser add-in."],["q","Just for information: I committed my working copy to the svn/branches.\nThere's the minimize to tray feature and some other changes. It's nicer\nto run in the background now, but it's still incomplete and I'm working\non it. The bugs are listed in bugs.txt.\n\nDid you get your Sourceforge account work yet?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-33","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1255023889,"b":[["t","I made a Windows installer for the latest version of Bitcoin, which\nincludes the autostart and minimize to tray features. The installer\nmakes a start menu shortcut and a startup registry entry. I first\nimplemented the autostart with a shortcut to the startup folder, but I\nfound out that it doesn't always work by default and ended up doing it\nwith a registry entry. The registry entry is removed by the\nuninstaller and can be also disabled from the options menu, so I don't\nthink it's such a big menace to the user after all.\n\nI made the installer with NSIS, and the nsi script can be found in the SVN.\n\nCould you add the installer to the SF download page? Here's the file:\nhttp://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe\n\nThere are some new users registered to the bitcoin.sf.net site. One of\nthem just announced that he's trading Bitcoins for dollars. Here's his\nsite: http://newlibertystandard.wetpaint.com/. Making an exchange\nservice first seemed a bit premature for the time being, but on the\nother hand it's good that people show interest towards the project,\nand this might attract even more interested people (and hopefully more\ndevelopers). I just sent the guy an email."]],"u":"https://mmalmi.github.io/satoshi/#email-34","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x19"},{"k":"x","s":"martti-malmi","t":"Re: Setup, Autorun, v0.1.6","u":"https://mmalmi.github.io/satoshi/#email-35","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1255718500,"b":[["t","Thanks for that.  I'm still merging in some changes I had that need to\ngo in before any next release.  Some things based on questions and\nfeedback I've received that'll reduce confusion.  I'll probably enable\nmulti-proc generating support, and hopefully make it safe to just backup\nwallet.dat to backup your money.  It's good to be coding again!\n\nI'm going to hide the transaction fee setting, which is completely not\nneeded and only serves to confuse people.  It was only there for testing\nand demonstration of a technical detail that can only be needed in the\nfar away future, if ever, but was necessary to implement at the\nbeginning to make it possible later.\n\nWhat was the problem with the shortcut in the startup folder?  If you\ncould send me the code, I'd like to take another look and see if I can\nsee what the problem was.  The first strcat in the registry code should\nbe strcpy, otherwise it would fail intermittently.  If the same code was\nin the shortcut one, maybe that was the problem.\n\nIt's encouraging to see more people taking an interest such as that\nNewLibertyStandard site.  I like his approach to estimating the value\nbased on electricity.  It's educational to see what explanations people\nadopt.  They may help discover a simplified way of understanding it that\nmakes it more accessible to the masses.  Many complex concepts in the\nworld have a simplistic explanation that satisfies 80% of people, and a\ncomplete explanation that satisfies the other 20% who see the flaws in\nthe simplistic explanation."],["q","I made a Windows installer for the latest version of Bitcoin, which\nincludes the autostart and minimize to tray features. The installer\nmakes a start menu shortcut and a startup registry entry. I first\nimplemented the autostart with a shortcut to the startup folder, but I\nfound out that it doesn't always work by default and ended up doing it\nwith a registry entry. The registry entry is removed by the uninstaller\nand can be also disabled from the options menu, so I don't think it's\nsuch a big menace to the user after all.\n\nI made the installer with NSIS, and the nsi script can be found in the SVN.\n\nCould you add the installer to the SF download page? Here's the file:\nhttp://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe\n\nThere are some new users registered to the bitcoin.sf.net site. One of\nthem just announced that he's trading Bitcoins for dollars. Here's his\nsite: http://newlibertystandard.wetpaint.com/. Making an exchange\nservice first seemed a bit premature for the time being, but on the\nother hand it's good that people show interest towards the project, and\nthis might attract even more interested people (and hopefully more\ndevelopers). I just sent the guy an email.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-35","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1255888782,"b":[["t","I got it, I see you checked in the startup folder code before changing\nit to registry.  I don't see any visible problems in the code.  I guess\nit depends what exactly the problem was with it not always working by\ndefault.  Was there a Vista/UAC security problem?"],["q","What was the problem with the shortcut in the startup folder?  If you\ncould send me the code, I'd like to take another look and see if I can\nsee what the problem was.  The first strcat in the registry code should\nbe strcpy, otherwise it would fail intermittently.  If the same code was\nin the shortcut one, maybe that was the problem.\n\nmmalmi@cc.hut.fi wrote:\n> I made a Windows installer for the latest version of Bitcoin, which\n> includes the autostart and minimize to tray features. The installer\n> makes a start menu shortcut and a startup registry entry. I first\n> implemented the autostart with a shortcut to the startup folder, but I\n> found out that it doesn't always work by default and ended up doing it\n> with a registry entry. The registry entry is removed by the\n> uninstaller and can be also disabled from the options menu, so I don't\n> think it's such a big menace to the user after all.","Satoshi Nakamoto wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-36","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1255899748,"b":[["t","Well, the code worked and made a shortcut in the startup folder. For\nsome reason it didn't automatically start when booting, but worked\nfine when you clicked on it in the menu. Now I tried making a shortcut\nmanually, and this time it works on autostart, don't know why. I could\ntry again with the older code."],["q","I got it, I see you checked in the startup folder code before changing\nit to registry.  I don't see any visible problems in the code.  I guess\nit depends what exactly the problem was with it not always working by\ndefault.  Was there a Vista/UAC security problem?\n\nSatoshi Nakamoto wrote:\n> What was the problem with the shortcut in the startup folder?  If\n> you could send me the code, I'd like to take another look and see\n> if I can see what the problem was.  The first strcat in the\n> registry code should be strcpy, otherwise it would fail\n> intermittently.  If the same code was in the shortcut one, maybe\n> that was the problem.\n>\n> mmalmi@cc.hut.fi wrote:\n>> I made a Windows installer for the latest version of Bitcoin,\n>> which includes the autostart and minimize to tray features. The\n>> installer makes a start menu shortcut and a startup registry\n>> entry. I first implemented the autostart with a shortcut to the\n>> startup folder, but I found out that it doesn't always work by\n>> default and ended up doing it with a registry entry. The registry\n>>  entry is removed by the uninstaller and can be also disabled from\n>>   the options menu, so I don't think it's such a big menace to the\n>>   user after all."]],"u":"https://mmalmi.github.io/satoshi/#email-37","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1255907510,"b":[["t","It's possible Bitcoin ran and bailed out because something was wrong.\ndebug.log should tell something if that was the case.  What OS are you\nusing?  I wonder if we need Admin privilege and don't realize it.  Stuff\nthat requires Admin can't start on startup on Vista.\n\nProgram shortcuts have multiple tabs of settings with lots of little\ndetails.  I'll try the startup folder code and see if I can reproduce\nthe problem.  Every other systray icon on my computer is in the startup\nfolder, and it makes it easy for users to manage all their autoruns in\none place.  The things in the registry key tend to be devious hidden\nbloatware.\n\nI implemented the code to flush wallet.dat whenever it's closed so we'll\nbe able to tell users they only need to backup wallet.dat.  You can\nrestore just wallet.dat and it'll re-download the rest.  I'll have to do\nanother stress test before release."],["q","Well, the code worked and made a shortcut in the startup folder. For\nsome reason it didn't automatically start when booting, but worked fine\nwhen you clicked on it in the menu. Now I tried making a shortcut\nmanually, and this time it works on autostart, don't know why. I could\ntry again with the older code.\n\n> I got it, I see you checked in the startup folder code before changing\n> it to registry.  I don't see any visible problems in the code.  I guess\n> it depends what exactly the problem was with it not always working by\n> default.  Was there a Vista/UAC security problem?\n>\n> Satoshi Nakamoto wrote:\n>> What was the problem with the shortcut in the startup folder?  If\n>> you could send me the code, I'd like to take another look and see\n>> if I can see what the problem was.  The first strcat in the\n>> registry code should be strcpy, otherwise it would fail\n>> intermittently.  If the same code was in the shortcut one, maybe\n>> that was the problem.\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> I made a Windows installer for the latest version of Bitcoin,\n>>> which includes the autostart and minimize to tray features. The\n>>> installer makes a start menu shortcut and a startup registry\n>>> entry. I first implemented the autostart with a shortcut to the\n>>> startup folder, but I found out that it doesn't always work by\n>>> default and ended up doing it with a registry entry. The registry\n>>>  entry is removed by the uninstaller and can be also disabled from\n>>> the options menu, so I don't think it's such a big menace to the\n>>> user after all.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-38","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1256063936,"b":[["q","It's possible Bitcoin ran and bailed out because something was wrong.\ndebug.log should tell something if that was the case.  What OS are you\nusing?  I wonder if we need Admin privilege and don't realize it.\nStuff that requires Admin can't start on startup on Vista."],["t","I'm using XP. I recompiled the older revision and this time the\nstartup shortcut works. It also works when testing on Vista\n(non-admin). Maybe I just missed something the previous time."],["q","Program shortcuts have multiple tabs of settings with lots of little\ndetails.  I'll try the startup folder code and see if I can reproduce\nthe problem.  Every other systray icon on my computer is in the startup\nfolder, and it makes it easy for users to manage all their autoruns in\none place.  The things in the registry key tend to be devious hidden\nbloatware."],["t","Here it's the other way around, I have all my startup programs in the\nregistry. But maybe the shortcut method is nicer for the user, if it\nworks just as well"]],"u":"https://mmalmi.github.io/satoshi/#email-39","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1256147929,"b":[["t","Yeah, I put back your startup folder shortcut code and it started fine\nfor me too on XP and Vista.  For good measure, I changed it to make the\nshortcut settings look identical to one I manually created.  I set the\nworking directory to where the EXE is since that's where debug.log is\ncreated, otherwise windows puts it in some weird directory.  I didn't\nchange the setup script yet.\n\nI checked everything in to SVN (thanks for setting that up)\n- multi-proc generate\n- flush wallet.dat after every change so the DB doesn't leave that stuff\nin the transaction logs\n- view menu checkbox to hide all generated coins so you can see just\nyour payment transactions\n- disabled transaction fee option\n- made the minimize to tray options similar to Firefox's MinimizeToTray\n- bunch of other misc changes since the 0.1.5 release\n\nI made it not show non-accepted generated coins.  It won't show\ngenerated coins until they have at least one confirmation (one block\nlinked after it), so usually they'll just never be seen.  Occasionally a\ngenerated coin that was displayed might disappear because it became not\naccepted later.  I don't think anyone would notice the occasional\nnon-accepteds if we didn't point them out in the UI.  People have told\nme they find it annoying to have to look at them, as they're permanently\ndisplayed in the transaction record.\n\nI still have more testing to do.  I guess we gotta test Windows 7 now."],["q","> It's possible Bitcoin ran and bailed out because something was wrong.\n> debug.log should tell something if that was the case.  What OS are you\n> using?  I wonder if we need Admin privilege and don't realize it.\n> Stuff that requires Admin can't start on startup on Vista.\n\nI'm using XP. I recompiled the older revision and this time the startup\nshortcut works. It also works when testing on Vista (non-admin). Maybe I\njust missed something the previous time.\n\n> Program shortcuts have multiple tabs of settings with lots of little\n> details.  I'll try the startup folder code and see if I can reproduce\n> the problem.  Every other systray icon on my computer is in the startup\n> folder, and it makes it easy for users to manage all their autoruns in\n> one place.  The things in the registry key tend to be devious hidden\n> bloatware.\n\nHere it's the other way around, I have all my startup programs in the\nregistry. But maybe the shortcut method is nicer for the user, if it\nworks just as well","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-40","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1}],"id":"x20"},{"k":"x","s":"martti-malmi","t":"Re: [bitcoin-list] Does Bitcoin Crash in Windows?","u":"https://mmalmi.github.io/satoshi/#email-41","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1256342106,"b":[["q"," Do you Windows users experience occasional Bitcoin crashes?\nLately Bitcoin running in wine-1.0.1 has been crashing frequently. I was\njust wondering whether this is a Wine issue or a Bitcoin issue. ","Liberty Standard wrote:"],["t","I haven't had any reports of crashes in v0.1.5.  It's been rock solid\nfor me on Windows.  I think it must be Wine related.  If you get another\ncrash in Wine and it prints anything on the terminal, e-mail me and I\nmay be able to figure out what happened, maybe something I can work\naround.  Martti and I have been working on a new version to release soon\nand it would be nice to get any Wine fixes in there."],["q","The following four lines print from the terminal when I start Bitcoin.\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub\nfixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot\nfixme:toolhelp:Heap32ListFirst : stub"],["t","Those don't look like anything to worry about.  Probably functions\nunimplemented by Wine that are harmlessly stubbed out."],["q","I previously wasn't starting Bitcoin from the terminal, so I don't know what\ngets printed out when it crashes, but I'll reply with the results the next\ntime it crashes.\n\nWhile Bitcoin first downloads previously completed blocks, the file\ndebug.log grows grows to 17.4 MB and then stops growing. I imagine it will\ncontinue to grow as more bitcoins are completed."],["t","You can delete debug.log occasionally if you don't want to take the disk\nspace.  It's just status messages that help with debugging.\n\nbitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing\nsome maintenance.\n\nSatoshi\n\n------------------------------------------------------------------------------\nCome build with us! The BlackBerry(R) Developer Conference in SF, CA\nis the only developer event you need to attend this year. Jumpstart your\ndeveloping skills, take BlackBerry mobile applications to market and stay\nahead of the curve. Join us from November 9 - 12, 2009. Register now!\nhttp://p.sf.net/sfu/devconference"],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-41","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x21"},{"k":"x","s":"martti-malmi","t":"Fw: bitcoin.sourceforge.net","u":"https://mmalmi.github.io/satoshi/#email-42","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1256579410,"b":[["t","Any idea what's going on with it?  Every time I look, it's fine.\n\nEugen Leitl wrote:"],["q","> bitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing","On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:"],["t","Doesn't work right now."],["q","> some maintenance."],["q","In case you weren't aware, the Bitcoin website is down.\n\nhttp://bitcoin.sourceforge.net/\n\n-----\nYou are running bitweaver in TEST mode\n\n    * Click here to log a bug, if this appears to be an error with the\napplication.\n    * Go here to begin the installation process, if you haven't done so\nalready.\n    * To hide this message, please set the IS_LIVE constant to TRUE ","Liberty Standard wrote:"],["t","in your"],["q","kernel/config_inc.php file."]],"u":"https://mmalmi.github.io/satoshi/#email-42","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1256612569,"b":[["t","IS_LIVE option was indeed set to false, but it only affects the\nvisibility of error messages to user. I've noticed the site being slow\nat times, sometimes taking up to 30 seconds to load. I think it's\nrelated to the Sourceforge hosting. Bitweaver should be among the\nlightest PHP CMS'es, but I can check out if there are any issues to it.\n\nOff the topic, do you think that we could use Boost's thread and\nsocket libraries instead of the Windows-specific ones? Are there other\nwindows-only-functions used in the code?"],["q","Any idea what's going on with it?  Every time I look, it's fine.\n\nEugen Leitl wrote:\nOn Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:\n> > bitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing\n\nDoesn't work right now.\n\n> > some maintenance.\n\nLiberty Standard wrote:\n> In case you weren't aware, the Bitcoin website is down.\n>\n> http://bitcoin.sourceforge.net/\n>\n> -----\n> You are running bitweaver in TEST mode\n>\n>     * Click here to log a bug, if this appears to be an error with the\n> application.\n>     * Go here to begin the installation process, if you haven't done so\n> already.\n>     * To hide this message, please set the IS_LIVE constant to TRUE in your\n> kernel/config_inc.php file."]],"u":"https://mmalmi.github.io/satoshi/#email-43","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Fw: bitcoin.sourceforge.net"},{"f":"Satoshi Nakamoto","d":1256618747,"b":[["t","Sourceforge is just so darn slow.  I don't know what else to do though.\n  It's such a standard, more often than not any given project has a\nprojectname.sourceforge.net site.  When I see whatever.sourceforge.net\nin a google search, I assume that's the official site.\n\nIs there a way to make Bitweaver allow users to edit (and maybe delete)\ntheir own messages in the forum?\n\nGetting antsy to port to Linux?  It's not a decision to be taken lightly\nbecause once it's done, it doubles my testing and building workload.\nAlthough I am worried about Liberty's Wine crashes.\n\nI've tried to be as portable as possible and use standard C stuff\ninstead of Windows calls.  The threading is _beginthread which is part\nof the standard C library.  wxWidgets has wxCriticalSection stuff we can\nuse.  The sockets code is send/recv stuff which I think is the same as\nunix because Microsoft ported sockets from BSD.  We need direct control\nover sockets, it wouldn't be a good idea to get behind an abstraction\nlayer.  wxWidgets is a good place to look for cross-platform support\nfunctions.  I want to avoid #ifdefing up the code if we can.  Anything\nthat's used more than once probably becomes a function in util.cpp that\nhas the #ifdef in it.\n\nBTW, I have a lot of uncommitted changes right now because it includes\nsome crucial protocol transitions that can't be unleashed on the network\nuntil I've tested the heck out of it.  It shouldn't be too much longer.\n\nCan you make the setup uninstall the Startup folder icon?  I figure it\nshould install and uninstall an icon in a regular program group, and\njust uninstall the Startup folder one.  I guess it doesn't matter that\nmuch whether it installs and uninstalls the Startup folder icon or just\nuninstalls it."],["q","IS_LIVE option was indeed set to false, but it only affects the\nvisibility of error messages to user. I've noticed the site being slow\nat times, sometimes taking up to 30 seconds to load. I think it's\nrelated to the Sourceforge hosting. Bitweaver should be among the\nlightest PHP CMS'es, but I can check out if there are any issues to it.\n\nOff the topic, do you think that we could use Boost's thread and socket\nlibraries instead of the Windows-specific ones? Are there other\nwindows-only-functions used in the code?\n\n> Any idea what's going on with it?  Every time I look, it's fine.\n>\n>\n> Eugen Leitl wrote:\n> On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:\n>> > bitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing\n>\n> Doesn't work right now.\n>\n>> > some maintenance.\n>\n>\n> Liberty Standard wrote:\n>> In case you weren't aware, the Bitcoin website is down.\n>>\n>> http://bitcoin.sourceforge.net/\n>>\n>> -----\n>> You are running bitweaver in TEST mode\n>>\n>>     * Click here to log a bug, if this appears to be an error with the\n>> application.\n>>     * Go here to begin the installation process, if you haven't done so\n>> already.\n>>     * To hide this message, please set the IS_LIVE constant to TRUE\n>> in your\n>> kernel/config_inc.php file.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-44","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Fw: bitcoin.sourceforge.net"},{"f":"mmalmi@cc.hut.fi","d":1256765255,"b":[["q","Sourceforge is just so darn slow.  I don't know what else to do though.\n It's such a standard, more often than not any given project has a\nprojectname.sourceforge.net site.  When I see whatever.sourceforge.net\nin a google search, I assume that's the official site.\n\nIs there a way to make Bitweaver allow users to edit (and maybe delete)\ntheir own messages in the forum?"],["t","It's not possible with the current version of Bitweaver. Bitweaver's\nwiki and forum packages aren't so very highly advanced. SF hosting\nalso has its disadvantages, like the occasional slowness and lack of\ne-mailer and user IP retrieving. I've been considering to buy web\nhosting from prq.se (the host of Wikileaks and Pirate Bay, among\nothers) to be used later for the exchange service. I could maybe host\nthe project site there as well, under a separate user account for\nbetter security. There I could set up Drupal or TikiWiki, which are\nmore advanced and have quite a lot bigger and more active\ndeveloper/user communities than Bitweaver."],["q","Getting antsy to port to Linux?  It's not a decision to be taken\nlightly because once it's done, it doubles my testing and building\nworkload. Although I am worried about Liberty's Wine crashes.\n\nI've tried to be as portable as possible and use standard C stuff\ninstead of Windows calls.  The threading is _beginthread which is part\nof the standard C library.  wxWidgets has wxCriticalSection stuff we\ncan use.  The sockets code is send/recv stuff which I think is the same\nas unix because Microsoft ported sockets from BSD.  We need direct\ncontrol over sockets, it wouldn't be a good idea to get behind an\nabstraction layer.  wxWidgets is a good place to look for\ncross-platform support functions.  I want to avoid #ifdefing up the\ncode if we can.  Anything that's used more than once probably becomes a\nfunction in util.cpp that has the #ifdef in it."],["t","Ok. I replaced the Windows thread and socket library includes with\ntheir POSIX equivalents, and now it only gives a few errors, mostly  svn/branches, it doesn't need to be an official release yet."],["q","Can you make the setup uninstall the Startup folder icon?  I figure it\nshould install and uninstall an icon in a regular program group, and\njust uninstall the Startup folder one.  I guess it doesn't matter that\nmuch whether it installs and uninstalls the Startup folder icon or just\nuninstalls it."],["t","I'll do it."]],"u":"https://mmalmi.github.io/satoshi/#email-45","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Fw: bitcoin.sourceforge.net"},{"f":"Satoshi Nakamoto","d":1256781930,"b":[["t","I'll convert the CriticalSection code to wxCriticalSection and upload it\nto SVN (it's a little tricky).  I don't know what to do for\nTryEnterCriticalSection though.  I think I'm almost ready to check\neverything in.\n\nYou're probably right, it's about time to do a linux build.  I've been\nworking on getting my linux machine set up and building the dependencies."],["q","Ok. I replaced the Windows thread and socket library includes with their\nPOSIX equivalents, and now it only gives a few errors, mostly from the\nCriticalSections. If I make it work, I'll put it into svn/branches, it\ndoesn't need to be an official release yet."]],"u":"https://mmalmi.github.io/satoshi/#email-46","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Fw: bitcoin.sourceforge.net"},{"f":"mmalmi@cc.hut.fi","d":1256789290,"b":[["q","I'll convert the CriticalSection code to wxCriticalSection and upload\nit to SVN (it's a little tricky).  I don't know what to do for\nTryEnterCriticalSection though.  I think I'm almost ready to check\neverything in."],["t","Would the Boost mutex be of any help here?\n\nhttp://www.boost.org/doc/libs/1_40_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts"]],"u":"https://mmalmi.github.io/satoshi/#email-47","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Fw: bitcoin.sourceforge.net"}],"id":"x22"},{"k":"x","s":"martti-malmi","t":"Re: Linux build","u":"https://mmalmi.github.io/satoshi/#email-48","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1256798310,"b":[["t","The easy solution I took was to look at the wxWidgets source code and\nsee how they did it.  They just mapped it to wxMutex on non-MSW, which\ndoes have TryEnter, so that mapped in perfectly.\n\nI checked in all my backlog of changes to SVN, including the overhaul of\nCCriticalSection in util.h and OpenSSL's mutex callback in util.cpp to\ndo everything with wxWidgets when not on Windows.\n\nIf we get it working on Linux, I'll run my test suite against it here\noff-network first, then we can give an unreleased build to\nLibertyStandard to test for a while before going public."],["q","> I'll convert the CriticalSection code to wxCriticalSection and upload\n> it to SVN (it's a little tricky).  I don't know what to do for\n> TryEnterCriticalSection though.  I think I'm almost ready to check\n> everything in.\n\nWould the Boost mutex be of any help here?\n\nhttp://www.boost.org/doc/libs/1_40_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-48","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1256864745,"b":[["t","I fixed some non-portable stuff I came across:\nQueryPerformanceCounter\n%I64d in printf format strings\nSleep\nCheckDiskSpace\n\nIf there's any other unportable stuff you know of I should fix, let me know.\n\nI think I'll move debug.log and db.log into the same directory as the\ndata files (%appdata%\\Bitcoin), rather than whatever the current\ndirectory happens to be."]],"u":"https://mmalmi.github.io/satoshi/#email-49","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1256980910,"b":[["t","I made an #ifdef to replace QueryPerformanceCounter with Linux's\ngettimeofday in util.h. Some Unicode/ANSI errors were resolved without\ncode changes when I updated to wxWidgets 2.9. The only compile error\nI'm getting in Linux at the moment is from heapchk() in util.h."],["q","I fixed some non-portable stuff I came across:\nQueryPerformanceCounter\n%I64d in printf format strings\nSleep\nCheckDiskSpace\n\nIf there's any other unportable stuff you know of I should fix, let me know.\n\nI think I'll move debug.log and db.log into the same directory as the\ndata files (%appdata%\\Bitcoin), rather than whatever the current\ndirectory happens to be."]],"u":"https://mmalmi.github.io/satoshi/#email-50","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1257019798,"b":[["t","heapchk() is just a MSVCRT debugging thing that's not being used.  It\ncan be a no-op on Linux.  OpenSSL automatically uses /dev/urandom to\nseed on Linux, so RandAddSeedPerfmon can also be a no-op.\n\nDon't let it connect to the network before we've tested it thoroughly\noff-net.  If you have two computers, unplug the internet and use\n\"bitcoin -connect=<ip>\" to connect to each other, one windows and one\nlinux.  -connect will allow you to connect to non-routable addresses\nlike 192.168.x.x.  We don't want to reflect badly on the reliability of\nthe network if it throws off some malformed crud we hadn't thought to\ncheck for yet, or discovers something else anti-social to do on the network.\n\nI have time that I can do some testing when you've got something\nbuildable to test.  I can include it in the stress test I'm currently\nrunning on the changes so far."],["q","I made an #ifdef to replace QueryPerformanceCounter with Linux's\ngettimeofday in util.h. Some Unicode/ANSI errors were resolved without\ncode changes when I updated to wxWidgets 2.9. The only compile error I'm\ngetting in Linux at the moment is from heapchk() in util.h.\n\n> I fixed some non-portable stuff I came across:\n> QueryPerformanceCounter\n> %I64d in printf format strings\n> Sleep\n> CheckDiskSpace\n>\n> If there's any other unportable stuff you know of I should fix, let me\n> know.\n>\n> I think I'll move debug.log and db.log into the same directory as the\n> data files (%appdata%\\Bitcoin), rather than whatever the current\n> directory happens to be.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-51","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1257233501,"b":[["t","I uploaded what I've ported so far to the svn/branches. Util, script,\ndb and the headers compile fully now and net.cpp partially, so there's\nstill work to do.\n\n_beginthread doesn't have a direct Linux equivalent, so I used Boost\nthreads instead.\n\nI couldn't get connected using the Tor SOCKS proxy. That might be\nbecause of the Freenode Tor policy which requires connecting to their\nhidden service: http://freenode.net/irc_servers.shtml#tor"],["q","heapchk() is just a MSVCRT debugging thing that's not being used.  It\ncan be a no-op on Linux.  OpenSSL automatically uses /dev/urandom to\nseed on Linux, so RandAddSeedPerfmon can also be a no-op.\n\nDon't let it connect to the network before we've tested it thoroughly\noff-net.  If you have two computers, unplug the internet and use\n\"bitcoin -connect=<ip>\" to connect to each other, one windows and one\nlinux.  -connect will allow you to connect to non-routable addresses\nlike 192.168.x.x.  We don't want to reflect badly on the reliability of\nthe network if it throws off some malformed crud we hadn't thought to\ncheck for yet, or discovers something else anti-social to do on the\nnetwork.\n\nI have time that I can do some testing when you've got something\nbuildable to test.  I can include it in the stress test I'm currently\nrunning on the changes so far.\n\nmmalmi@cc.hut.fi wrote:\n> I made an #ifdef to replace QueryPerformanceCounter with Linux's\n> gettimeofday in util.h. Some Unicode/ANSI errors were resolved\n> without code changes when I updated to wxWidgets 2.9. The only\n> compile error I'm getting in Linux at the moment is from heapchk()\n> in util.h.\n>\n>> I fixed some non-portable stuff I came across:\n>> QueryPerformanceCounter\n>> %I64d in printf format strings\n>> Sleep\n>> CheckDiskSpace\n>>\n>> If there's any other unportable stuff you know of I should fix,\n>> let me know.\n>>\n>> I think I'll move debug.log and db.log into the same directory as the\n>> data files (%appdata%\\Bitcoin), rather than whatever the current\n>> directory happens to be.\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-52","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1257313097,"b":[["t","It was almost there.  I fixed a few things and got it to finish\ncompiling but I don't know the system libraries to link to so there's\nundefined references galore.\n\nI changed the makefile to look for things under /usr/local and in their\ndefault \"make install\" locations.  I wrote what I did and switches I\nused in build-unix.txt.  I'm currently using wxWidgets 2.8.9 for now\nbecause it's the same version as on Windows and I don't want to wonder\nif there's version change issues at the same time as platform change.\n2.8.10 or 2.9.0 are probably fine though.  I went with the\nsingle-library compile of wxWidgets since we're linking to almost every\nlibrary anyway.\n\nI added xpm files, which is what they use everywhere else but Windows\ninstead of RC files.  They're clever C files that define graphics in\nstatic arrays.  The bitcoin icon has 5 different versions but I couldn't\nfigure out how that works in xpm so I only put the biggest one.  Maybe\non GTK it scales it for you.  I don't know if these are right or what,\nbut they compile."],["q","I uploaded what I've ported so far to the svn/branches. Util, script, db\nand the headers compile fully now and net.cpp partially, so there's\nstill work to do.\n\n_beginthread doesn't have a direct Linux equivalent, so I used Boost\nthreads instead.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-54","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1257367083,"b":[["t","Just letting you know I'm still working on the Linux build so we don't\nduplicate work.  I got it linked and ran it and working through runtime\nissues like getting it switched to load bitmaps from xpm instead of\nresources.\n\nThere are debian packages available for some of the dependencies instead\nof having to compile them ourselves:\napt-get install build-essential\napt-get install libgtk2.0-dev\napt-get install libssl-dev\n\nI need to see if Berkeley DB or Boost have packages.\n\nWe'll shared-link OpenSSL, I'm pretty sure it's always preinstalled on\nLinux.  GTK has to be shared linked.  I'm not completely sure if it's\npreinstalled by default."]],"u":"https://mmalmi.github.io/satoshi/#email-55","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1257370964,"b":[["q","Besides the IRC part, how did your test of proxy go?  Since you've been\nconnected before, your addr.dat contains known node addresses, but\nwithout IRC to know which ones are online, it takes a long time to find\nthem.  There are normally 1 to 3 other nodes besides you that can\naccept incoming connections, and existing nodes that already know you\nwould eventually connect to you.  How many connections did you get, and\nhow long did it take?  I guess to know whether it successfully\nconnected outbound through TOR you'd need to search debug.log for\n\"connected\"."],["t","Enabling the proxy setting and restarting Bitcoin I got the first\nconnections in less than a minute and ultimately even 8 connections. I\nwonder if they're all really through TOR. Netstat shows only 2\nconnections to localhost:9050 and 7 connections from local port 8333\nto elsewhere. (Some of the shown connections may be already\ndisconnected ones.) For some reason there's no debug.log in the folder\nwhere I'm running it."],["q","If some nodes that accept incoming connects were willing to have their\nIP coded into the program, it could seed automatically.  Or some IP\nseed addresses posted on a Wiki page with the instructions."],["t","The wiki page sounds like a good and quickly applicable solution. I\ncould keep my ip updated there and we could ask others to do the same.\nWhen the Linux build works, it's easier to set up nodes on servers\nthat are online most of the time and have a static IP. A static ip\nlist shipped with Bitcoin and a peer exchange protocol would be cool.\nThat way there'd be no need for an IRC server."],["q","Just letting you know I'm still working on the Linux build so we don't\nduplicate work.  I got it linked and ran it and working through runtime\nissues like getting it switched to load bitmaps from xpm instead of\nresources."],["t","Ok. I didn't get it linked on the first attempt, but I didn't look\nfurther into the dependencies yet."]],"u":"https://mmalmi.github.io/satoshi/#email-56","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1257399063,"b":[["t","I merged the linux changes into the main trunk on SVN.  It compiles and\nruns now.  I think all the problems are in the UI.  The menus quickly\nquit working and it doesn't repaint when it's supposed to unless I\nresize it, and the UI is getting some segfaults.  Shouldn't be too hard\nto debug with gdb.  I haven't tested if it plays nice with other nodes\nyet so keep it off-net.\n\nbuild-unix.txt and makefile.unix added"]],"u":"https://mmalmi.github.io/satoshi/#email-57","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1257488415,"b":[["t","It works reliably on Linux now, except if it uses wxMessageBox() outside\nthe GUI thread, it'll crash because non-GUI threads can't open a window\non Linux.  I haven't got to fixing that yet.  I've been running my\nstress test on it and it's functioning normally.\n\nMost of wxWidgets is not thread-safe to use in threads other than the UI\nthread, but as a rule of thumb on Windows anything not UI related is OK.\n  It turns out its more thread-unsafe on GTK.  I replaced a bunch of\nstuff at once so I don't know if it was just one thing (probably\nRepaint), but I have to assume even any wx function that uses wxString\nis not safe to use outside the UI thread.  So dang, there goes all the\nnice wxWidgets portability support functions.  I left a few simple\nthings like wxThread::GetCPUCount() that I checked the source and it's\nall numerical, and wxMutex has to be safe or it'd be useless.\n\nThere's an issue that if you exit and run it again right away, it can't\nbind port 8333.  The port frees up after about a minute.  Unless I'm\nmissing something, I am closing the socket before exit, so I don't know\nwhat else I can do.  Maybe this is just something about Linux that it\ntakes a minute to free up a port you had bound.  Possibly a security\nfeature so some trojan doesn't kill the web server and quickly jump into\nits place and pick up all the client retries.\n\nStill gotta figure out how to do the xpm version of the icon correctly.\n\nI wonder if the database dat files are interchangeable with Windows."]],"u":"https://mmalmi.github.io/satoshi/#email-60","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x23"},{"k":"x","s":"martti-malmi","t":"Re: Linux build, proxy","u":"https://mmalmi.github.io/satoshi/#email-53","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257263605,"b":[["t","Great, I've been looking forward to working on the Linux build.\n\nIf you connect to Freenode's hidden service, then they tell you they've\nalso banned TOR from that due to abuse and it kicks you off.  There's a\nseveral step procedure you can do to run a password utility on unix and\ne-mail request an account that you could login with, but that's getting\npretty complicated.  I wonder if we could get away with applying for one\naccount and then everyone use the same account?  I suppose the IRC\nserver probably limits accounts to one login, or some admin might not\nlike to see a dozen logins on the same account.\n\nBesides the IRC part, how did your test of proxy go?  Since you've been\nconnected before, your addr.dat contains known node addresses, but\nwithout IRC to know which ones are online, it takes a long time to find\nthem.  There are normally 1 to 3 other nodes besides you that can accept\nincoming connections, and existing nodes that already know you would\neventually connect to you.  How many connections did you get, and how\nlong did it take?  I guess to know whether it successfully connected\noutbound through TOR you'd need to search debug.log for \"connected\".\n\nTo originally connect with TOR without connecting normally once to get\nseeded, you'd have to know the address of an existing node that can\naccept incoming connections and seed it like this:\nbitcoin -proxy=127.0.0.1:9050 -addnode=<ip of a node>\n\nIf some nodes that accept incoming connects were willing to have their\nIP coded into the program, it could seed automatically.  Or some IP seed\naddresses posted on a Wiki page with the instructions.\n\nAnother option is to search the world again for an IRC server that\ndoesn't ban TOR nodes.  Or if we could get someone to set one up.  IRC\nservers ban TOR because they have actual text chat on them... if there\nwas one with just bots and junk then it wouldn't care.  Probably should\npost a question on the forum or the mailing list and see if anyone knows\none.\n\nAnother problem is that TOR users can't accept incoming connections, and\nwe have so few that can.  If everyone goes to TOR, there won't be any\nnodes to connect to.\n\nWe have a shortage of nodes that can accept incoming connections.  It\ngenerally ranges from 2 to 4 lately.  We need to emphasize the\nimportance to people of setting up port forwarding on their router.\nEvery P2P file sharing program has instructions how to do it.  We should\nhave a paragraph on the bitcoin.sourceforge.net homepage urging people\nto set up port forwarding to accept incoming connections, and a link to\na site that describes how to do it for each router."],["q","I uploaded what I've ported so far to the svn/branches. Util, script, db\nand the headers compile fully now and net.cpp partially, so there's\nstill work to do.\n\n_beginthread doesn't have a direct Linux equivalent, so I used Boost\nthreads instead.\n\nI couldn't get connected using the Tor SOCKS proxy. That might be\nbecause of the Freenode Tor policy which requires connecting to their\nhidden service: http://freenode.net/irc_servers.shtml#tor\n\n> heapchk() is just a MSVCRT debugging thing that's not being used.  It\n> can be a no-op on Linux.  OpenSSL automatically uses /dev/urandom to\n> seed on Linux, so RandAddSeedPerfmon can also be a no-op.\n>\n> Don't let it connect to the network before we've tested it thoroughly\n> off-net.  If you have two computers, unplug the internet and use\n> \"bitcoin -connect=<ip>\" to connect to each other, one windows and one\n> linux.  -connect will allow you to connect to non-routable addresses\n> like 192.168.x.x.  We don't want to reflect badly on the reliability of\n> the network if it throws off some malformed crud we hadn't thought to\n> check for yet, or discovers something else anti-social to do on the\n> network.\n>\n> I have time that I can do some testing when you've got something\n> buildable to test.  I can include it in the stress test I'm currently\n> running on the changes so far.\n>\n> mmalmi@cc.hut.fi wrote:\n>> I made an #ifdef to replace QueryPerformanceCounter with Linux's\n>> gettimeofday in util.h. Some Unicode/ANSI errors were resolved\n>> without code changes when I updated to wxWidgets 2.9. The only\n>> compile error I'm getting in Linux at the moment is from heapchk()\n>> in util.h.\n>>\n>>> I fixed some non-portable stuff I came across:\n>>> QueryPerformanceCounter\n>>> %I64d in printf format strings\n>>> Sleep\n>>> CheckDiskSpace\n>>>\n>>> If there's any other unportable stuff you know of I should fix,  let\n>>> me know.\n>>>\n>>> I think I'll move debug.log and db.log into the same directory as the\n>>> data files (%appdata%\\Bitcoin), rather than whatever the current\n>>> directory happens to be.\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-53","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1}],"id":"x24"},{"k":"x","s":"martti-malmi","t":"Re: Proxy","u":"https://mmalmi.github.io/satoshi/#email-58","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257434727,"b":[["q","Enabling the proxy setting and restarting Bitcoin I got the first\nconnections in less than a minute and ultimately even 8 connections. I\nwonder if they're all really through TOR. Netstat shows only 2\nconnections to localhost:9050 and 7 connections from local port 8333 to\nelsewhere. (Some of the shown connections may be already disconnected\nones.) For some reason there's no debug.log in the folder where I'm\nrunning it.","mmalmi@cc.hut.fi wrote:"],["t","debug.log moved to the data directory \"%appdata%/bitcoin/debug.log\"\n\n7 inbound and 2 outbound sounds about as expected.\n\nMy last SVN commit included an overhaul of the code that selects the\norder of addresses to connect to, trying them in the order of most\nrecently seen online, so it should get connected in a more reasonable\namount of time if IRC is unavailable.  IRC is really only needed to seed\nthe first connection, but we've been using it as a crutch to get\nconnected faster."],["q","> If some nodes that accept incoming connects were willing to have their\n> IP coded into the program, it could seed automatically.  Or some IP\n> seed addresses posted on a Wiki page with the instructions.\n\nThe wiki page sounds like a good and quickly applicable solution. I\ncould keep my ip updated there and we could ask others to do the same.\nWhen the Linux build works, it's easier to set up nodes on servers that\nare online most of the time and have a static IP. A static ip list\nshipped with Bitcoin and a peer exchange protocol would be cool. That\nway there'd be no need for an IRC server."],["t","That would be great.  It's only TOR users that need it, so in the\ninstructions saying \"bitcoin -proxy=127.0.0.1:9050 -addnode=<someip>\",\nsomeip could be an actual static IP, with the wiki free-for-all\nadd-your-ip list nearby or a link to it.  There should be a link to that optional step, add your IP to this list now that you can accept incoming\nif you're static.\n\nDo you think anonymous people are looking to be completely stealth, as\nin never connect once without TOR so nobody knows they use bitcoin, or\njust want to switch to TOR before doing any transactions?  It's just if\nyou want to be completely stealth that you'd have to go through the\n-proxy -addnode manual seeding.  It would be very easy to fumble that\nup; if you run bitcoin normally to begin with it immediately\nautomatically starts connecting."]],"u":"https://mmalmi.github.io/satoshi/#email-58","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1}],"id":"x25"},{"k":"x","s":"martti-malmi","t":"Forum","u":"https://mmalmi.github.io/satoshi/#email-59","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257442438,"b":[["t","Now that the forum on bitcoin.sourceforge.net is catching on, we really\nshould look for somewhere that freehosts full blown forum software.  The\nbitweaver forum feature is just too lightweight.  I assume the \"Forum\"\ntab on the homepage can link out to wherever the forum is hosted.\n\nI've seen projects that have major following just from forum talk and\npie-in-the-sky planning without even having any code yet.  Having a lot\nof forum talk gives a project more presence on the net, more search\nhits, makes it look big, draws new users in, helps solve support\nquestions, hashes out what features are most of wanted.\n\nIt would be a big plus if it could support SSL, at least for the login\npage if not sitewide.  Multiple people on the forum have expressed\ninterest in TOR/I2P, and those users need SSL because a lot of TOR exit\nnodes are probably password scrapers run by identity thieves.  A lot of\nthe core interest in Bitcoin is going to be from the privacy crowd.\n\nAny ideas where we can get a free forum?  Maybe we should look at where\nsome other projects have their forums hosted for ideas where to look."]],"u":"https://mmalmi.github.io/satoshi/#email-59","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1257588825,"b":[["q","Do you think anonymous people are looking to be completely stealth, as\nin never connect once without TOR so nobody knows they use bitcoin, or\njust want to switch to TOR before doing any transactions?  It's just if\nyou want to be completely stealth that you'd have to go through the\n-proxy -addnode manual seeding.  It would be very easy to fumble that\nup; if you run bitcoin normally to begin with it immediately\nautomatically starts connecting."],["t","The people who are interested in being stealthy tend to be more\ntechnically able, and they probably don't have a problem following the\ninstructions to get perfect secrecy. Of course there could be a\nconnect-button in the UI that needs to be clicked before use, but the\ntradeoff is that the UI becomes less straightforward for the average\nuser."],["q","It would be a big plus if it could support SSL, at least for the login\npage if not sitewide.  Multiple people on the forum have expressed\ninterest in TOR/I2P, and those users need SSL because a lot of TOR exit\nnodes are probably password scrapers run by identity thieves.  A lot of\nthe core interest in Bitcoin is going to be from the privacy crowd.\n\nAny ideas where we can get a free forum?  Maybe we should look at where\nsome other projects have their forums hosted for ideas where to look."],["t","One option would be ning.com. Ning.com is a popular community site and\nmany users who already have an account wouldn't need to register a new\naccount. Example: http://p2pfoundation.ning.com/. This seems to\nsupport SSL.\n\nAnother option would be to relocate the whole site to some place where\nwe can run Drupal or TikiWiki. I've been thinking of buying virtual\nserver or web hosting for the exchange service sometime soon, and if\nthe platform allows for two separate accounts, we could run the site\nthere too. The CMS and its database can be always copied and relocated\nto a new web host if needed."]],"u":"https://mmalmi.github.io/satoshi/#email-61","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Forum"},{"f":"mmalmi@cc.hut.fi","d":1257698907,"b":[["t","I made a ning.com site for testing: bitcoin.ning.com. At least it's\nthere to get Google hits, even if we didn't use it."],["q","Now that the forum on bitcoin.sourceforge.net is catching on, we really\nshould look for somewhere that freehosts full blown forum software.\nThe bitweaver forum feature is just too lightweight.  I assume the\n\"Forum\" tab on the homepage can link out to wherever the forum is\nhosted.\n\nI've seen projects that have major following just from forum talk and\npie-in-the-sky planning without even having any code yet.  Having a lot\nof forum talk gives a project more presence on the net, more search\nhits, makes it look big, draws new users in, helps solve support\nquestions, hashes out what features are most of wanted.\n\nIt would be a big plus if it could support SSL, at least for the login\npage if not sitewide.  Multiple people on the forum have expressed\ninterest in TOR/I2P, and those users need SSL because a lot of TOR exit\nnodes are probably password scrapers run by identity thieves.  A lot of\nthe core interest in Bitcoin is going to be from the privacy crowd.\n\nAny ideas where we can get a free forum?  Maybe we should look at where\nsome other projects have their forums hosted for ideas where to look."]],"u":"https://mmalmi.github.io/satoshi/#email-65","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Forum"},{"f":"Satoshi Nakamoto","d":1257706118,"b":[["t","I'm not really a fan of that type of forum layout.  The thread list only\nfits about 4 threads on a page, posts are treated like news articles or\nblog posts with reply comments at the bottom.  It's more of a social\nnetworking site, not really conducive to technical discussion.\n\nI'm thinking phpBB or IPB or similar.  One line of text per thread,\nsmall fonts, efficient use of vertical space.  Most people are already\nfamiliar with the interface."],["q","I made a ning.com site for testing: bitcoin.ning.com. At least it's\nthere to get Google hits, even if we didn't use it.\n\n> Now that the forum on bitcoin.sourceforge.net is catching on, we really\n> should look for somewhere that freehosts full blown forum software.\n> The bitweaver forum feature is just too lightweight.  I assume the\n> \"Forum\" tab on the homepage can link out to wherever the forum is\n> hosted.\n>\n> I've seen projects that have major following just from forum talk and\n> pie-in-the-sky planning without even having any code yet.  Having a lot\n> of forum talk gives a project more presence on the net, more search\n> hits, makes it look big, draws new users in, helps solve support\n> questions, hashes out what features are most of wanted.\n>\n> It would be a big plus if it could support SSL, at least for the login\n> page if not sitewide.  Multiple people on the forum have expressed\n> interest in TOR/I2P, and those users need SSL because a lot of TOR exit\n> nodes are probably password scrapers run by identity thieves.  A lot of\n> the core interest in Bitcoin is going to be from the privacy crowd.\n>\n> Any ideas where we can get a free forum?  Maybe we should look at where\n> some other projects have their forums hosted for ideas where to look.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-67","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Forum"},{"f":"mmalmi@cc.hut.fi","d":1258391966,"b":[["t","I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently\nenabled with a self-signed certificate. Admin password is the same as\nin the Bitweaver. How about using this as the site platform? Maybe we\ncan make bitcoin.org or at least bitcoin.sf.net point there?"]],"u":"https://mmalmi.github.io/satoshi/#email-87","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1258400096,"b":[["q","I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently\nenabled with a self-signed certificate. Admin password is the same as in\nthe Bitweaver. How about using this as the site platform? Maybe we can\nmake bitcoin.org or at least bitcoin.sf.net point there?","mmalmi@cc.hut.fi wrote:"],["t","What do you see as the benefits of switching the wiki?\nSome I can think of:\n  SSL\n  get away from sourceforge's unreliable hosting\n  everything not logged by sourceforge\n\nThe forum feature is about as weak as bitweaver.  We need a full blown\nforum software for that.\n\nMy priority right now is to get a forum going, either phpBB or similar.\n  What do you think of the zetaboards option?  Should we go ahead with that?"]],"u":"https://mmalmi.github.io/satoshi/#email-88","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Forum"},{"f":"mmalmi@cc.hut.fi","d":1258402284,"b":[["q","What do you see as the benefits of switching the wiki?\nSome I can think of:\n SSL\n get away from sourceforge's unreliable hosting\n everything not logged by sourceforge"],["t","I think the biggest advantage is having a single site so you don't\nneed a separate account for the wiki and the forum, and the\nfunctionalities are also nicely integrated with the main site itself.\nAlso being ad-free is a plus."],["q","The forum feature is about as weak as bitweaver.  We need a full blown\nforum software for that."],["t","How about Drupal's forum functionality? Address:\nhttps://174.143.149.98/drupal/. The CMS in general looks better and\nsimpler than TikiWiki. If the forum's not good enough, then we can of\ncourse use a specialized forum software like phpBB."],["q","My priority right now is to get a forum going, either phpBB or similar.\n What do you think of the zetaboards option?  Should we go ahead with\nthat?"],["t","Otherwise fine, but the ads and the lack of SSL are a minus."]],"u":"https://mmalmi.github.io/satoshi/#email-89","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Forum"},{"f":"Satoshi Nakamoto","d":1258405822,"b":[["t","That's a good idea to go in a more web-publishing CMS type direction\nlike Drupal.  That's a better fit and can produce a better looking\nwebsite than a wiki.  I think I was wrong about wiki.  Only a few\nspecific people will do any website design work and those people can go\nahead and have a separate login.  In that case, login integration with\nthe forum doesn't matter much.  For security, I'd almost rather have a\ndifferent login than be constantly checking the forum with the same\nlogin that could pwn the website.\n\nDrupal's forum is less bad than the wikis, but still a long way from\nsomething I would want to use.\n\nzetaboards pros and cons:\n\npros:\n- we don't have to worry about bandwidth\n- they handle the backend management and security patches\n\ncon:\n- lack of SSL\n- lack of privacy, everything is logged\n- lack of control over the php code for customization\n- no CAPTCHA, and if they add one later it might be unacceptable flash\n- ads (could pay to get rid of them later if we care enough)\n- there's always the risk they abruptly cancel the site for some petty\nreason"],["q","> What do you see as the benefits of switching the wiki?\n> Some I can think of:\n>  SSL\n>  get away from sourceforge's unreliable hosting\n>  everything not logged by sourceforge\n\nI think the biggest advantage is having a single site so you don't need\na separate account for the wiki and the forum, and the functionalities\nare also nicely integrated with the main site itself. Also being ad-free\nis a plus.\n\n> The forum feature is about as weak as bitweaver.  We need a full blown\n> forum software for that.\n\nHow about Drupal's forum functionality? Address:\nhttps://174.143.149.98/drupal/. The CMS in general looks better and\nsimpler than TikiWiki. If the forum's not good enough, then we can of\ncourse use a specialized forum software like phpBB.\n\n> My priority right now is to get a forum going, either phpBB or similar.\n>  What do you think of the zetaboards option?  Should we go ahead with\n> that?\n\nOtherwise fine, but the ads and the lack of SSL are a minus.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-90","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Forum"},{"f":"Satoshi Nakamoto","d":1258477046,"b":[["q","How about Drupal's forum functionality? Address:\nhttps://174.143.149.98/drupal/. The CMS in general looks better and\nsimpler than TikiWiki. If the forum's not good enough, then we can of\ncourse use a specialized forum software like phpBB.","mmalmi@cc.hut.fi wrote:"],["t","Another issue I thought of with zetaboards: most free forum sites won't\nlet you export the user account database if you want to move.  I don't\nknow why I don't see any other software projects using a free forum, but\nI have to assume there might be a reason we would discover later.\n\nIf you can install phpBB3 on your VPS, that's probably the better option.\n\n From what I've seen on other forums, if the cost of bandwidth becomes\nan issue, a small Google Adwords (text links) at the top generates more\nthan the cost of bandwidth even for very low value traffic like gaming.\n  This would be much higher value traffic well targeted for high paying\ngold merchant keywords and VPN hosts.  It could eventually be a valuable\nrevenue stream you wouldn't want to give away to some free site.\n\nI want to pre-announce some of the features in version 0.2 on the forum\nand try to get some anticipation going.  Even if hardly anyone else is\nposting, I have seen project forums where most of the posts are the\nauthor announcing what's going on with the latest changes.  Users can\nsee progress going on, see that it's improving and supported and not\nabandonware.  It's a little like a blog in that case, but easier for\nusers to use it as a searchable FAQ and better organized.  Whenever I\ngoogle search software questions, most of the hits are forum posts."]],"u":"https://mmalmi.github.io/satoshi/#email-92","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Forum"},{"f":"mmalmi@cc.hut.fi","d":1258507899,"b":[["t","I installed both phpBB3 and Simple Machines Forum, which are kind of\nthe market leaders among the open source forums. SMF's interface looks\nbetter on the first look, especially the admin panel. What do you\nthink, shall we go with SMF or phpBB3?"]],"u":"https://mmalmi.github.io/satoshi/#email-93","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Forum"},{"f":"Satoshi Nakamoto","d":1258522342,"b":[["t","That's great, this is going to fun!  I'll research what people say about\nthe two."],["q","I installed both phpBB3 and Simple Machines Forum, which are kind of\nthe market leaders among the open source forums. SMF's interface looks\nbetter on the first look, especially the admin panel. What do you\nthink, shall we go with SMF or phpBB3?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-97","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Forum"}],"id":"x26"},{"k":"x","s":"martti-malmi","t":"Linux build ready for testing (attached)","u":"https://mmalmi.github.io/satoshi/#email-62","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257657793,"b":[["t","bitcoin-linux-0.1.6-test1.tar.bz2 attached"]],"u":"https://mmalmi.github.io/satoshi/#email-62","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>, Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x27"},{"k":"x","s":"martti-malmi","t":"Linux build ready for testing","u":"https://mmalmi.github.io/satoshi/#email-63","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257659531,"b":[["t","The Linux build is ready for testing on the network.  It seems solid.  I\nsent the executable as an attachment in the previous e-mail, but if the\nmail server didn't let it through (it's 12MB), you can download it here:\nhttp://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html"]],"u":"https://mmalmi.github.io/satoshi/#email-63","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>, Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1257673844,"b":[["t","That's great! A major waypoint reached. Seems to work fine here."],["q","The Linux build is ready for testing on the network.  It seems solid.\nI sent the executable as an attachment in the previous e-mail, but if\nthe mail server didn't let it through (it's 12MB), you can download it\nhere:\nhttp://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html"]],"u":"https://mmalmi.github.io/satoshi/#email-64","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Linux build ready for testing"},{"f":"Satoshi Nakamoto","d":1257701979,"b":[["t","In the debug.log, it requests the block list, receives the block list,\nthen begins uploading the list of blocks requested.  It doesn't receive\nthe blocks, but it didn't run long enough for me to be sure it would\nhave had time yet.  Everything else looks normal.\n\nHow long did you run it?  It could take a few minutes to start\ndownloading the blocks.  Especially if you're on a cable modem, the\nuplink can be much lower bandwidth so it would take some time to upload\nthe block request list.\n\nIf you run it again and it still doesn't download blocks, keep it\nrunning for several hours at least and then send me the debug.log.  That\nshould give it time for my node to connect to you and I could see what\nit says on my side and correlate it with your debug.log.\n\nYou're right about the minimize on close option, there's no reason that\ncan't be separate.  Martti originally had it separate and I made it a\nsub-option, my bad.  I'll change it back."],["q","That is what I meant. The blocks displayed in the status bar did not\nincrease at all while i ran the program. I have attached my debug.log.\n\nA good way for you to test the tray icon in Gnome is to remove the\nnotification area and then add it back. If the icon is still displayed\nafter adding the notification back, then it's working correctly.\n\nI generally set application preferences to not minimize to the tray, but\nto close to the tray. And I keep the application minimized. That way I\ndon't accidentally close the program and still have the convenience of\nbeing able to open the application from the tray. (I don't display open\nwindows in the 'task bar' but I have an icon that if clicked displays\nopen windows as sub-menu items.) Then if the tray icon disappears, I go\ninto the settings disable and re-enable the tray icon setting to get it\nto reappear. That's currently not possible with the bitcoin preferences\nbecause the close to tray check mark can not be enabled without the\nminimize to tray check box being enabled.\n\nOn Sun, Nov 8, 2009 at 9:08 AM, Satoshi Nakamoto <satoshin@gmx.com\n<mailto:satoshin@gmx.com>> wrote:\n\n    Liberty Standard wrote:\n\n        I downloaded it and it runs. It and it is using plenty of CPU,\n        so I think it's working properly. It has not downloaded\n        previously generated blocks. Is that a bug or a new feature?\n\n    If you mean the blocks count in the status bar isn't working its way\n    up to around 26600, then that's a bug, you should send me your\n    debug.log. (which is at ~/.bitcoin/debug.log)\n\n        The system tray in Gnome is not very reliable. Sometimes an icon\n        will disappear leaving no way to get back to the program. I have\n        verified that this can happen with bitcoin. It would be nice if\n        starting bitcoin while it's already running would just bring up\n        the GUI of the already running bitcoin process.\n\n    We haven't figured out how to find and bring up the existing running\n    program yet on Linux like it does on Windows.  Given what you say, I\n    should at least turn off the minimize to tray option initially by\n    default.","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-66","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux build ready for testing"},{"f":"Satoshi Nakamoto","d":1257729839,"b":[["q","Ok, blocks have now started to increase. It definitely takes longer for\nthem to start increasing than with the Windows version. Also, I think\nthey might be increasing at a slower rate than in with the Windows\nversion. Is there perhaps debugging enabled in the Linux build that you\nsent me? Block are increasing at about 15 blocks per second (eyeball\nestimate while looking at a clock). I didn't time how fast they\nincreased in the Windows version, but it seems like it was much faster.","Liberty Standard wrote:"],["t","About how long did it take to start?  It could be the node that you\nhappened to request from is slow.  The slow start is consistent with the\nslow download speed.\n\nI'd like to look at your current debug.log file and try to understand\nwhat's going.  It might just be a really slow connection on the other\nside, or maybe something's wrong and failed and retried.  Taking too\nlong could confuse other users.\n\nMartti, how long did it take to start downloading blocks when you ran\nit, and how fast did it download?"],["q","    When I launch bitcoin and the bitcoin port is not available, I get\n    the following messages to the command line. I don't get those\n    messages when the bitcoin port is available. Would it be possible\n    for bitcoin to pick another port if the default port is taken? The\n    same think sometimes happens to me with my BitTorrent client. When I\n    restart it, my previously open port is closed. All I have to do is\n    change the port and it starts working again.\n\n    /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64\n    Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so\n    /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF\n    class: ELFCLASS64\n    Failed to load module:\n    /usr/lib/gio/modules/libgioremote-volume-monitor.so\n    /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64\n    Failed to load module: /usr/lib/gio/modules/libgiogconf.so"],["t","It already uses SO_REUSEADDR so it can bind to the port if it's in\nTIME_WAIT state after being closed.  The only time it should fail to\nbind is when the program really is already running.  It's important that\ntwo copies of Bitcoin not run on the same machine at once because they\nwould be modifying the database at the same time.  There is never any\nneed to run two on one machine as coin generation will now use multiple\nprocessors automatically.\n\nI'm not sure what those lib errors are, I'll do some searching."]],"u":"https://mmalmi.github.io/satoshi/#email-68","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux build ready for testing"},{"f":"Satoshi Nakamoto","d":1257745379,"b":[["t","Thanks for that, I see what happened.  Because the first one was slow,\nit ended up requesting the blocks from everybody else, which only bogged\neverything down.  I can fix this, I just need to think a while about the\nright way.\n\nThere's no risk in shutting down while there are unconfirmed.  When you\nmake a transaction or new block, it immediately broadcasts it to the\nnetwork.  After that, the increasing #/confirmed number is just\nmonitoring the outcome.  There's nothing your node does during that time\nto promote the acceptance.\n\nNow that I think about it, when you close Bitcoin, it closes the main\nwindow immediately but in the background continues running to finish an\norderly flush and shutdown of the database.  Before I implemented that,\nit was annoying having a dead hung unresponsive window hanging around.\nUntil it finishes the orderly shutdown in the background, the port would\nbe locked, and this is an important protection to make sure another copy\ncan't touch the database until it's done.  I haven't seen the shutdown\ntake more than a few seconds.\n\nIn Wine, there's no way for the Windows version to do SO_REUSEADDR, so\nthat would add 60 seconds (on my system) of TIME_WAIT after the port is\nclosed.\n\nIf you need to transfer between two copies, you could send it to the\nother's bitcoin address.  The receiving copy doesn't have to be online\nat the time.\n\nThe command line to use a different data directory is\nbitcoin -datadir=<directory>\n\nFor example, on Linux, the default directory is (don't use ~)\nbitcoin -datadir=/home/yourusername/.bitcoin\n\nYou shouldn't normally have any need to use this switch.  It still won't\nlet you run two instances at once."],["q","On Mon, Nov 9, 2009 at 3:23 AM, Satoshi Nakamoto <satoshin@gmx.com\n<mailto:satoshin@gmx.com>> wrote:\n\n    Liberty Standard wrote:\n\n        Ok, blocks have now started to increase. It definitely takes\n        longer for them to start increasing than with the Windows\n        version. Also, I think they might be increasing at a slower rate\n        than in with the Windows version. Is there perhaps debugging\n        enabled in the Linux build that you sent me? Block are\n        increasing at about 15 blocks per second (eyeball estimate while\n        looking at a clock). I didn't time how fast they increased in\n        the Windows version, but it seems like it was much faster.\n\n    About how long did it take to start?  It could be the node that you\n    happened to request from is slow.  The slow start is consistent with\n    the slow download speed.\n\nIt took about a half hour for it to start incrementing quickly.\nInterestingly, the CPU usage increased before it started to increment\nsteadily and then lowered when it started to increment steadily.\nAlthough this time the block incremented to 2 within the first few\nminutes. I have not yet generated any bitcoins. I'll wait for as long as\nI have patience to generate a bitcoin, but if none are created by the\ntime I lose patience, I'm going to move back to the wine version.\n\n    I'd like to look at your current debug.log file and try to\n    understand what's going.  It might just be a really slow connection\n    on the other side, or maybe something's wrong and failed and\n    retried.  Taking too long could confuse other users.\n\nI've included my current debug.log.\n\n    Martti, how long did it take to start downloading blocks when you\n    ran it, and how fast did it download?\n\n           When I launch bitcoin and the bitcoin port is not available,\n        I get\n           the following messages to the command line. I don't get those\n           messages when the bitcoin port is available. Would it be possible\n           for bitcoin to pick another port if the default port is\n        taken? The\n           same think sometimes happens to me with my BitTorrent client.\n        When I\n           restart it, my previously open port is closed. All I have to\n        do is\n           change the port and it starts working again.\n\n           /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64\n           Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so\n           /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF\n           class: ELFCLASS64\n           Failed to load module:\n           /usr/lib/gio/modules/libgioremote-volume-monitor.so\n           /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64\n           Failed to load module: /usr/lib/gio/modules/libgiogconf.so\n\n    It already uses SO_REUSEADDR so it can bind to the port if it's in\n    TIME_WAIT state after being closed.  The only time it should fail to\n    bind is when the program really is already running.  It's important\n    that two copies of Bitcoin not run on the same machine at once\n    because they would be modifying the database at the same time.\n     There is never any need to run two on one machine as coin\n    generation will now use multiple processors automatically.\n\nThe reason I run two instances at the same time is to transfer bitcoins\nfrom one bitcoin instance to another. They of course would need to be\naccessing different data directories. Perhaps that could be specified as\na command line argument. I currently have to move my bitcoin data folder\nto a virtual machine to do this. Shutting down bitcoin and restarting it\nwith a different data directory is a poor solution because shutting down\nbitcoin while there are unconfirmed bitcoins risks losing those bitcoins.\n\nBitcoin was definitely not running when i get the busy port error. The\nprocess closes quickly and reliably from my experience, but it takes\nanywhere from 30 seconds to 3 minutes (estimation from memory) for the\nport to become available again. It occurred while switching from bitcoin\n0.1.5 in Wine to the Linux build and again while switching from the\nLinux build to bitcoin 0.1.5 in Wine.\n\nAnother thing that I noticed is that the about dialog text does not fit\ncorrectly and it cannot be resized.\n\n    I'm not sure what those lib errors are, I'll do some searching.","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-69","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux build ready for testing"},{"f":"mmalmi@cc.hut.fi","d":1257755528,"b":[["q","Martti, how long did it take to start downloading blocks when you ran\nit, and how fast did it download?"],["t","Started very quickly when I got connected and downloaded quicker than\nmy Windows PC, which has a slower CPU.\n\nI'll have to focus on a school project (coincidentally C++ coding) for\nabout a month now, so I don't have that much time for active\ndeveloping until December. Let's keep contact anyway."],["q","Liberty Standard wrote:\n> Ok, blocks have now started to increase. It definitely takes longer\n>  for them to start increasing than with the Windows version. Also,\n> I  think they might be increasing at a slower rate than in with the\n>  Windows version. Is there perhaps debugging enabled in the Linux\n> build that you sent me? Block are increasing at about 15 blocks per\n>  second (eyeball estimate while looking at a clock). I didn't time\n> how fast they increased in the Windows version, but it seems like\n> it was much faster.\n\nAbout how long did it take to start?  It could be the node that you\nhappened to request from is slow.  The slow start is consistent with\nthe slow download speed.\n\nI'd like to look at your current debug.log file and try to understand\nwhat's going.  It might just be a really slow connection on the other\nside, or maybe something's wrong and failed and retried.  Taking too\nlong could confuse other users.\n\nMartti, how long did it take to start downloading blocks when you ran\nit, and how fast did it download?\n\n>    When I launch bitcoin and the bitcoin port is not available, I get\n>    the following messages to the command line. I don't get those\n>    messages when the bitcoin port is available. Would it be possible\n>    for bitcoin to pick another port if the default port is taken? The\n>    same think sometimes happens to me with my BitTorrent client. When I\n>    restart it, my previously open port is closed. All I have to do is\n>    change the port and it starts working again.\n>\n>    /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64\n>    Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so\n>    /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF\n>    class: ELFCLASS64\n>    Failed to load module:\n>    /usr/lib/gio/modules/libgioremote-volume-monitor.so\n>    /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64\n>    Failed to load module: /usr/lib/gio/modules/libgiogconf.so\n\nIt already uses SO_REUSEADDR so it can bind to the port if it's in\nTIME_WAIT state after being closed.  The only time it should fail to\nbind is when the program really is already running.  It's important\nthat two copies of Bitcoin not run on the same machine at once because\nthey would be modifying the database at the same time.  There is never\nany need to run two on one machine as coin generation will now use\nmultiple processors automatically.\n\nI'm not sure what those lib errors are, I'll do some searching."]],"u":"https://mmalmi.github.io/satoshi/#email-70","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Linux build ready for testing"},{"f":"Satoshi Nakamoto","d":1257795053,"b":[["t","You really don't want to keep running in Wine, you're getting database\nerrors (db.log).  You probably developed these rituals of transferring\nto a fresh install to cope with database corruption.  If there is a way\nto lose unconfirmed blocks, it would have to be the database errors.\nAny problems you find in the Linux build can be fixed.  The Wine\nincompatibility deep inside Berkeley DB is unfixable.\n\nI think GCC 4.3.3 on the Linux build optimized the SHA-256 code better\nthan the old GCC 3.4.5 on Windows.  When I was looking for the best\nSHA-256 code, there was a lot of hand tuned highly optimized SHA1 code\navailable, but not so much for SHA-256 yet.  I should see if I can\nupgrade MinGW to 4.3.x to get them on a level playing field."],["q","Everyone that contributed to making this Linux build really did a great\njob! Thanks for the hard work. It has started maturing some bitcoins, so\nI'm going to continue to run the Linux client for the time being until I\ndecide whether it's at least as good or better at generating coins than\nthe Windows version running in Wine.\n\nOn Mon, Nov 9, 2009 at 8:59 AM, Liberty Standard\n<newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:\n\n    Another instance when I would like to run multiple instances is when\n    I upgrade bitcoin. I will uncheck the generate coin check box in the\n    outdated bitcoin, launch and start generating coins in the new\n    bitcoin using a separate data directory, then when the old\n    application's coins have matured I will send them to the new\n    application and then close the old application. I prefer do do clean\n    installs rather than upgrading while maintaining old data.\n\n    On Mon, Nov 9, 2009 at 7:42 AM, Satoshi Nakamoto <satoshin@gmx.com\n    <mailto:satoshin@gmx.com>> wrote:\n\n        Thanks for that, I see what happened.  Because the first one was\n        slow, it ended up requesting the blocks from everybody else,\n        which only bogged everything down.  I can fix this, I just need\n        to think a while about the right way.\n\n        There's no risk in shutting down while there are unconfirmed.\n         When you make a transaction or new block, it immediately\n        broadcasts it to the network.  After that, the increasing\n        #/confirmed number is just monitoring the outcome.  There's\n        nothing your node does during that time to promote the acceptance.","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-71","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux build ready for testing"},{"f":"Satoshi Nakamoto","d":1257795671,"b":[["t","You got a lot done with the Linux build, autostart, minimize to tray,\nsetup and everything, it's really appreciated.  Good luck on your C++\nproject."],["q","I'll have to focus on a school project (coincidentally C++ coding) for\nabout a month now, so I don't have that much time for active developing\nuntil December. Let's keep contact anyway.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-72","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux build ready for testing"}],"id":"x28"},{"k":"x","s":"martti-malmi","t":"Re: Linux - dead sockets problem","u":"https://mmalmi.github.io/satoshi/#email-73","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257871564,"b":[["t","I see what happened.  All your sockets went dead somehow.  You had no\ncommunication with the network, but because you had 8 zombie\nconnections, it thought it was still online and kept generating blocks.\n  You can tell this is happening when your blocks are numbered\nsequentially, without other people's blocks interspersed, like:\n2/unconfirmed\n3/unconfirmed\n4/unconfirmed\n5/unconfirmed\n6 blocks\n7 blocks\n\nIt's implausible that you would be the only one to find blocks for 6\nblocks in a row like that.\n\nWhen you exited and restarted, it connected and downloaded 45 blocks\nthat the network found in your absence.  Since your blocks were not\nbroadcast to the network immediately, the network went on without them.\n\nIt sounds like you had exactly the same problem on Wine.  There's\nclearly something about socket handling on Linux that's effecting it\neither way.\n\nI'll start researching this.  Ultimately if I can't find the root of the\nproblem, I'll have to make some kind of mechanism to watch for an\nabsence of messages and disconnect.  The only workaround for you right\nnow would be to exit and restart more often.\n\nAll but one of your node connections went dead at the same time, one\nshortly after.  IRC was still working, so it wasn't that you were\noffline from the internet.\n\nI wonder if the status of blocks should say \"#/unconfirmed\" all the way\nup to maturity (119/unconfirmed then 120 blocks) instead.  The meaning\nof the number isn't as strong for blocks as for transactions.\n\nI think it would be an improvement not to count one's own blocks as\nconfirmations.  A drawback would be that the status numbers shown by\ndifferent nodes would not match.  The status number would no longer be\ncoordinated with the maturity countdown on blocks either.  A lighter\noption would be a special case only if all confirmations are your own."],["q","I just lost 6 sets of maturing coins! I had 10 sets of bitcoins\nmaturing. The last set was generated at about 0:22. It got to\n2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was\ngenerated at 0:22 was still only at 2/unconfirmed. Since you had told me\nthat I wasn't going to lose coins, I shutdown and restarted bitcoin. On\nthe bright side, it shutdown and started up very smoothly. But\nunfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four\nsets were still unconfirmed, but two sets were confirmed. And there's no\ntrace of them now. Perhaps now that you have the 'Show Generated Coins'\noption available, you can put back in failed bitcoin generations. I just\ndon't like that those bitcoins just disappeared into thin air. I'm still\nrunning the Linux build at the moment, but the Wine version is suddenly\nlooking much more attractive now that 6 out of the 10 sets of bitcoins I\ngenerated in the past 24 hours just vanished. I've included my debug.log.\n\nOn Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard\n<newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:\n\n    The Linux build has generated a decent amount of bitcoins within the\n    past 20 hours and I trust what you're telling me about database\n    errors, so all signs point toward me running the Linux build from\n    now on. The only half annoying thing about the Linux build is that\n    my computer's fan has gone from 50% to 100%. :-P I know I can limit\n    the CPU, so if it gets on my nerves too much and if I can live with\n    less bitcoins being generated, perhaps I'll do that. Or maybe I just\n    need to start listening to more music...","Liberty Standard wrote:"],["t","..."],["q","                   There's no risk in shutting down while there are\n            unconfirmed.\n                    When you make a transaction or new block, it immediately\n                   broadcasts it to the network.  After that, the increasing\n                   #/confirmed number is just monitoring the outcome.\n             There's\n                   nothing your node does during that time to promote\n            the acceptance."]],"u":"https://mmalmi.github.io/satoshi/#email-73","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x29"},{"k":"x","s":"martti-malmi","t":"Re: Linux - linux-0.1.6-test2","u":"https://mmalmi.github.io/satoshi/#email-74","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257899959,"b":[["t","I fixed a few places I found where it was possible for a socket to get\nan error and not get disconnected.  If your connections go dead again,\nit should disconnect and reconnect them.  I also implemented an\ninactivity timeout as a fallback.\n\nThis also includes a partial fix for the slow initial block download.\n\nYou should run with the \"-debug\" switch to get some additional debug.log\ninformation I added that'll help if there are more problems.\n\nlinux-0.1.6-test2.tar.bz2  12,134,012 bytes\nDownload:\nhttp://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html"],["q","I see what happened.  All your sockets went dead somehow.  You had no\ncommunication with the network, but because you had 8 zombie\nconnections, it thought it was still online and kept generating blocks.\n You can tell this is happening when your blocks are numbered\nsequentially, without other people's blocks interspersed, like:\n2/unconfirmed\n3/unconfirmed\n4/unconfirmed\n5/unconfirmed\n6 blocks\n7 blocks\n\nIt's implausible that you would be the only one to find blocks for 6\nblocks in a row like that.\n\nWhen you exited and restarted, it connected and downloaded 45 blocks\nthat the network found in your absence.  Since your blocks were not\nbroadcast to the network immediately, the network went on without them.\n\nIt sounds like you had exactly the same problem on Wine.  There's\nclearly something about socket handling on Linux that's effecting it\neither way.\n\nI'll start researching this.  Ultimately if I can't find the root of the\nproblem, I'll have to make some kind of mechanism to watch for an\nabsence of messages and disconnect.  The only workaround for you right\nnow would be to exit and restart more often.\n\nAll but one of your node connections went dead at the same time, one\nshortly after.  IRC was still working, so it wasn't that you were\noffline from the internet.\n\nI wonder if the status of blocks should say \"#/unconfirmed\" all the way\nup to maturity (119/unconfirmed then 120 blocks) instead.  The meaning\nof the number isn't as strong for blocks as for transactions.\n\nI think it would be an improvement not to count one's own blocks as\nconfirmations.  A drawback would be that the status numbers shown by\ndifferent nodes would not match.  The status number would no longer be\ncoordinated with the maturity countdown on blocks either.  A lighter\noption would be a special case only if all confirmations are your own.\n\nLiberty Standard wrote:\n> I just lost 6 sets of maturing coins! I had 10 sets of bitcoins\n> maturing. The last set was generated at about 0:22. It got to\n> 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which\n> was generated at 0:22 was still only at 2/unconfirmed. Since you had\n> told me that I wasn't going to lose coins, I shutdown and restarted\n> bitcoin. On the bright side, it shutdown and started up very smoothly.\n> But unfortunately, when the blocks updated, I lost 6 sets of bitcoins.\n> Four sets were still unconfirmed, but two sets were confirmed. And\n> there's no trace of them now. Perhaps now that you have the 'Show\n> Generated Coins' option available, you can put back in failed bitcoin\n> generations. I just don't like that those bitcoins just disappeared\n> into thin air. I'm still running the Linux build at the moment, but\n> the Wine version is suddenly looking much more attractive now that 6\n> out of the 10 sets of bitcoins I generated in the past 24 hours just\n> vanished. I've included my debug.log.\n>\n>\n> On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard\n> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>>\n> wrote:\n>\n>     The Linux build has generated a decent amount of bitcoins within the\n>     past 20 hours and I trust what you're telling me about database\n>     errors, so all signs point toward me running the Linux build from\n>     now on. The only half annoying thing about the Linux build is that\n>     my computer's fan has gone from 50% to 100%. :-P I know I can limit\n>     the CPU, so if it gets on my nerves too much and if I can live with\n>     less bitcoins being generated, perhaps I'll do that. Or maybe I just\n>     need to start listening to more music...\n>\n...\n>\n>                    There's no risk in shutting down while there are\n>             unconfirmed.\n>                     When you make a transaction or new block, it\n> immediately\n>                    broadcasts it to the network.  After that, the\n> increasing\n>                    #/confirmed number is just monitoring the outcome.\n>              There's\n>                    nothing your node does during that time to promote\n>             the acceptance.\n>\n>\n>","Satoshi Nakamoto wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-74","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x30"},{"k":"x","s":"martti-malmi","t":"Re: Linux - linux-0.1.6-test2 attachment","u":"https://mmalmi.github.io/satoshi/#email-75","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1257900066,"b":[["t","linux-0.1.6-test2.tar.bz2 attached"]],"u":"https://mmalmi.github.io/satoshi/#email-75","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x31"},{"k":"x","s":"martti-malmi","t":"Linux - linux-0.1.6-test3","u":"https://mmalmi.github.io/satoshi/#email-76","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258004166,"b":[["t","Right now (04:50 GMT) my node is connecting to yours and getting zombie\nconnections each time.  The socket isn't returning an error, just zombie\nwithout notice.  If you're running the linux build right now, it would\nbe interesting to see what the log says on your side.\n\ntest3:\n\nI've added specific code to detect zombie sockets.  It'll detect if the\nsocket hasn't sent or received any data within 60 seconds of connecting,\nand detect if data is queued to send and hasn't sent for 3 minutes.\n\nI think I may have weakened the reconnect speed in test2.  In test3 I'm\nmaking it more determined to reconnect quickly.\n\nI added checking to track whether other nodes received your generated\nblocks.  If none did, it'll warn you in the description:\n\"Generated - Warning: This block was not received by any other nodes and\nwill probably not be accepted!\"\n\nThe status can go to \"#/offline?\" for blocks or transactions you create\nif they don't get out to any other nodes.\n\nWith all this, it should be impossible not to notice as soon as it\nscrews up.  It should hopefully disconnect all the zombie sockets.\nAfter that, whether it's able to make some good connections, or sockets\nis completely hosed and it stays at 0 connections, I don't know.\n\nIf this doesn't work, I guess I'll look at the sourcecode of some other\nP2P apps like BitTorrent and see how they deal with this stuff.  Maybe\nthere's some magic flag or procedure to bash the sockets system back to\nlife.\n\nFile linux-0.1.6-test3.tar.bz2 attached in the next message."],["q","On Wed, Nov 11, 2009 at 8:08 AM, Liberty Standard\n<newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:\n\n    My network connection is direct to my computer. My ISP requires that\n    I run VPN to connect to the Internet. I then have a second NIC that\n    shares my Internet with other devices. My IP address while using my\n    computer is my actual IP address, but the devices connected through\n    my second NIC use NAT. When I connect through a virtual machine,\n    that also uses NAT. All this requires very little configuration.\n    NetworkManager in Ubuntu has an option to share my Internet\n    connection through the second NIC and VirtualBox has the option to\n    use NAT.\n\n    I lost a couple packs of bitcoins again, so that problem is not yet\n    fixed. It's a bit more bearable now that I have an idea of what is\n    going on. I figure for now I'll just restart bitcoin whenever I see\n    a pack of bitcoins starting to mature. I may go back and forth a bit\n    between Linux and Wine, but I'll definitely test every new version\n    that comes out. At the moment I'm still running the Linux build.\n\n    On Wed, Nov 11, 2009 at 7:49 AM, Satoshi Nakamoto <satoshin@gmx.com\n    <mailto:satoshin@gmx.com>> wrote:\n\n        Thanks.  The log didn't stop on anything special, just simple\n        message passing.  Chances are it's UI related.  Most of the\n        initial bugs were all UI.\n\n        What brand/model of firewall do you have?  It's possible for\n        BitTorrent to overwhelm the number of connections some models\n        can handle.  Most are underpowered and flaky under load.\n\n        NewLibertyStandard wrote:\n\n            I have been getting your attachments just fine. I just\n            thought I'd spare Martti the large attachment.\n\n            I am not able to reproduce the bug. I don't know whether the\n            paste, the blocks finishing, a combination of the two or\n            something else entirely caused the fault.\n\n        ...\n\n                    But after they started\n                   downloading, I took a look a look at my BitTorrent\n            client, and\n                   sure enough, I had forgotten about a torrent and my\n            upload was\n                   quite high, at the limit I had set for it.","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-76","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x32"},{"k":"x","s":"martti-malmi","t":"linux-0.1.6-test3.tar.bz2 attached","u":"https://mmalmi.github.io/satoshi/#email-77","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258004278,"b":[["t","File linux-0.1.6-test3.tar.bz2 attached\n\nlinux-0.1.6-test3.tar.bz2   12,143,473 bytes"]],"u":"https://mmalmi.github.io/satoshi/#email-77","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x33"},{"k":"x","s":"martti-malmi","t":"linux-0.1.6-test5 fix for zombie sockets","u":"https://mmalmi.github.io/satoshi/#email-78","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258069184,"b":[["t","test 5:\n\nI added MSG_DONTWAIT to the send and recv calls in case they forgot the\nsocket is non-blocking.  If that doesn't work, there's now the catch-all\nsolution: another thread monitors the send/recv thread and terminates\nand restarts it if it stops.  It prints \"*** Restarting\nThreadSocketHandler ***\" in debug.log, and an error message displays on\nthe status bar for a while.\n\nBefore terminating, it tries closing the socket that's hung.  If that\nworks, it doesn't have to resort to terminating.\n\nI ran a test where it terminated the thread about 1000 times without\ntrouble, so it should be safe.  The terminate on linux is\npthread_cancel, which throws it into C++'s exception handler.\n\nThe thread calls we were using didn't have terminate, so I created our\nown wrappers in util.h to use CreateThread on windows and pthread_create\non linux, instead of:\n   _beginthread is windows only and lacks terminate\n   boost::thread is really attractive, but lacks terminate\n   wxThread requires you to create a class for every function you might\ncall (yuck)\n\nFile attached in the next e-mail"]],"u":"https://mmalmi.github.io/satoshi/#email-78","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x34"},{"k":"x","s":"martti-malmi","t":"linux-0.1.6-test5.tar.bz2 attached","u":"https://mmalmi.github.io/satoshi/#email-79","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258069349,"b":[["t","12,033,918 linux-0.1.6-test5.tar.bz2"]],"u":"https://mmalmi.github.io/satoshi/#email-79","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x35"},{"k":"x","s":"martti-malmi","t":"Zetaboards forum","u":"https://mmalmi.github.io/satoshi/#email-80","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258177582,"b":[["t","I created a forum on Zetaboards, InvisionFree's new site that they're\nmigrating to.\n\nhttp://s1.zetaboards.com/Bitcoin/index/\n\nI made an admin account you can use to upgrade your own account to admin:\nu: admin\npw: B98VzUUA\n\nBTW, the admin pages have a huge blank space at the top, you have to\nscroll down.\n\nIt doesn't support SSL, but none of them do.  I replaced the ugly\ndefault orange and blue theme with the Frostee theme, which was the only\ndecent looking theme I could find after extensive searching.  Searching\nfor themes is futile, there are thousands of rubbish themes.  It turns\nout the solution is to look at button sets instead\n(http://resources.zetaboards.com/forum/1000328/)\n\nI only created two subforums to begin with.  I'll create new ones as the\nneed arises.  I like to start with a flat namespace until there's enough\nitems to justify subsections.  Technical Support makes sense as a\nseparate section to get that stuff out of the main spotlight so our\ndirty laundry isn't in everyone's face, and to make people feel more\nfree to report bugs there.  Mostly only devs and people checking on a\nbug need read the Technical Support section."]],"u":"https://mmalmi.github.io/satoshi/#email-80","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x36"},{"k":"x","s":"martti-malmi","t":"Linux update","u":"https://mmalmi.github.io/satoshi/#email-81","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258299629,"b":[["t","linux-0.1.6-test5 solved Liberty's zombie socket problem.  The\nMSG_DONTWAIT fixed the root cause, it's not having to terminate and\nrestart the thread.  The sockets are marked non-blocking already, so I\ndon't understand why.  Maybe it forgot.  I suppose if a socket fails and\nthe OS closes it then there's nothing left to remember it was\nnon-blocking, but then accessing a closed handle should return\nimmediately with an error.  There's no MSG_DONTWAIT on Windows, marking\nthe socket as nonblocking is the only way, so if anyone runs the Windows\nversion in Wine it will have to rely on terminating the thread.\n\nThe only problem now is the DB exceptions he's getting.\n************************\nEXCEPTION: 11DbException\nDb::open: Bad file descriptor\nbitcoin in ThreadMessageHandler()\n************************\nEXCEPTION: 11DbException\nDb::close: Bad file descriptor\nbitcoin in ThreadMessageHandler()\n\nI had expected those to be a Wine problem, but he's getting them on\nLinux just the same.  He tried moving the datadir to a different drive,\nno help.  I've never gotten them.  I'm running a stress test that\ncontinuously generates a lot of activity and DB access and never got it.\n\nHe has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the\ndifference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had\na DB exception? (see db.log also)  Now that the zombie problem is fixed\nin test5, could you start running it on your Linux machine?  We could\nuse a 3rd vote to get a better idea of what we're dealing with here.\nThe DB exception is uncaught, so it'll stop the program if you get it.\n\nBTW, zetaboards insists on displaying \"Member #\", so you better sign up\nsoon and grab a good account number."]],"u":"https://mmalmi.github.io/satoshi/#email-81","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258307735,"b":[["t","The program terminated a few times with the same error in debug.log\nclose: Bad file descriptor\nblkindex.dat: Bad file descriptor\n\nI'm running a 64-bit Ubuntu distribution."],["q","The only problem now is the DB exceptions he's getting.\n************************\nEXCEPTION: 11DbException\nDb::open: Bad file descriptor\nbitcoin in ThreadMessageHandler()\n************************\nEXCEPTION: 11DbException\nDb::close: Bad file descriptor\nbitcoin in ThreadMessageHandler()\n\nI had expected those to be a Wine problem, but he's getting them on\nLinux just the same.  He tried moving the datadir to a different drive,\nno help.  I've never gotten them.  I'm running a stress test that\ncontinuously generates a lot of activity and DB access and never got it.\n\nHe has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the\ndifference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had\na DB exception? (see db.log also)  Now that the zombie problem is fixed\nin test5, could you start running it on your Linux machine?  We could\nuse a 3rd vote to get a better idea of what we're dealing with here.\nThe DB exception is uncaught, so it'll stop the program if you get it.\n\nBTW, zetaboards insists on displaying \"Member #\", so you better sign up\nsoon and grab a good account number."]],"u":"https://mmalmi.github.io/satoshi/#email-82","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Linux update"},{"f":"Satoshi Nakamoto","d":1258312542,"b":[["t","I'd better install 64-bit then.  I imagine it's something about the\n32-bit version of Berkeley DB on 64-bit Linux.\n\nBTW, in things like the feature list credits, do you want me to refer to\nyou as sirius-m or Martti Malmi?  I think most projects go by real names\nfor consistency."],["q","The program terminated a few times with the same error in debug.log from\nDb::close. Db.log has:\n\nclose: Bad file descriptor\nblkindex.dat: Bad file descriptor\n\nI'm running a 64-bit Ubuntu distribution.\n\n> The only problem now is the DB exceptions he's getting.\n> ************************\n> EXCEPTION: 11DbException\n> Db::open: Bad file descriptor\n> bitcoin in ThreadMessageHandler()\n> ************************\n> EXCEPTION: 11DbException\n> Db::close: Bad file descriptor\n> bitcoin in ThreadMessageHandler()\n>\n> I had expected those to be a Wine problem, but he's getting them on\n> Linux just the same.  He tried moving the datadir to a different drive,\n> no help.  I've never gotten them.  I'm running a stress test that\n> continuously generates a lot of activity and DB access and never got it.\n>\n> He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the\n> difference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had\n> a DB exception? (see db.log also)  Now that the zombie problem is fixed\n> in test5, could you start running it on your Linux machine?  We could\n> use a 3rd vote to get a better idea of what we're dealing with here.\n> The DB exception is uncaught, so it'll stop the program if you get it.\n>\n> BTW, zetaboards insists on displaying \"Member #\", so you better sign up\n> soon and grab a good account number.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-83","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux update"},{"f":"mmalmi@cc.hut.fi","d":1258315550,"b":[["t","Perhaps the real name is better.\n\nAnother name question: I've been thinking of a name for the exchange\nservice, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop\n(bitcoinshop.com). Which one do you find better?"],["q","I'd better install 64-bit then.  I imagine it's something about the\n32-bit version of Berkeley DB on 64-bit Linux.\n\nBTW, in things like the feature list credits, do you want me to refer\nto you as sirius-m or Martti Malmi?  I think most projects go by real\nnames for consistency.\n\nmmalmi@cc.hut.fi wrote:\n> The program terminated a few times with the same error in debug.log\n>  from Db::close. Db.log has:\n>\n> close: Bad file descriptor\n> blkindex.dat: Bad file descriptor\n>\n> I'm running a 64-bit Ubuntu distribution.\n>\n>> The only problem now is the DB exceptions he's getting.\n>> ************************\n>> EXCEPTION: 11DbException\n>> Db::open: Bad file descriptor\n>> bitcoin in ThreadMessageHandler()\n>> ************************\n>> EXCEPTION: 11DbException\n>> Db::close: Bad file descriptor\n>> bitcoin in ThreadMessageHandler()\n>>\n>> I had expected those to be a Wine problem, but he's getting them on\n>> Linux just the same.  He tried moving the datadir to a different drive,\n>> no help.  I've never gotten them.  I'm running a stress test that\n>> continuously generates a lot of activity and DB access and never got it.\n>>\n>> He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the\n>> difference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had\n>> a DB exception? (see db.log also)  Now that the zombie problem is fixed\n>> in test5, could you start running it on your Linux machine?  We could\n>> use a 3rd vote to get a better idea of what we're dealing with here.\n>> The DB exception is uncaught, so it'll stop the program if you get it.\n>>\n>> BTW, zetaboards insists on displaying \"Member #\", so you better sign up\n>> soon and grab a good account number.\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-84","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Linux update"},{"f":"Satoshi Nakamoto","d":1258316726,"b":[["t","At first glance, bitcoinshop.com looks better.  bitcoinexchange.com\nmight be better than bitcoinx.com.\n\nBe careful where you search domain names, many will front-run you.  Even\nnetwork solutions, although they've said they won't if you use their\nwhois page not the homepage.  The only safe place is\nhttp://www.internic.com/whois.html"],["q","Perhaps the real name is better.\n\nAnother name question: I've been thinking of a name for the exchange\nservice, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop\n(bitcoinshop.com). Which one do you find better?\n\n> I'd better install 64-bit then.  I imagine it's something about the\n> 32-bit version of Berkeley DB on 64-bit Linux.\n>\n> BTW, in things like the feature list credits, do you want me to refer\n> to you as sirius-m or Martti Malmi?  I think most projects go by real\n> names for consistency.\n>\n> mmalmi@cc.hut.fi wrote:\n>> The program terminated a few times with the same error in debug.log\n>>  from Db::close. Db.log has:\n>>\n>> close: Bad file descriptor\n>> blkindex.dat: Bad file descriptor\n>>\n>> I'm running a 64-bit Ubuntu distribution.\n>>\n>>> The only problem now is the DB exceptions he's getting.\n>>> ************************\n>>> EXCEPTION: 11DbException\n>>> Db::open: Bad file descriptor\n>>> bitcoin in ThreadMessageHandler()\n>>> ************************\n>>> EXCEPTION: 11DbException\n>>> Db::close: Bad file descriptor\n>>> bitcoin in ThreadMessageHandler()\n>>>\n>>> I had expected those to be a Wine problem, but he's getting them on\n>>> Linux just the same.  He tried moving the datadir to a different drive,\n>>> no help.  I've never gotten them.  I'm running a stress test that\n>>> continuously generates a lot of activity and DB access and never got\n>>> it.\n>>>\n>>> He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the\n>>> difference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had\n>>> a DB exception? (see db.log also)  Now that the zombie problem is fixed\n>>> in test5, could you start running it on your Linux machine?  We could\n>>> use a 3rd vote to get a better idea of what we're dealing with here.\n>>> The DB exception is uncaught, so it'll stop the program if you get it.\n>>>\n>>> BTW, zetaboards insists on displaying \"Member #\", so you better sign up\n>>> soon and grab a good account number.\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-85","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Linux update"}],"id":"x37"},{"k":"x","s":"martti-malmi","t":"Re: Db::open/Db::close \"Bad file descriptor\" exception","u":"https://mmalmi.github.io/satoshi/#email-86","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258352452,"b":[["t","I have an idea for a workaround, but it depends on what files the errors\nare on.  If you've accumulated several errors in db.log, could you send\nit to me? (even if it's rather simple and boring)  Is the file listed\nalways blkindex.dat, or does it include addr.dat or wallet.dat too?"],["q","I moved the data directory back to my SSD card and started bitcoin test\n6. It encountered a segmentation fault today with Db::open in the log. I\nhad changed the settings to only use one processor/core while I watched\na 720p mkv movie. I noticed the segmentation fault after the film had ended.\n\nOn Sun, Nov 15, 2009 at 12:45 AM, Satoshi Nakamoto <satoshin@gmx.com\n<mailto:satoshin@gmx.com>> wrote:\n\n    Here's one where I linked Berkeley DB a different way.  It's worth a\n    try.  Otherwise identical to test5.\n\n    (Keep the datadir on the hard drive at least until you get it to\n    fail the same way there.  That has a fair chance of success.)","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-86","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258509024,"b":[["t","Here's the logs in case they're still useful."],["q","I have an idea for a workaround, but it depends on what files the\nerrors are on.  If you've accumulated several errors in db.log, could\nyou send it to me? (even if it's rather simple and boring)  Is the file\nlisted always blkindex.dat, or does it include addr.dat or wallet.dat\ntoo?"]],"u":"https://mmalmi.github.io/satoshi/#email-94","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1258521285,"b":[["t","Thanks.  The db::open/close errors confirm the pattern.\n\nMore interesting is the zombie sockets activity towards the end, and the\nsocket thread monitor tripped but didn't get it going again.  Was the\nmachine disconnected from the net?  MSG_DONTWAIT in test5 solved the\nzombie problem for Liberty.  What test version were you running?  (I\nshould print the test version in the log)"],["q","Here's the logs in case they're still useful.\n\n> I have an idea for a workaround, but it depends on what files the\n> errors are on.  If you've accumulated several errors in db.log, could\n> you send it to me? (even if it's rather simple and boring)  Is the file\n> listed always blkindex.dat, or does it include addr.dat or wallet.dat\n> too?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-96","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258572735,"b":[["t","I think it was test version 5, not completely sure though. I'm running\nthe Linux version on a laptop which I move between different locations\nand use the hibernate-feature instead of powering down."],["q","Thanks.  The db::open/close errors confirm the pattern.\n\nMore interesting is the zombie sockets activity towards the end, and\nthe socket thread monitor tripped but didn't get it going again.  Was\nthe machine disconnected from the net?  MSG_DONTWAIT in test5 solved\nthe zombie problem for Liberty.  What test version were you running?\n(I should print the test version in the log)\n\nmmalmi@cc.hut.fi wrote:\n> Here's the logs in case they're still useful.\n>\n>> I have an idea for a workaround, but it depends on what files the\n>> errors are on.  If you've accumulated several errors in db.log, could\n>> you send it to me? (even if it's rather simple and boring)  Is the file\n>> listed always blkindex.dat, or does it include addr.dat or wallet.dat\n>> too?\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-98","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x38"},{"k":"x","s":"martti-malmi","t":"linux-0.1.6-test7","u":"https://mmalmi.github.io/satoshi/#email-91","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258429286,"b":[["t","test 7:\n\nBackup your data directory before running this, just in case.\n\nWorkaround for the Db::open/Db::close \"Bad file descriptor\" exception.\nMight also make the initial block download faster.  The workaround is to\nopen the database handles and keep them open for the duration of the\nprogram, which is actually the more common thing to do anyway.  If we're\nnot closing and opening all the time, the error shouldn't get a chance\nto happen.\n\nThe one exception is wallet.dat, which I still close after writing is\nfinished so I can flush the transaction logs into the dat file, making\nthe dat file standalone.  That way if someone does a backup while\nBitcoin is running, they'll get a wallet.dat that is valid by itself\nwithout the database transaction logs.\n\nThis is a restructuring of the database handling, so we might find some\nnew deadlocks.  Usually if it deadlocks, either the UI will stop\nrepainting, or it'll stop using CPU even though it still says Generating."]],"u":"https://mmalmi.github.io/satoshi/#email-91","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1258518932,"b":[["t","Finally an easy one.  I see a way that could happen on a long operation\nsuch as the initial download.  The TryLock bug is unrelated to the db\nstuff.  Fix will be in test8.\n\nI've been able to reproduce the db::open/close exception 3 times now on\n32-bit linux by hitting it with a continuous flood of non-stop requests.\n  It looks like even periodically closing the wallet.dat database to\nflush it gets the db::close exceptions.  I'm disabling the wallet flush\nfeature on Linux.  On Linux we'll never close a database handle until\nwe're ready to exit.  So far with this disabled, no exceptions.\n\nI'm also implementing the orderly initial block download.  Instead of\nnaively requesting all the blocks at once, it'll request batches of 500\nat a time.  This way, it'll receive the blocks before the retry timeout,\nso it shouldn't go requesting it from other nodes unless it actually\ndoesn't receive them or it's too slow.  The change is in the requestee's\nside, so this functionality won't be visible until your initial block\ndownload is coming from a node that has the new version.\n\nI'm going to test this some more before sending test8."],["q","I started with a fresh data directory with test7. Blocks started to\ndownload much faster. It only took about 15 seconds where it took a few\nminutes previously with the Linux build. It crashed once while it was\ndownloading blocks with the following message in the terminal.\n\n../include/wx/thrimpl.cpp(50): assert \"m_internal\" failed in TryLock():\nwxMutex::TryLock(): not initialized [in child thread]\nTrace/breakpoint trap\n\nI've included my log file, but I forgot to back it up before restarting\nbitcoin, so I'm not sure at what point in the log file the crash occurred.\n\nFortunately I haven't encountered the segmentation fault yet. The\nfrequency of segmentation faults in the previous builds varied quite a\nbit, so I'll keep running it and let you know if i run into any problems.\n\nOn Tue, Nov 17, 2009 at 5:41 AM, Satoshi Nakamoto <satoshin@gmx.com\n<mailto:satoshin@gmx.com>> wrote:\n\n    test 7:\n\n    Backup your data directory before running this, just in case.\n\n    Workaround for the Db::open/Db::close \"Bad file descriptor\"\n    exception. Might also make the initial block download faster.  The\n    workaround is to open the database handles and keep them open for\n    the duration of the program, which is actually the more common thing\n    to do anyway.  If we're not closing and opening all the time, the\n    error shouldn't get a chance to happen.\n\n    The one exception is wallet.dat, which I still close after writing\n    is finished so I can flush the transaction logs into the dat file,\n    making the dat file standalone.  That way if someone does a backup\n    while Bitcoin is running, they'll get a wallet.dat that is valid by\n    itself without the database transaction logs.\n\n    This is a restructuring of the database handling, so we might find\n    some new deadlocks.  Usually if it deadlocks, either the UI will\n    stop repainting, or it'll stop using CPU even though it still says\n    Generating.","Liberty Standard wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-95","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Liberty Standard <newlibertystandard@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: linux-0.1.6-test7"}],"id":"x39"},{"k":"x","s":"martti-malmi","t":"SMF forum, need a mod installed","u":"https://mmalmi.github.io/satoshi/#email-99","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258694096,"b":[["t","I've been configuring the SMF forum.  They're saying SMF is better\nwritten than phpBB and more reliable, so if I can get SMF to look right,\nthat's the preferable choice.\n\nMost forums run vBulletin (big-boards.com lists 1376 vBulletin, 275\nInvision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or\nInvision, it looks like you compromised because you couldn't afford\nvBulletin.  SMF's UI started out further away from the standard look,\nbut I've been able to use CSS to make it look more like the others.\n\nI've done as much as I can with CSS, the rest requires editing PHP files\nand uploading images.  The forum doesn't have a built in file\nupload/edit admin feature, it's added separately as the SMF File Manager\nmod.  I uploaded the mod but some files need to be chmod 777 so it can\ninstall.  If you go to Admin->Packages->Browse Packages and click on\nApply Mod, it offers to do it automatically if you enter an ftp login.\n\nSomeone says you might also have to\nmkdir /var/www/bitcoin/smf/packages/temp\n\nThe error in the error log is:\nfailed to open stream: Permission denied\nFile: /var/www/bitcoin/smf/Sources/Subs-Package.php\n(I'm sure that's just the first file)\n\nIs it OK to go live with this SMF installation when I'm finished\nconfiguring it?  I should be able to point forum.bitcoin.org to it.\n\nLiberty reports that linux-test8 has been running smoothly.  My tests\nhave been running fine as well.  The Linux version looks fully\nstabilized to me.\n\nGood news: he says he made his first sale of bitcoins.  Someone bought\nout all he had.  I had been wondering whether it would be buyers or sellers."]],"u":"https://mmalmi.github.io/satoshi/#email-99","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258700734,"b":[["t","I don't have the time to configure it today, but I made a temporary\naccount \"maintenance\" with password \"6648ku5HeK\" and full permissions\nto /var/www/bitcoin. You can access it via ssh or sftp at port 30000.\n\nIt's okay to go live. Are you setting up a redirect or a dns entry? In\ncase of dns entry I could set up an Apache vhost so that the forum\naddress would be http://forum.bitcoin.org/.\n\nGreat that the Linux build works now. It's exciting to see how things\nwill start rolling with the new release and the forum. Not too long\nuntil I can set up my own exchange and start promoting the currency to\n(web) business people.\n\nNewLibertyStandard should perhaps change his pricing to the market\nprice (i.e. what people are willing to buy and sell for) so that he\ndoesn't run out of coins."],["q","I've been configuring the SMF forum.  They're saying SMF is better\nwritten than phpBB and more reliable, so if I can get SMF to look\nright, that's the preferable choice.\n\nMost forums run vBulletin (big-boards.com lists 1376 vBulletin, 275\nInvision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or\nInvision, it looks like you compromised because you couldn't afford\nvBulletin.  SMF's UI started out further away from the standard look,\nbut I've been able to use CSS to make it look more like the others.\n\nI've done as much as I can with CSS, the rest requires editing PHP\nfiles and uploading images.  The forum doesn't have a built in file\nupload/edit admin feature, it's added separately as the SMF File\nManager mod.  I uploaded the mod but some files need to be chmod 777 so\nit can install.  If you go to Admin->Packages->Browse Packages and\nclick on Apply Mod, it offers to do it automatically if you enter an\nftp login.\n\nSomeone says you might also have to\nmkdir /var/www/bitcoin/smf/packages/temp\n\nThe error in the error log is:\nfailed to open stream: Permission denied\nFile: /var/www/bitcoin/smf/Sources/Subs-Package.php\n(I'm sure that's just the first file)\n\nIs it OK to go live with this SMF installation when I'm finished\nconfiguring it?  I should be able to point forum.bitcoin.org to it.\n\nLiberty reports that linux-test8 has been running smoothly.  My tests\nhave been running fine as well.  The Linux version looks fully\nstabilized to me.\n\nGood news: he says he made his first sale of bitcoins.  Someone bought\nout all he had.  I had been wondering whether it would be buyers or\nsellers."]],"u":"https://mmalmi.github.io/satoshi/#email-100","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: SMF forum, need a mod installed"},{"f":"mmalmi@cc.hut.fi","d":1258701420,"b":[["t","Oh yes, one more thing. I haven't configured the server's sendmail\nyet, so the php mail functionality doesn't work, but it's not needed\nyet anyway."],["q","I don't have the time to configure it today, but I made a temporary\naccount \"maintenance\" with password \"6648ku5HeK\" and full permissions\nto /var/www/bitcoin. You can access it via ssh or sftp at port 30000.\n\nIt's okay to go live. Are you setting up a redirect or a dns entry? In\ncase of dns entry I could set up an Apache vhost so that the forum\naddress would be http://forum.bitcoin.org/.\n\nGreat that the Linux build works now. It's exciting to see how things\nwill start rolling with the new release and the forum. Not too long\nuntil I can set up my own exchange and start promoting the currency to\n(web) business people.\n\nNewLibertyStandard should perhaps change his pricing to the market\nprice (i.e. what people are willing to buy and sell for) so that he\ndoesn't run out of coins.\n\n> I've been configuring the SMF forum.  They're saying SMF is better\n> written than phpBB and more reliable, so if I can get SMF to look\n> right, that's the preferable choice.\n>\n> Most forums run vBulletin (big-boards.com lists 1376 vBulletin, 275\n> Invision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or\n> Invision, it looks like you compromised because you couldn't afford\n> vBulletin.  SMF's UI started out further away from the standard look,\n> but I've been able to use CSS to make it look more like the others.\n>\n> I've done as much as I can with CSS, the rest requires editing PHP\n> files and uploading images.  The forum doesn't have a built in file\n> upload/edit admin feature, it's added separately as the SMF File\n> Manager mod.  I uploaded the mod but some files need to be chmod 777 so\n> it can install.  If you go to Admin->Packages->Browse Packages and\n> click on Apply Mod, it offers to do it automatically if you enter an\n> ftp login.\n>\n> Someone says you might also have to\n> mkdir /var/www/bitcoin/smf/packages/temp\n>\n> The error in the error log is:\n> failed to open stream: Permission denied\n> File: /var/www/bitcoin/smf/Sources/Subs-Package.php\n> (I'm sure that's just the first file)\n>\n> Is it OK to go live with this SMF installation when I'm finished\n> configuring it?  I should be able to point forum.bitcoin.org to it.\n>\n> Liberty reports that linux-test8 has been running smoothly.  My tests\n> have been running fine as well.  The Linux version looks fully\n> stabilized to me.\n>\n> Good news: he says he made his first sale of bitcoins.  Someone bought\n> out all he had.  I had been wondering whether it would be buyers or\n> sellers."]],"u":"https://mmalmi.github.io/satoshi/#email-101","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: SMF forum, need a mod installed"},{"f":"Satoshi Nakamoto","d":1258754981,"b":[["q","It's okay to go live. Are you setting up a redirect or a dns entry? In\ncase of dns entry I could set up an Apache vhost so that the forum\naddress would be http://forum.bitcoin.org/."],["t","DNS entry.\n\nI'm thinking of merging the bitcoin.org information with your site\ncontent so I can switch the whole bitcoin.org domain over.  We need to\nreplace the current bitcoin.org site with a user-oriented site before\nthe release.\n\nIf the website and forum switch at the same time, then forum.bitcoin.org\nisn't necessary unless we want it that way for looks.\n\nHave you decided on the CMS to use?  I should research Drupal and other\nCMSes and see what's the most popular."],["q","Great that the Linux build works now. It's exciting to see how things\nwill start rolling with the new release and the forum. Not too long\nuntil I can set up my own exchange and start promoting the currency to\n(web) business people."],["t","The linux version, setup exe, tor option and better website/forum will\nall increase the percentage of visitors who can use it, and the\nautostart and minimize to tray will increase how many keep running it.\nAll those factors multiply together."],["q","NewLibertyStandard should perhaps change his pricing to the market price\n(i.e. what people are willing to buy and sell for) so that he doesn't\nrun out of coins."],["t","It's good to start low and only have the price go up.\n\nI really like that he explains the concept that the cost of electricity\nis a minimum floor under the price.  At a minimum you either have to pay\nthe cost in electricity or pay someone the cost of production to make\nthem for you."]],"u":"https://mmalmi.github.io/satoshi/#email-102","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: SMF forum, need a mod installed"},{"f":"Satoshi Nakamoto","d":1258786940,"b":[["t","Thanks, that worked, I got File Manager installed with SSH.  I also\nuploaded a few themes into Drupal.  I haven't thoroughly gone through\nall the available themes yet.\n\nLooked around at CMSes, Drupal and Joomla are popular.  Consensus is\nJoomla has a better selection of themes and is easier to learn, though\nDrupal may be more intuitive for programmers and customization.  Joomla\nbetter for CMS, Drupal better for blogs.  Drupal's URLs are search\nengine friendly, Joomla not.\n\nBoth have SMF bridge modules available.  For future reference, Drupal's\nis named \"SMFforum Integration\"."],["q","I don't have the time to configure it today, but I made a temporary\naccount \"\" with password \"\" and full permissions to\n/var/www/bitcoin. You can access it via ssh or sftp at port 30000.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-103","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: SMF forum, need a mod installed"},{"f":"mmalmi@cc.hut.fi","d":1258800600,"b":[["t","I've done a Joomla site for a customer, and I must say I like Drupal\nbetter, mostly for the admin interface which is easier to use and\nintegrated into the main site.\n\nImages aren't loading properly over https, I'll check it out when I can.\n\nIt's easier to just change the bitcoin.org DNS entry,\nforum.bitcoin.org is not necessary.\n\nWe could see if we can get a free SSL certificate somewhere, like\nhttp://www.startssl.com/?app=1, so the users wouldn't get a security\nwarning from a self-signed certificate. However I don't know if they\ngive certificates for anonymously registered domains."],["q","Thanks, that worked, I got File Manager installed with SSH.  I also\nuploaded a few themes into Drupal.  I haven't thoroughly gone through\nall the available themes yet.\n\nLooked around at CMSes, Drupal and Joomla are popular.  Consensus is\nJoomla has a better selection of themes and is easier to learn, though\nDrupal may be more intuitive for programmers and customization.  Joomla\nbetter for CMS, Drupal better for blogs.  Drupal's URLs are search\nengine friendly, Joomla not.\n\nBoth have SMF bridge modules available.  For future reference, Drupal's\nis named \"SMFforum Integration\".\n\nmmalmi@cc.hut.fi wrote:\n> I don't have the time to configure it today, but I made a temporary\n>  account \"\" with password \"\" and full permissions to\n> /var/www/bitcoin. You can access it via ssh or sftp at port 30000."]],"u":"https://mmalmi.github.io/satoshi/#email-104","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: SMF forum, need a mod installed"},{"f":"Satoshi Nakamoto","d":1258840012,"b":[["t","I'll go ahead with setting up Drupal then.\n\nI don't think we should make the site https by default.  It's still very\nunusual for the public part of sites to be https, probably because it\nintroduces potential technical complications, delays and greater server\nload.  As a user I'm a little annoyed when it takes time to verify the\nidentity of some no-name site I casually came across.  For me it seems\nlike https sites fail to load a lot more often.\n\nThe important thing is to have SSL available for those who need it.\nThose who need SSL I think know to try inserting an \"s\" after http and\nsee if it works.  SMF has code that changes all the links to https if\nthe URL handed in is https.\n\nWe could add a note on the registration page that if you want SSL, you\ncan change http to https at any time and approve the self-signed\ncertificate, or a link that does it, and the TOR page can mention it too.\n\nWe can look into getting a certificate later when things have settled\ndown.  With Class 1, no changes are allowed for a year, which is a risk\nif we find issues with the current host and have to change IP."],["q","I've done a Joomla site for a customer, and I must say I like Drupal\nbetter, mostly for the admin interface which is easier to use and\nintegrated into the main site.\n\nImages aren't loading properly over https, I'll check it out when I can.\n\nIt's easier to just change the bitcoin.org DNS entry, forum.bitcoin.org\nis not necessary.\n\nWe could see if we can get a free SSL certificate somewhere, like\nhttp://www.startssl.com/?app=1, so the users wouldn't get a security\nwarning from a self-signed certificate. However I don't know if they\ngive certificates for anonymously registered domains.\n\n> Thanks, that worked, I got File Manager installed with SSH.  I also\n> uploaded a few themes into Drupal.  I haven't thoroughly gone through\n> all the available themes yet.\n>\n> Looked around at CMSes, Drupal and Joomla are popular.  Consensus is\n> Joomla has a better selection of themes and is easier to learn, though\n> Drupal may be more intuitive for programmers and customization.  Joomla\n> better for CMS, Drupal better for blogs.  Drupal's URLs are search\n> engine friendly, Joomla not.\n>\n> Both have SMF bridge modules available.  For future reference, Drupal's\n> is named \"SMFforum Integration\".\n>\n> mmalmi@cc.hut.fi wrote:\n>> I don't have the time to configure it today, but I made a temporary\n>>  account \"\" with password \"\" and full permissions to\n>> /var/www/bitcoin. You can access it via ssh or sftp at port 30000.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-105","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: SMF forum, need a mod installed"}],"id":"x40"},{"k":"x","s":"martti-malmi","t":"SEO friendly site transition","u":"https://mmalmi.github.io/satoshi/#email-106","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258919276,"b":[["t","We need to do a continuity transition with bitcoin.org so the search\nengines don't think this is a new site and reset the site start date and\nPR data.  Google allows a certain number of properties like IP address\nor content of the site to change without deleting your site history.  To\nplay it safe, when the IP address changes, the content better stay the\nsame and vice versa.  Even though not much rank has accumulated yet, the\noriginal start date becomes extremely important if the site gets popular\nlater.\n\nSteps:\n1) copy the current bitcoin.org index.html to the new server exactly as-is.\n2) switch the bitcoin.org DNS entry.\n3) keep working on the drupal site behind the scenes.\n4) after google has had time to update its records, we can switch over\nto the drupal site.\n\nThe timing works out well because we can switch to the new forum now and\nrelease the drupal site later when we're ready.\n\nI'll see if I can figure out how to temporarily move drupal aside to\ndrupal.php or /drupal/ or something where we can still easily get in and\nwork on it."]],"u":"https://mmalmi.github.io/satoshi/#email-106","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258921377,"b":[["t","That's ok.\n\nI'll be afk 23.-25.11."],["q","We need to do a continuity transition with bitcoin.org so the search\nengines don't think this is a new site and reset the site start date\nand PR data.  Google allows a certain number of properties like IP\naddress or content of the site to change without deleting your site\nhistory.  To play it safe, when the IP address changes, the content\nbetter stay the same and vice versa.  Even though not much rank has\naccumulated yet, the original start date becomes extremely important if\nthe site gets popular later.\n\nSteps:\n1) copy the current bitcoin.org index.html to the new server exactly as-is.\n2) switch the bitcoin.org DNS entry.\n3) keep working on the drupal site behind the scenes.\n4) after google has had time to update its records, we can switch over\nto the drupal site.\n\nThe timing works out well because we can switch to the new forum now\nand release the drupal site later when we're ready.\n\nI'll see if I can figure out how to temporarily move drupal aside to\ndrupal.php or /drupal/ or something where we can still easily get in\nand work on it."]],"u":"https://mmalmi.github.io/satoshi/#email-107","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: SEO friendly site transition"}],"id":"x41"},{"k":"x","s":"martti-malmi","t":"Access permissions required to fix Drupal","u":"https://mmalmi.github.io/satoshi/#email-108","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1258955299,"b":[["t","Drupal's .htaccess file which uses mod_rewrite to allow clean URLs\nwithout the ? parameter is not working because its changes are rejected\nbecause Apache is not configured with \"AllowOverride All\".  This is\nneeded to make Drupal coexist with the other site the way we want.\n\nI need access to change these files to fix it:\n  /etc/apache2/sites-available/default\n  /etc/apache2/sites-available/default-ssl\n  /etc/apache2/httpd.conf\n\nHere's the planned fix.  If you do it yourself, please still give me\naccess to httpd.conf in case I need to change it again later.\n\nIn /etc/apache2/sites-available/default\nchange the 2nd instance of \"AllowOverride None\"\n      to \"AllowOverride All\"\n\nand in /etc/apache2/sites-available/default-ssl\nchange the 2nd instance of \"AllowOverride AuthConfig\"\n      to \"AllowOverride All\"\n\nreplace\n  /etc/apache2/httpd.conf\nwith\n  /home/maintenance/httpd.conf\n\nThis probably requires Apache to be restarted after.\n(apache2ctl graceful)"]],"u":"https://mmalmi.github.io/satoshi/#email-108","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1258958675,"b":[["t","Done. I granted you access to all the files."],["q","Drupal's .htaccess file which uses mod_rewrite to allow clean URLs\nwithout the ? parameter is not working because its changes are rejected\nbecause Apache is not configured with \"AllowOverride All\".  This is\nneeded to make Drupal coexist with the other site the way we want.\n\nI need access to change these files to fix it:\n /etc/apache2/sites-available/default\n /etc/apache2/sites-available/default-ssl\n /etc/apache2/httpd.conf\n\nHere's the planned fix.  If you do it yourself, please still give me\naccess to httpd.conf in case I need to change it again later.\n\nIn /etc/apache2/sites-available/default\nchange the 2nd instance of \"AllowOverride None\"\n     to \"AllowOverride All\"\n\nand in /etc/apache2/sites-available/default-ssl\nchange the 2nd instance of \"AllowOverride AuthConfig\"\n     to \"AllowOverride All\"\n\nreplace\n /etc/apache2/httpd.conf\nwith\n /home/maintenance/httpd.conf\n\nThis probably requires Apache to be restarted after.\n(apache2ctl graceful)"]],"u":"https://mmalmi.github.io/satoshi/#email-109","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Access permissions required to fix Drupal"}],"id":"x42"},{"k":"x","s":"martti-malmi","t":"bitcoin.org DNS change went through","u":"https://mmalmi.github.io/satoshi/#email-110","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1259195193,"b":[["t","The bitcoin.org DNS change went through about 12 hours ago.  I'll wait\nanother 12 hours and then change the Forum tab on\nbitcoin.sourceforge.net to go to http://www.bitcoin.org/smf/\n\nFor future reference, the changes in SMF to update the base url were:\n   server settings->Forum URL\n   themes and layout->attempt to reset all themes\n   there's a path in smileys and message icons"]],"u":"https://mmalmi.github.io/satoshi/#email-110","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x43"},{"k":"x","s":"martti-malmi","t":"Bitweaver menu editor broken","u":"https://mmalmi.github.io/satoshi/#email-111","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1259257542,"b":[["t","The Bitweaver menu editor is broken, I can't change the Forum link.  The\n\"create and edit menu items\" page comes up blank for me:\n\nhttp://bitcoin.sourceforge.net/nexus/menu_items.php?menu_id=2\n\nYou try it, I'm stumped.\n\nThe Forum link should be changed to:\nhttp://www.bitcoin.org/smf/"]],"u":"https://mmalmi.github.io/satoshi/#email-111","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1259282810,"b":[["t","Fixed. I changed it directly in the database."],["q","The Bitweaver menu editor is broken, I can't change the Forum link.\nThe \"create and edit menu items\" page comes up blank for me:\n\nhttp://bitcoin.sourceforge.net/nexus/menu_items.php?menu_id=2\n\nYou try it, I'm stumped.\n\nThe Forum link should be changed to:\nhttp://www.bitcoin.org/smf/"]],"u":"https://mmalmi.github.io/satoshi/#email-112","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitweaver menu editor broken"}],"id":"x44"},{"k":"x","s":"martti-malmi","t":"Google Wave","u":"https://mmalmi.github.io/satoshi/#email-113","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1259481190,"b":[["t","I just watched the Google Wave introduction video at wave.google.com.\nIt's the Google's open source proposal for a replacement for the\ndecades old e-mail protocol, and it looked quite cool. A \"wave\" is a\ncommunication and collaboration unit that can be read and edited by\nmultiple users in real time and easily shared to new users, unlike\ne-mail threads. It combines the functionality of instant messaging,\nwikis, conventional e-mail and social networking, and supports\nintegration with external applications.\n\nIf you want invites, you can give me the e-mail addresses where you\nwant them to. If you already have Wave addresses, please give me them\nas well. It would be great to see how the system works in practice."]],"u":"https://mmalmi.github.io/satoshi/#email-113","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x45"},{"k":"x","s":"martti-malmi","t":"Bitcoin.org","u":"https://mmalmi.github.io/satoshi/#email-114","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1259583184,"b":[["t","The current site layout looks nice and simple. The logo just should be\nchanged. If we want to go live quickly, we can just replace it with\nthe site title and make a better logo later.\n\nIf we need help with site administration or contacts to professional\nweb graphic artists, we can ask Dave. He does Drupal stuff for work."]],"u":"https://mmalmi.github.io/satoshi/#email-114","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1259584611,"b":[["t","It would be also great if you can get the Sourceforge logo from the SF\nproject admin and add it to the site footer."],["q","The current site layout looks nice and simple. The logo just should be\nchanged. If we want to go live quickly, we can just replace it with the\nsite title and make a better logo later.\n\nIf we need help with site administration or contacts to professional\nweb graphic artists, we can ask Dave. He does Drupal stuff for work."]],"u":"https://mmalmi.github.io/satoshi/#email-115","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org"},{"f":"mmalmi@cc.hut.fi","d":1259590033,"b":[["t","I autogenerated the new logo at http://cooltext.com/, it's a good\nquick solution. You can try a wide variety of different logo styles\nthere if you have the patience for the slow user interface."],["q","It would be also great if you can get the Sourceforge logo from the SF\nproject admin and add it to the site footer.\n\n> The current site layout looks nice and simple. The logo just should be\n> changed. If we want to go live quickly, we can just replace it with the\n> site title and make a better logo later.\n>\n> If we need help with site administration or contacts to professional\n> web graphic artists, we can ask Dave. He does Drupal stuff for work."]],"u":"https://mmalmi.github.io/satoshi/#email-116","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org"},{"f":"Satoshi Nakamoto","d":1259613260,"b":[["t","Thanks, I haven't settled on a theme yet.  My first experiment was to\ntry something besides yet another blue site.  Another line of thought is\nthat it should be like a bank website, stately, professional and\nofficial looking to support confidence in financial matters.\n\nThe logo's a little too Disco/web-1990's.  I still like your bitweaver\none better, I recreated it with text as a placeholder for now.  When the\ntheme is more settled, I'll think about a matching logo.\n\nGood idea about the Sourceforge tag, we can use all the graphics we can get.\n\nI have more to do before we go live, and we need to give the search\nengines more time."],["q","I autogenerated the new logo at http://cooltext.com/, it's a good quick\nsolution. You can try a wide variety of different logo styles there if\nyou have the patience for the slow user interface.\n\n> It would be also great if you can get the Sourceforge logo from the SF\n> project admin and add it to the site footer.\n>\n>> The current site layout looks nice and simple. The logo just should be\n>> changed. If we want to go live quickly, we can just replace it with the\n>> site title and make a better logo later.\n>>\n>> If we need help with site administration or contacts to professional\n>> web graphic artists, we can ask Dave. He does Drupal stuff for work.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-117","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin.org"},{"f":"mmalmi@cc.hut.fi","d":1259764002,"b":[["t","The text logo looks quite good actually, except on Windows when the\nfont antialiasing doesn't work. I turned it into a png.\n\nI just made a 10,000bc transaction from one account to another, but it\nended up sending 10,000.20bc. Any idea why that could be?"],["q","Thanks, I haven't settled on a theme yet.  My first experiment was to\ntry something besides yet another blue site.  Another line of thought\nis that it should be like a bank website, stately, professional and\nofficial looking to support confidence in financial matters.\n\nThe logo's a little too Disco/web-1990's.  I still like your bitweaver\none better, I recreated it with text as a placeholder for now.  When\nthe theme is more settled, I'll think about a matching logo.\n\nGood idea about the Sourceforge tag, we can use all the graphics we can get.\n\nI have more to do before we go live, and we need to give the search\nengines more time.\n\nmmalmi@cc.hut.fi wrote:\n> I autogenerated the new logo at http://cooltext.com/, it's a good\n> quick solution. You can try a wide variety of different logo styles\n>  there if you have the patience for the slow user interface.\n>\n>> It would be also great if you can get the Sourceforge logo from the SF\n>> project admin and add it to the site footer.\n>>\n>>> The current site layout looks nice and simple. The logo just should be\n>>> changed. If we want to go live quickly, we can just replace it with the\n>>> site title and make a better logo later.\n>>>\n>>> If we need help with site administration or contacts to professional\n>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-118","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org"},{"f":"Satoshi Nakamoto","d":1259776068,"b":[["t","What Windows version/browser doesn't font anti-aliasing work on?  IE 6\non XP anti-aliases, and versions below that have less than 1% market share.\n\nThere's a transaction fee of 0.01 per KB after the first 1KB for\noversized transactions.  The first 1KB is free, small transactions are\ntypically 250 bytes.  Doubleclick on the transaction.  Think of it like\npostage by weight.\n\nThe solution is an extra dialog when sending, something like \"This is an\noversized transaction and requires a transaction fee of 0.20bc.  Is this\nOK?\"  (is that text good enough or any improvements?)  I have the code\nalready, I'll put it in.\n\nThen we wouldn't have to explain the 10,000.20bc transaction, but may\nstill have to explain who the transaction fee goes to."],["q","The text logo looks quite good actually, except on Windows when the font\nantialiasing doesn't work. I turned it into a png.\n\nI just made a 10,000bc transaction from one account to another, but it\nended up sending 10,000.20bc. Any idea why that could be?\n\n> Thanks, I haven't settled on a theme yet.  My first experiment was to\n> try something besides yet another blue site.  Another line of thought\n> is that it should be like a bank website, stately, professional and\n> official looking to support confidence in financial matters.\n>\n> The logo's a little too Disco/web-1990's.  I still like your bitweaver\n> one better, I recreated it with text as a placeholder for now.  When\n> the theme is more settled, I'll think about a matching logo.\n>\n> Good idea about the Sourceforge tag, we can use all the graphics we\n> can get.\n>\n> I have more to do before we go live, and we need to give the search\n> engines more time.\n>\n> mmalmi@cc.hut.fi wrote:\n>> I autogenerated the new logo at http://cooltext.com/, it's a good\n>> quick solution. You can try a wide variety of different logo styles\n>>  there if you have the patience for the slow user interface.\n>>\n>>> It would be also great if you can get the Sourceforge logo from the SF\n>>> project admin and add it to the site footer.\n>>>\n>>>> The current site layout looks nice and simple. The logo just should be\n>>>> changed. If we want to go live quickly, we can just replace it with\n>>>> the\n>>>> site title and make a better logo later.\n>>>>\n>>>> If we need help with site administration or contacts to professional\n>>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-119","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin.org"},{"f":"mmalmi@cc.hut.fi","d":1259826410,"b":[["q","What Windows version/browser doesn't font anti-aliasing work on?  IE 6\non XP anti-aliases, and versions below that have less than 1% market\nshare."],["t","Firefox on XP doesn't, and IE also doesn't produce as good quality as\nI have on Linux. Screenshots from browsershots.org attached."],["q","There's a transaction fee of 0.01 per KB after the first 1KB for\noversized transactions.  The first 1KB is free, small transactions are\ntypically 250 bytes.  Doubleclick on the transaction.  Think of it like\npostage by weight."],["t","Is there no transaction fee then, if you send the same amount in\nmultiple small packages?"],["q","The solution is an extra dialog when sending, something like \"This is\nan oversized transaction and requires a transaction fee of 0.20bc.  Is\nthis OK?\"  (is that text good enough or any improvements?)  I have the\ncode already, I'll put it in."],["t","Sounds fine."],["q","Then we wouldn't have to explain the 10,000.20bc transaction, but may\nstill have to explain who the transaction fee goes to."],["t","Where should it go btw? Here it went to the receiver along with all\nthe other coins. Transaction screenshot attached."],["q","mmalmi@cc.hut.fi wrote:\n> The text logo looks quite good actually, except on Windows when the\n>  font antialiasing doesn't work. I turned it into a png.\n>\n> I just made a 10,000bc transaction from one account to another, but\n>  it ended up sending 10,000.20bc. Any idea why that could be?\n>\n>> Thanks, I haven't settled on a theme yet.  My first experiment was to\n>> try something besides yet another blue site.  Another line of thought\n>> is that it should be like a bank website, stately, professional and\n>> official looking to support confidence in financial matters.\n>>\n>> The logo's a little too Disco/web-1990's.  I still like your bitweaver\n>> one better, I recreated it with text as a placeholder for now.  When\n>> the theme is more settled, I'll think about a matching logo.\n>>\n>> Good idea about the Sourceforge tag, we can use all the graphics\n>> we can get.\n>>\n>> I have more to do before we go live, and we need to give the search\n>> engines more time.\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> I autogenerated the new logo at http://cooltext.com/, it's a good\n>>>   quick solution. You can try a wide variety of different logo\n>>> styles  there if you have the patience for the slow user interface.\n>>>\n>>>> It would be also great if you can get the Sourceforge logo from the SF\n>>>> project admin and add it to the site footer.\n>>>>\n>>>>> The current site layout looks nice and simple. The logo just should be\n>>>>> changed. If we want to go live quickly, we can just replace it with the\n>>>>> site title and make a better logo later.\n>>>>>\n>>>>> If we need help with site administration or contacts to professional\n>>>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.\n>>>\n>>>\n>>>\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-120","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org"},{"f":"Satoshi Nakamoto","d":1259900681,"b":[["q","> What Windows version/browser doesn't font anti-aliasing work on?  IE 6\n> on XP anti-aliases, and versions below that have less than 1% market\n> share.\n\nFirefox on XP doesn't, and IE also doesn't produce as good quality as I\nhave on Linux. Screenshots from browsershots.org attached.","mmalmi@cc.hut.fi wrote:"],["t","That's strange, I've seen Firefox 3.5 on XP anti-alias large fonts.\nWell anyway, your way is safer.\n\nI changed it back to text for now though so I can keep tweaking the\ncolours.  Drupal puts the <span> tags and junk in the browser title but\nthat's fine for testing.\n\nI added some instruction text on the homepage below the screenshots."],["q","Is there no transaction fee then, if you send the same amount in\nmultiple small packages?"],["t","True.  I suppose the dialog could make it worse by giving people a\nchance to experiment with breaking it up.\n\nI'm making some changes.  The largest free transaction will be 60KB, or\nabout 27,000bc if made of 50bc inputs.  I hope that's high enough that\nthe transaction fee should rarely ever come up.  v0.2 nodes will take\nfree transactions until the block size is over 200K, with priority given\nto smaller transactions.\n\nIt's best if you don't talk about this transaction fee stuff in public.\n  It's there for flood control.  We don't want to give anyone any ideas."],["q","Where should it go btw? Here it went to the receiver along with all the\nother coins. Transaction screenshot attached."],["t","You found an infrequent bug in CreateTransaction.  It wrote the\ntransaction for 10000.20 with a fee of 0.22.  If you look at the\ntransaction on the sender's side, it'll be a debit 10000.42 with\ntransaction fee 0.22.  The bug was that it had to make a rare third pass\non calculating the fee, and incorrectly added the first pass' fee to the\namount being sent.  Will fix."]],"u":"https://mmalmi.github.io/satoshi/#email-121","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin.org"}],"id":"x46"},{"k":"x","s":"martti-malmi","t":"Re: Sourceforge tracker","u":"https://mmalmi.github.io/satoshi/#email-122","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1260069660,"b":[["t","I added the sourceforge tracker to bitcoin.sourceforge.net.  The\ncomplete selection of links is below if you want a different one.\n\nI had it on bitcoin.org for a minute, but took it off.  It breaks the\nlock in SSL mode with a mixed content warning, \"partially encrypted\" and\n\"contains unauthenticated content\".  Anyway, do we really want\nsourceforge tracking everyone?  It's more privacy friendly without it.\n\n---\nThe available logos and the correct HTML to use for the Bitcoin project are:\n\nLogo 1 (Dimensions: 80 x 15; Background: Black)\n\nHTML Code:\n\nLogo 2 (Dimensions: 80 x 15; Background: Silver)\n\nHTML Code:\n\nLogo 3 (Dimensions: 80 x 15; Background: White)\n\nHTML Code:\n\nLogo 4 (Dimensions: 120 x 30; Background: Black)\n\nHTML Code:\n\nLogo 5 (Dimensions: 120 x 30; Background: Silver)\n\nHTML Code:\n\nLogo 6 (Dimensions: 120 x 30; Background: White)\n\nHTML Code:\n\nLogo 7 (Dimensions: 150 x 40; Background: Black)\n\nHTML Code:\n\nLogo 8 (Dimensions: 150 x 40; Background: Silver)\n\nHTML Code:\n\nLogo 9 (Dimensions: 150 x 40; Background: White)\n\nHTML Code:"],["q","It would be also great if you can get the Sourceforge logo from the SF\nproject admin and add it to the site footer.\n\n> The current site layout looks nice and simple. The logo just should be\n> changed. If we want to go live quickly, we can just replace it with the\n> site title and make a better logo later.\n>\n> If we need help with site administration or contacts to professional\n> web graphic artists, we can ask Dave. He does Drupal stuff for work.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-122","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1260186548,"b":[["t","I made a copy of the logo onto the local server, so we can still use\nit for graphics. It's not disallowed by the SF trademark policy."],["q","I added the sourceforge tracker to bitcoin.sourceforge.net.  The\ncomplete selection of links is below if you want a different one.\n\nI had it on bitcoin.org for a minute, but took it off.  It breaks the\nlock in SSL mode with a mixed content warning, \"partially encrypted\"\nand \"contains unauthenticated content\".  Anyway, do we really want\nsourceforge tracking everyone?  It's more privacy friendly without it.\n\nmmalmi@cc.hut.fi wrote:\n> It would be also great if you can get the Sourceforge logo from the\n>  SF project admin and add it to the site footer.\n>\n>> The current site layout looks nice and simple. The logo just should be\n>> changed. If we want to go live quickly, we can just replace it with the\n>> site title and make a better logo later.\n>>\n>> If we need help with site administration or contacts to professional\n>> web graphic artists, we can ask Dave. He does Drupal stuff for work.\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-123","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x47"},{"k":"x","s":"martti-malmi","t":"Drupal site online","u":"https://mmalmi.github.io/satoshi/#email-124","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1260251013,"b":[["t","I went ahead and put the new Drupal site online.  Enough time has passed\nfor a safe transition, and the site looks good.  There's more work I\nshould do on the theme, but it's good enough so far.  This is a huge\nimprovement over the old bitcoin.org page."]],"u":"https://mmalmi.github.io/satoshi/#email-124","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1260269420,"b":[["t","Good job. I redirected bitcoin.sourceforge.net there."],["q","I went ahead and put the new Drupal site online.  Enough time has\npassed for a safe transition, and the site looks good.  There's more\nwork I should do on the theme, but it's good enough so far.  This is a\nhuge improvement over the old bitcoin.org page."]],"u":"https://mmalmi.github.io/satoshi/#email-125","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Drupal site online"}],"id":"x48"},{"k":"x","s":"martti-malmi","t":"custom3 theme","u":"https://mmalmi.github.io/satoshi/#email-126","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1260502210,"b":[["t","I wasn't satisfied with my custom2 theme.  It felt crowded, the\nheader/logo seemed wrong and the heavy left margin stationery style is\noutdated.\n\ncustom3 online now is a more standard layout similar to a lot of\ncommercial software homepages.  Maybe it's just me, but I really like\nthe random blue squares."]],"u":"https://mmalmi.github.io/satoshi/#email-126","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x49"},{"k":"x","s":"martti-malmi","t":"Re: Version 0.2 almost ready to release","u":"https://mmalmi.github.io/satoshi/#email-127","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1260735158,"b":[["q","It's almost time to release version 0.2.  If you have a minute, could\nyou try this release candidate (attached)?  If there aren't any\nproblems and I don't think of anything I missed, this could be released\nin a day or two."],["t","No problems so far. Seems fine."],["q","I zipped the setup exe because I doubt the e-mail servers will allow\nexe attachments.  I'm not sure it'll allow zip either, but pretty sure\nthe tar.gz one will get through.\n\nAttachments:\n3,092,916 bitcoin-0.2.0-setup.zip\n2,402,522 bitcoin-0.2.0-linux.tar.gz\n3,061,059 bitcoin-0.2.0-win32.zip"],["t","Both got through here."]],"u":"https://mmalmi.github.io/satoshi/#email-127","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x50"},{"k":"x","s":"martti-malmi","t":"Re: RC2","u":"https://mmalmi.github.io/satoshi/#email-128","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1260852004,"b":[["q","Found something I felt I had to fix with the initial block download.\nDo you mind testing an initial block download again?"],["t","The first time I tried it on Windows, the initial download took a few\nminutes to start, even though it got many connections quickly. I tried\nagain twice, and didn't have the same problem again. I don't know\nwhether it's related to your latest update or not.\n\nOn Ubuntu it worked fine."],["q","Hope this isn't in the middle of your final exams right now."],["t","Well actually it is, but it's not too bad. Time is a matter of arrangement."]],"u":"https://mmalmi.github.io/satoshi/#email-128","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1260939456,"b":[["q","The first time I tried it on Windows, the initial download took a few\nminutes to start, even though it got many connections quickly. I tried\nagain twice, and didn't have the same problem again. I don't know\nwhether it's related to your latest update or not.","mmalmi@cc.hut.fi wrote:"],["t","Most of the fixes are on the sender's side, so if you were downloading the network upgrades to 0.2.\n\nHow long did the initial download take?"]],"u":"https://mmalmi.github.io/satoshi/#email-129","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1260978101,"b":[["q","> The first time I tried it on Windows, the initial download took a\n> few minutes to start, even though it got many connections quickly.\n> I tried again twice, and didn't have the same problem again. I\n> don't know whether it's related to your latest update or not.\n\nMost of the fixes are on the sender's side, so if you were downloading\nfrom a 0.1.5 node, some problems are still there.  It'll get better as\nthe network upgrades to 0.2.\n\nHow long did the initial download take?"],["t","About 1,5h."]],"u":"https://mmalmi.github.io/satoshi/#email-130","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x51"},{"k":"x","s":"martti-malmi","t":"Planned release announcement text","u":"https://mmalmi.github.io/satoshi/#email-131","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1260982486,"b":[["t","Here's the planned release announcement text.  Probably releasing shortly.\n\nBitcoin version 0.2 is here!\n\nDownload links:\nWindows Setup Program\nWindows Zip File\nLinux (tested on Ubuntu)\n\nNew features\n\nMartti Malmi\n  - Minimize to system tray option\n  - Autostart on boot option so you can keep it running in the\nbackground automatically\n  - New options dialog layout for future expansion\n  - Setup program for Windows\n  - Linux version\nSatoshi Nakamoto\n  - Multi-processor support for coin generation\n  - Proxy support for use with TOR\n  - Fixed some slowdowns in the initial block download\n  - Various refinements to keep the network running smoothly\n\nWe also have a new forum at http://www.bitcoin.org/smf/ if you have any\nquestions.\n\nThanks to Martti Malmi (sirius-m) for his coding work and for hosting\nthe new site and forum, and thanks to New Liberty Standard for testing\nthe Linux version.\n\nSatoshi Nakamoto"]],"u":"https://mmalmi.github.io/satoshi/#email-131","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x52"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] Bitcoin 0.2 released","u":"https://mmalmi.github.io/satoshi/#email-132","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1261032542,"b":[["t","Bitcoin 0.2 is here!\n\nDownload (Windows, and now Linux version available)\nhttp://sourceforge.net/projects/bitcoin/files/\n\nNew Features\n\nMartti Malmi\n  - Minimize to system tray option\n  - Autostart on boot option so you can keep it running in the\nbackground automatically\n  - New options dialog layout for future expansion\n  - Setup program for Windows\n  - Linux version (tested on Ubuntu)\nSatoshi Nakamoto\n  - Multi-processor support for coin generation\n  - Proxy support for use with TOR\n  - Fixed some slowdowns in the initial block download\n\nWe also have a new forum at http://www.bitcoin.org/smf/\n\nMany thanks to Martti (sirius-m) for all his development work, and to\nNew Liberty Standard for his help with testing the Linux version.\n\nSatoshi Nakamoto\n\n------------------------------------------------------------------------------\nThis SF.Net email is sponsored by the Verizon Developer Community\nTake advantage of Verizon's best-in-class app development support\nA streamlined, 14 day to market process makes app distribution fast and easy\nJoin now and get one step closer to millions of Verizon customers\nhttp://p.sf.net/sfu/verizon-dev2dev "],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-132","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x53"},{"k":"x","s":"martti-malmi","t":"Bitcoin stuff","u":"https://mmalmi.github.io/satoshi/#email-133","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1261489754,"b":[["t","I have registered the domain name bitcoinexchange.com and will start\ncoding the service sometime soon as a nice leisure activity. I'm\nenvisioning a simple Google-like interface with no registration and\nonly two texts fields on the front page, where you insert the amount\nof money you wish to trade, and either your PayPal address to buy\ndollars or bitcoin address to buy bitcoins. On the next page you'll\nget a new bitcoin address for sending the coins or a check code for\nthe PayPal transaction text.\n\nPayPal is good for the beginning - it's simple and has no startup\ncosts, but later on I might accept credit cards also.\n\nDo you still need the maintenance account? It's ok if you do, but\nchange the password to something else."]],"u":"https://mmalmi.github.io/satoshi/#email-133","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1261508441,"b":[["t","Thanks for creating the maintenance account, it would have been\nimpossible to do all that without it.  I'm really always going to need\nit.  OK, I changed the password to a 20 character random password.\n\nThat's a good domain.  People rarely type domain names anymore, they use\nautocomplete or click links on search engines.\n\nI need to make a way for you to programmatically get new generated\nbitcoin addresses.  Either that or you could have them send to your IP\naddress, but then you have to rely on them to put the order number in\nthe comment.\n\nWhen generating the new address, there can be an option to add an entry\nto the address book associated with the address, so the received\ntransaction will be labelled.  I kinda hid the labels after early users\nfound them confusing, but it would be very helpful for this application.\n  You have to widen up the comment column to see them.\n\nAre you going to manually review and enter orders, at least to begin\nwith?  I sure would.\n\nI'm thinking I should move the UI in the direction of having the user\nask for their bitcoin address when they want one.  \"give me a bitcoin to\nreceive a payment with\".  I suppose next to the send button, there would\nby a receive button, you press it and it says \"here's a new address to\nuse, here's the button to copy it to the clipboard, do you want to label\nit?\" and maybe some explanation about why you shouldn't reuse addresses.\n\nOr maybe just a \"New Address\" button next to the address box that you\nshould hit each time to change it."],["q","I have registered the domain name bitcoinexchange.com and will start\ncoding the service sometime soon as a nice leisure activity. I'm\nenvisioning a simple Google-like interface with no registration and only\ntwo texts fields on the front page, where you insert the amount of money\nyou wish to trade, and either your PayPal address to buy dollars or\nbitcoin address to buy bitcoins. On the next page you'll get a new\nbitcoin address for sending the coins or a check code for the PayPal\ntransaction text.\n\nPayPal is good for the beginning - it's simple and has no startup costs,\nbut later on I might accept credit cards also.\n\nDo you still need the maintenance account? It's ok if you do, but change\nthe password to something else.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-134","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin stuff"},{"f":"mmalmi@cc.hut.fi","d":1261559523,"b":[["q","I need to make a way for you to programmatically get new generated\nbitcoin addresses.  Either that or you could have them send to your IP\naddress, but then you have to rely on them to put the order number in\nthe comment."],["t","I'd also need at least the command line tools to check if coins have\nbeen received and to send coins. It would require some way to\ncommunicate with the Bitcoin process running in the background. I\ndon't know how that should be done, maybe with something RPC related.\n\nIt would also be great if the background process was non-graphical -\nthe VPS on the current service level doesn't have enough memory to run\nthe X Windowing environment, unless I come up with some ways to free\nmemory."],["q","Are you going to manually review and enter orders, at least to begin\nwith?  I sure would."],["t","Yes, at least to begin with, when the customer sells bc's and receives\ndollars. I wouldn't give a script the access to my dollar reserves so\nlightly. The other way around (customer's dollars -> bitcoins) it\ndoesn't feel that insecure, and it's certainly nicer for the customer\nto receive his bitcoins immediately."],["q","mmalmi@cc.hut.fi wrote:\n> I have registered the domain name bitcoinexchange.com and will\n> start coding the service sometime soon as a nice leisure activity.\n> I'm envisioning a simple Google-like interface with no registration\n>  and only two texts fields on the front page, where you insert the\n> amount of money you wish to trade, and either your PayPal address\n> to buy dollars or bitcoin address to buy bitcoins. On the next page\n>  you'll get a new bitcoin address for sending the coins or a check\n> code for the PayPal transaction text.\n>\n> PayPal is good for the beginning - it's simple and has no startup\n> costs, but later on I might accept credit cards also.\n>\n> Do you still need the maintenance account? It's ok if you do, but\n> change the password to something else.\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-135","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin stuff"},{"f":"Satoshi Nakamoto","d":1261590798,"b":[["q","I'd also need at least the command line tools to check if coins have\nbeen received and to send coins. It would require some way to\ncommunicate with the Bitcoin process running in the background. I don't\nknow how that should be done, maybe with something RPC related.\n\nIt would also be great if the background process was non-graphical - the\nVPS on the current service level doesn't have enough memory to run the X\nWindowing environment, unless I come up with some ways to free memory.","mmalmi@cc.hut.fi wrote:"],["t","I had been wondering why everyone keeps harping on no-UI, when already\nyou can run it with only a small icon on the tray, which is common for\nserver services on Windows.  So I guess this is why.  I had chalked it\nup to unix snobbery if they couldn't abide a tiny little icon on a\ndesktop they never see.\n\nNot opening any windows is easy, but it may fail because the gtk\nlibraries aren't there.  wxWidgets has __WXBASE__ for \"Only wxBase, no\nGUI features\".  You could try building for that instead of __WXGTK__ and\nsee what happens.  It would be preferable if there's any way to do it as\na command line switch on the same executable, rather than yet another\nbuild variation to release.\n\nHow much memory do you have to work with?  Bitcoin necessarily takes a\nfair bit of memory; about 75MB on Windows.  Is that a problem?\n\nCommand line control is one of the next things on the list.  I want to\ndesign the API carefully.\n\nReceiving payments is the part that has a lot of design choices to be\nmade.  The caller needs to identify the transactions of interest, that's\nwhere the one-bitcoin-address-per-transaction model helps.  Searching\nthe comments text for an order number is another possibility.  There's\npolled, asking what has been received to the given bitcoin address, and\nevent driven.  I guess in event driven, bitcoin would be told to run a\ncommand line when a certain amount is received to a certain bitcoin address."]],"u":"https://mmalmi.github.io/satoshi/#email-136","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin stuff"},{"f":"mmalmi@cc.hut.fi","d":1261747543,"b":[["q","How much memory do you have to work with?"],["t","The VPS has 320MB RAM, 50MB of which is currently free. There's also\n500MB swap space."],["q","Bitcoin necessarily takes a\nfair bit of memory; about 75MB on Windows.  Is that a problem?"],["t","Sure about that? Windows task manager shows about 13MB memory usage here."]],"u":"https://mmalmi.github.io/satoshi/#email-137","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin stuff"},{"f":"Satoshi Nakamoto","d":1261757474,"b":[["t","You're right, I was looking at a test run with 250,000 blocks... duh.\n\nA normal one shows 17MB memory usage and 10MB VM size."],["q","> How much memory do you have to work with?\nThe VPS has 320MB RAM, 50MB of which is currently free. There's also\n500MB swap space.\n\n> Bitcoin necessarily takes a\n> fair bit of memory; about 75MB on Windows.  Is that a problem?\n\nSure about that? Windows task manager shows about 13MB memory usage here.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-138","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin stuff"}],"id":"x54"},{"k":"x","s":"martti-malmi","t":"Bitcoin Exchange","u":"https://mmalmi.github.io/satoshi/#email-139","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1262656514,"b":[["t","I have a prototype of the bitcoinexchange.com service up now (auth:\nbitcoin/bit). It's running on the Python-powered Django web\napplication framework, which is a pleasure to work with, compared to\nphp.\n\nI'll have to do some studying for a few days now, after which I can\nreturn to work with the exchange service. Among other things I'll fix\nthe pricing so that the price of Bitcoins grows towards infinity when\nmy supply of them gets closer to zero. That way I can find the market\nrate and stay at the point where supply meets demand. I'm not yet\ncompletely sure what the parameters of the hyperbolic pricing curve\nshould be, so that's something to think about."]],"u":"https://mmalmi.github.io/satoshi/#email-139","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x55"},{"k":"x","s":"martti-malmi","t":"Bitcoin API","u":"https://mmalmi.github.io/satoshi/#email-140","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1265189237,"b":[["t","Have you decided upon the inter-process calling method of the Bitcoin\nAPI yet? An easy solution would be the socket interface provided by\nwxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The\nBitcoin program running a wxServer could be then accessed by calling\nthe bitcoin executable from the command line or by coding your own\nwxClient app.\n\nAnother option would be to just use the plain BSD sockets.\n\nCan you send me a 64-bit Linux binary of Bitcoin if you have one? I\ntried compiling on the VPS, but it ran out of memory. Tried the 32-bit\nversion (with ia32-libs) also, but it didn't find the shared libraries."]],"u":"https://mmalmi.github.io/satoshi/#email-140","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1265228753,"b":[["t","Is there any way to find out what the missing shared libraries are?  It\nwould help to know.\n\nIt probably needs the gtk libraries, in which case you'll have the same\nproblem with the 64-bit version.  I would like to have a single\nexecutable that can also run on a UI-less system, but I'm not sure how\non linux to link to things but still be able to run and not use them if\nthe library is not present.  Maybe we should statically link the GTK.\nLicensewise, it's LGPL, but since it's only used on unix, that would be\nOK.  (we can't link LGPL stuff on windows because we provide the OpenSSL\nDLL, but on linux OpenSSL comes with the OS)\n\nMy 64-bit (debug stripped) executable is attached.  It includes untested\nchanges that are not in SVN yet: UI changes and the wallet fSpent flag\nresync stuff.\n\nI've been researching options for interprocess calling.  I want\nsomething that will be easy for a variety of server side languages to\ncall, particularly PHP.  Cross-platform to windows is a plus.\n\nI'm not sure if I want it to be something that can be accessed across\nthe network.  That would introduce security issues.  If it can only be\naccessed on the local system, then local security authentication covers\nit, and it is incapable of being hacked remotely.\n\nAt surface level, not looking into any details yet, the current front\nrunners are:\nD-Bus:\n    local system only\n    used by qt, gnome and skype\n    bindings: c, python, java, c++,\n          php listed as \"in progress\"\n          .net listed as unmaintained\n          not sure how ready it is on windows\nXML-RPC:\n    widely used, built in libraries on PHP\n    it's more for web clients to talk to server, transport is http, so\nits a security question\n\nIs it possible to open a socket that can only be accessed locally?"],["q","Have you decided upon the inter-process calling method of the Bitcoin\nAPI yet? An easy solution would be the socket interface provided by\nwxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The\nBitcoin program running a wxServer could be then accessed by calling the\nbitcoin executable from the command line or by coding your own wxClient\napp.\n\nAnother option would be to just use the plain BSD sockets.\n\nCan you send me a 64-bit Linux binary of Bitcoin if you have one? I\ntried compiling on the VPS, but it ran out of memory. Tried the 32-bit\nversion (with ia32-libs) also, but it didn't find the shared libraries.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-143","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin API"},{"f":"mmalmi@cc.hut.fi","d":1265305656,"b":[["q","Is there any way to find out what the missing shared libraries are?  It\nwould help to know."],["t","This is what \"ldd bitcoin\" says:\n\n         linux-gate.so.1 =>  (0xf778c000)\n         libcrypto.so.0.9.8 => /usr/lib32/i686/cmov/libcrypto.so.0.9.8\n(0xf762a000)\n         libgtk-x11-2.0.so.0 => not found\n         libgthread-2.0.so.0 => not found\n         libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7621000)\n         libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7533000)\n         libm.so.6 => /lib32/libm.so.6 (0xf750f000)\n         libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7502000)\n         libc.so.6 => /lib32/libc.so.6 (0xf73b0000)\n         libdl.so.2 => /lib32/libdl.so.2 (0xf73ac000)\n         libgdk-x11-2.0.so.0 => not found\n         libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf73a8000)\n         libgdk_pixbuf-2.0.so.0 => not found\n         libX11.so.6 => /usr/lib32/libX11.so.6 (0xf72b9000)\n         libpango-1.0.so.0 => not found\n         libgobject-2.0.so.0 => not found\n         libglib-2.0.so.0 => not found\n         libpthread.so.0 => /lib32/libpthread.so.0 (0xf72a1000)\n         libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf727e000)\n         libz.so.1 => /usr/lib32/libz.so.1 (0xf7269000)\n         libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7251000)\n         /lib/ld-linux.so.2 (0xf778d000)\n         libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7243000)\n         libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7241000)\n         libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7229000)\n         libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000)\n         libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7220000)\n\nNotfounds seem to be gtk-libraries indeed. I have those files in my\n/usr/lib folder, but maybe they're ignored because they're 64bit, or\nmaybe only /usr/lib32 is searched. I haven't tested on other 64bit\nmachines."],["q","My 64-bit (debug stripped) executable is attached.  It includes\nuntested changes that are not in SVN yet: UI changes and the wallet\nfSpent flag resync stuff."],["t","The package doesn't open, it says \"not in gzip format\"."],["q","Is it possible to open a socket that can only be accessed locally?"],["t","Yes, you can use IPC sockets (\"Unix domain sockets\") which are local\nonly. That's done in the wx-api by using a filename in place of a port\nnumber. I committed an example of how the wxServer-Client\ncommunication is used, you can revert if you want to. Now there's the\n-blockamount command line option which asks the running instance for\nthe block chain length.\n\nI think this command line method could already be used from PHP, but\nit might be lighter if php itself could call the socket server\ndirectly. The wx's IPC overview mentions wxSocketEvent, wxSocketBase,\nwxSocketClient and wxSocketServer as being \"Classes for the low-level\nTCP/IP API\", which might be easier to use from php than what I used\nnow (wxServer, wxClient, wxConnection). I'll look more into it."]],"u":"https://mmalmi.github.io/satoshi/#email-144","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin API"},{"f":"Satoshi Nakamoto","d":1265309435,"b":[["t","I must have accidentally typed j instead of z.  It's bz2 format.  Rename\nto .tar.bz2 or just do tar -jxvf"],["q","The package doesn't open, it says \"not in gzip format\"."]],"u":"https://mmalmi.github.io/satoshi/#email-145","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin API"},{"f":"Satoshi Nakamoto","d":1265313588,"b":[["t","Good, then no need to consider d-bus.  Is there something like IPC\nsockets on Windows?  I guess we could look how wx does it, or maybe the\nXML-RPC library will already know what to do.  Windows has named pipes,\nmaybe that's the best analogue.\n\nI don't think I want to invent my own RPC protocol, I want to use an\nexisting standard.  PHP, Java, Python or anything will be able to talk\nto the server directly the same way the command line commands do.\n\nI'm going to start reading on XML-RPC.  It's coming up in searches as\nthe most widely used protocol and widely supported.  PHP includes it in\nits standard libraries."],["q","> Is it possible to open a socket that can only be accessed locally?\n\nYes, you can use IPC sockets (\"Unix domain sockets\") which are local\nonly. That's done in the wx-api by using a filename in place of a port\nnumber. I committed an example of how the wxServer-Client communication\nis used, you can revert if you want to. Now there's the -blockamount\ncommand line option which asks the running instance for the block chain\nlength.\n\nI think this command line method could already be used from PHP, but it\nmight be lighter if php itself could call the socket server directly.\nThe wx's IPC overview mentions wxSocketEvent, wxSocketBase,\nwxSocketClient and wxSocketServer as being \"Classes for the low-level\nTCP/IP API\", which might be easier to use from php than what I used now\n(wxServer, wxClient, wxConnection). I'll look more into it."]],"u":"https://mmalmi.github.io/satoshi/#email-147","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin API"}],"id":"x56"},{"k":"x","s":"martti-malmi","t":"Exchange options","u":"https://mmalmi.github.io/satoshi/#email-142","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265247170,"b":[["t","Don't rush ahead and get yourself rejected from all the payment options\nbefore you've had time to see if there's a better approach.  I suggest\nyou wait before contacting any more payment processors.  You may get\nideas from things other users come up with and try.\n\nJust some random incomplete ideas: There may be a way to position it as\nan intermediate credit for micropayments for some virtual good or\nsomething.  Or maybe if the payments are only in one direction.  If you\nonly buy bitcoins, then you're only sending money out not taking\npeople's money, that would still be useful to peg the currency.  That\nmight be payment for computer time.\n\nCredit card is only one way.  Don't even talk about the idea of\nreturning money to customer's credit cards.  Credit card companies hate\nthat.\n\nIn any case, any payment processor is going to expect you to be selling\nsomething real.\n\nDo you have electronic transfer or paper cheque in your country? (even\nif only within Europe)"]],"u":"https://mmalmi.github.io/satoshi/#email-142","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1265356576,"b":[["t","Liberty Reserve sounds good. I could first make a service that only\naccepts LR, and add more options later. The weakness is that buying LR\nis an extra step of inconvenience when the customer just wants to get\nBitcoins. But maybe I don't have too much choice here."],["q","Do you have electronic transfer or paper cheque in your country? (even\nif only within Europe)"],["t","Yes, electronic bank transfer is available. During 2010 most European\ncountries will become a part of SEPA (Single Euro Payments Area),\nwhich means that all payments within Europe are to be considered\ndomestic. Banks will have to apply the same fees and standards to all\ndomestic transfers, so they'll probably all be free of charge and\ncomplete in one bank day. For international transfers there's the\nSWIFT/IBAN system, which usually costs some extra.\n\nA longer term project for my exchange service would be to see what\nkinds of integration options the banks have to offer. Bank transfers\nwould reach nearly as many customers as credit cards do."]],"u":"https://mmalmi.github.io/satoshi/#email-150","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Exchange options"},{"f":"Satoshi Nakamoto","d":1265394552,"b":[["t","Maybe the current difficulty of buying LR is already the limit of how\neasy it can get in that direction.\n\nEvery conventional payment method has refutability as their way to cope\nwith their lack of passwords and crypto.  The system is wide open to\ncopying plaintext credit card numbers and account numbers, and they deal\nwith it by reversing the transaction after the fact.  The system works\nfor physical goods that have to be delivered somewhere, and services\nwhich can't be resold.  It's a problem when it interfaces with precious\nmetals and currency conversion.\n\nThe first step of being easy in one direction, bitcoin->LR or anything\nof established value, goes a long way.  Even those who don't use the\nconversion still benefit from knowing that they could.  Trading bitcoin\nbecomes an easier way to trade the ability to claim LR, similar to how\npaper money was once the right to claim gold.  Nobody has to ever\nactually claim the LR to get the benefit of having the option that they\ncould if they wanted to.\n\nA lot of times you just need a minuscule amount of online currency.  The\nhassle of buying the other online currencies is too much for buying a\nsmall amount.  The ease of getting a small amount of bitcoin may help\nbootstrap an ecosystem of sellers of micropayment sized online goods\nselling to that market.  If the sellers can get LR for bitcoins, they're\nhappy, and that may be subsidized at first by investors who want to buy\nbc in large lots.\n\nThe main thing holding online currencies back is the lack of an easy way\nto get a small amount of currency.  Bitcoin opens that up.  It'll be the\nonly online currency that's both easy to cash out and easy to get a\nsmall amount.  It'll just be the usual harder difficulty to buy a large\namount."],["q","Liberty Reserve sounds good. I could first make a service that only\naccepts LR, and add more options later. The weakness is that buying LR\nis an extra step of inconvenience when the customer just wants to get\nBitcoins. But maybe I don't have too much choice here.\n\n> Do you have electronic transfer or paper cheque in your country? (even\n> if only within Europe)\n\nYes, electronic bank transfer is available. During 2010 most European\ncountries will become a part of SEPA (Single Euro Payments Area), which\nmeans that all payments within Europe are to be considered domestic.\nBanks will have to apply the same fees and standards to all domestic\ntransfers, so they'll probably all be free of charge and complete in one\nbank day. For international transfers there's the SWIFT/IBAN system,\nwhich usually costs some extra.\n\nA longer term project for my exchange service would be to see what kinds\nof integration options the banks have to offer. Bank transfers would\nreach nearly as many customers as credit cards do.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-151","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Exchange options"},{"f":"mmalmi@cc.hut.fi","d":1266170352,"b":[["t","I'm moving in the direction of making transactions automated only when\nthe customer buys coins with SMS payment provided by ZayPay. Pecunix\nis the only reliable and practical enough e-currency that I'd store my\nreserves in, but the exchange fees are quite high (about 5%).\n\nWhen I'm buying coins, my recommended payment method would be IBAN\ntransfer. I could also say \"contact us if you want to buy/sell with\nany other payment option\" and handle each order separately. I could\nmanually accept single orders with even PayPal, as long as I don't\nstore my money there and the customer pays the fees."]],"u":"https://mmalmi.github.io/satoshi/#email-162","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Exchange options"}],"id":"x57"},{"k":"x","s":"martti-malmi","t":"Exchange ideas","u":"https://mmalmi.github.io/satoshi/#email-141","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265250010,"b":[["t","You could always exchange for Liberty Reserve.  It's an online currency\nsimilar to e-Bullion, Pecunix or Webmoney that allows exchanges no\nquestions asked and with privacy.\n\nLR and the others are hard to buy but easy to cash out.  Hard to buy\nbecause exchangers are very cautious about getting ripped off by\nreversed payments, so they require more details and holding time.\nCashing out is very easy.  LR is non-reversible, so there are oodles of\nexchanges eager to turn LR into any kind of payment.\n\nBitcoin is the reverse, in that it's easy to get Bitcoins just by\ngenerating them.  It would be easy for customers to go\nbitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they\njust want to save the money, then just bitcoin->LR.\n\nThere's also the idea BTC2PSC had to sell paysafecards for bitcoins.\nEither online delivery by sending the card number by e-mail, or delivery\nof the unopened physical card in the mails.  There are many variations\nof these cards.  In some countries, they're called Gift Cards, and can\nbe used wherever credit cards are accepted.  I think they're used more\nby people who don't have the credit history to get a real credit card,\nso they buy gift cards themselves to pay for things that require a\ncredit card."]],"u":"https://mmalmi.github.io/satoshi/#email-141","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x58"},{"k":"x","s":"martti-malmi","t":"UTF-8 to ANSI hack in CAboutDialog","u":"https://mmalmi.github.io/satoshi/#email-146","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265312006,"b":[["t","What was the reason for this change?\n\n#if !wxUSE_UNICODE\n...\n     if (str.Find('Â') != wxNOT_FOUND)\n         str.Remove(str.Find('Â'), 1);\nto:\n     if (str.Find('�') != wxNOT_FOUND)\n         str.Remove(str.Find('�'), 1);\n\nwxFormBuilder turns the (c) symbol into UTF-8 automatically.  On\nwxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash\ncharacter, which this hack fixes up for the non-unicode (ansi) case."]],"u":"https://mmalmi.github.io/satoshi/#email-146","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1265354183,"b":[["t","I didn't change it knowingly, must have been some encoding problem."],["q","What was the reason for this change?\n\n#if !wxUSE_UNICODE\n...\n    if (str.Find('Â') != wxNOT_FOUND)\n        str.Remove(str.Find('Â'), 1);\nto:\n    if (str.Find('�') != wxNOT_FOUND)\n        str.Remove(str.Find('�'), 1);\n\nwxFormBuilder turns the (c) symbol into UTF-8 automatically.  On\nwxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra\ntrash character, which this hack fixes up for the non-unicode (ansi)\ncase."]],"u":"https://mmalmi.github.io/satoshi/#email-149","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: UTF-8 to ANSI hack in CAboutDialog"},{"f":"Satoshi Nakamoto","d":1265395158,"b":[["t","Right, I'll change it to this so it doesn't get broken again:\n     if (str.Find('\\xC2') != wxNOT_FOUND)\n         str.Remove(str.Find('\\xC2'), 1);"],["q","I didn't change it knowingly, must have been some encoding problem.\n\n> What was the reason for this change?\n>\n> #if !wxUSE_UNICODE\n> ...\n>     if (str.Find('Â') != wxNOT_FOUND)\n>         str.Remove(str.Find('Â'), 1);\n> to:\n>     if (str.Find('�') != wxNOT_FOUND)\n>         str.Remove(str.Find('�'), 1);\n>\n> wxFormBuilder turns the (c) symbol into UTF-8 automatically.  On\n> wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra\n> trash character, which this hack fixes up for the non-unicode (ansi)\n> case.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-152","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: UTF-8 to ANSI hack in CAboutDialog"}],"id":"x59"},{"k":"x","s":"martti-malmi","t":"Re: Bitcoin API research status","u":"https://mmalmi.github.io/satoshi/#email-148","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265342934,"b":[["t","I noticed this in the docs for wxSocketServer::Accept(bool wait = true):\n\"If wait is true and there are no pending connections to be accepted, it\nwill wait for the next incoming connection to arrive.  **Warning: This\nwill block the GUI.\"\n\nwxWidgets is pathologically single-threaded.  Not only single-threaded,\nbut must-be-the-GUI-thread-ed.  Even for something as non-UI as\nwxStandardPaths I got nailed.  All this is fine for UI code, since this\nis the same constraint placed by Windows anyway, but for UI-less server\ndaemon code, wx calls are uncertain.\n\nStatus of my research currently:\n\nFor PHP, Python, etc to access the server, we need to use regular\nsockets.  I think we can make it local-only by binding to localhost\nonly, so it can only be accessed through the loopback.  They say it's\nalso watertight to simply check the IP of connections received and\ndisconnect anything not 127.0.0.1.  May as well do both.\n\nXML-RPC is a bit fat.  There are 4 libraries for C++ but they're all big\nand hard to build, dependencies, license issues.  Some posters complain\nall the C++ and PHP XML-RPC libraries are buggy.\n\nJSON-RPC is a simpler more elegant standard.  It's simple enough I could\nuse a generic JSON parser.\n\nPHP, Python and Java all have good implementations of JSON-RPC.\n\nI'm currently leaning towards JSON-RPC."]],"u":"https://mmalmi.github.io/satoshi/#email-148","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x60"},{"k":"x","s":"martti-malmi","t":"JSON-RPC status","u":"https://mmalmi.github.io/satoshi/#email-153","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265523124,"b":[["t","The JSON-RPC implementation is going well.  I'm using boost::asio for\nsockets.  JSON-RPC can be plain socket or HTTP, but it seems most other\nimplementations are HTTP, so I made my own simple HTTP headers.  For\nJSON parsing I'm using JSON Spirit, which makes full use of STL and has\nbeen really nice to use.  It's header-only so it's no added build work,\nand small enough to just add it to our source tree.  MIT license.  This\nshould all be working in a few more days.\n\nThe forum sure is taking off.  I didn't expect to have so much activity\nso fast."]],"u":"https://mmalmi.github.io/satoshi/#email-153","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1265539553,"b":[["t","That's great! I'll start familiarizing myself with Liberty Reserve and\nits api."],["q","The JSON-RPC implementation is going well.  I'm using boost::asio for\nsockets.  JSON-RPC can be plain socket or HTTP, but it seems most other\nimplementations are HTTP, so I made my own simple HTTP headers.  For\nJSON parsing I'm using JSON Spirit, which makes full use of STL and has\nbeen really nice to use.  It's header-only so it's no added build work,\nand small enough to just add it to our source tree.  MIT license.  This\nshould all be working in a few more days.\n\nThe forum sure is taking off.  I didn't expect to have so much activity\nso fast."]],"u":"https://mmalmi.github.io/satoshi/#email-154","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: JSON-RPC status"},{"f":"Satoshi Nakamoto","d":1266023322,"b":[["t","I uploaded my JSON-RPC and command line implementation to SVN.  I'm\nwaiting to post on the forum when I've had more time to think about the\ncommands.  At least some method names are going to change.\n\nTo enable the RPC server, add the switch -server.  It's not on by default.\n\nClient commands are without any switches, as such:\nbitcoin getblockcount\nbitcoin getdifficulty\nbitcoin getnewaddress somelabel\nbitcoin sendtoaddress 1DvqsbZ... 1.00\nbitcoin getallpayments 0\nbitcoin stop\n\nApplications would normally use JSON-RPC directly, not command line.\n\nI haven't tested my JSON-RPC server with anything else yet.  If you do,\nplease tell me how it goes.  You're using Python, right?\n\nGetting the Linux version to run without the GTK installed will be a\nseparate task."],["q","That's great! I'll start familiarizing myself with Liberty Reserve and\nits api.\n\n> The JSON-RPC implementation is going well.  I'm using boost::asio for\n> sockets.  JSON-RPC can be plain socket or HTTP, but it seems most other\n> implementations are HTTP, so I made my own simple HTTP headers.  For\n> JSON parsing I'm using JSON Spirit, which makes full use of STL and has\n> been really nice to use.  It's header-only so it's no added build work,\n> and small enough to just add it to our source tree.  MIT license.  This\n> should all be working in a few more days.\n>\n> The forum sure is taking off.  I didn't expect to have so much activity\n> so fast.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-160","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: JSON-RPC status"},{"f":"mmalmi@cc.hut.fi","d":1266170151,"b":[["q","I haven't tested my JSON-RPC server with anything else yet.  If you do,\nplease tell me how it goes.  You're using Python, right?\n\nGetting the Linux version to run without the GTK installed will be a\nseparate task."],["t","Yes, using Python. I didn't test the JSON-RPC yet as I don't have\nBitcoin running on the vps yet. It doesn't work without a window\nmanager even if GTK libraries are installed. I asked about it at\nwxWidgets forum (http://wxforum.shadonet.com/viewtopic.php?t=26954)\nbut they didn't have much clue. Maybe we'll just need to make two\ndifferent binaries."]],"u":"https://mmalmi.github.io/satoshi/#email-161","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: JSON-RPC status"},{"f":"Satoshi Nakamoto","d":1266184111,"b":[["q","> I haven't tested my JSON-RPC server with anything else yet.  If you do,\n> please tell me how it goes.  You're using Python, right?\n>\n> Getting the Linux version to run without the GTK installed will be a\n> separate task.\n\nYes, using Python. I didn't test the JSON-RPC yet as I don't have\nBitcoin running on the vps yet. It doesn't work without a window manager\neven if GTK libraries are installed. I asked about it at wxWidgets forum\n(http://wxforum.shadonet.com/viewtopic.php?t=26954) but they didn't have\nmuch clue. Maybe we'll just need to make two different binaries.","mmalmi@cc.hut.fi wrote:"],["t","I will probably relent and do that.  I can move init and shutdown into\ninit.cpp or start.cpp or something, link only wxbase and not link ui.o\nand uibase.o.\n\nwxWidgets is mostly Windows people, they wouldn't know much about GTK.\n\nDon't you have an Ubuntu laptop you can test and compile on so you don't\nhave to toy with the vps?"]],"u":"https://mmalmi.github.io/satoshi/#email-163","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: JSON-RPC status"},{"f":"mmalmi@cc.hut.fi","d":1266238834,"b":[["q","Don't you have an Ubuntu laptop you can test and compile on so you\ndon't have to toy with the vps?"],["t","Yes. Tested with Python's JSON-RPC, and seems to work fine! Really\neasy to use."]],"u":"https://mmalmi.github.io/satoshi/#email-164","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: JSON-RPC status"},{"f":"Satoshi Nakamoto","d":1266257513,"b":[["q","> Don't you have an Ubuntu laptop you can test and compile on so you\n> don't have to toy with the vps?\n\nYes. Tested with Python's JSON-RPC, and seems to work fine! Really easy\nto use.","mmalmi@cc.hut.fi wrote:"],["t","Hurray, I got it on the first go.\n\nCould you send me the Python code you used?  So if I do some testing\nlater I don't have to figure it out myself."]],"u":"https://mmalmi.github.io/satoshi/#email-165","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: JSON-RPC status"},{"f":"mmalmi@cc.hut.fi","d":1266258803,"b":[["q","mmalmi@cc.hut.fi wrote:\n>> Don't you have an Ubuntu laptop you can test and compile on so you\n>> don't have to toy with the vps?\n>\n> Yes. Tested with Python's JSON-RPC, and seems to work fine! Really\n> easy to use.\n\nHurray, I got it on the first go.\n\nCould you send me the Python code you used?  So if I do some testing\nlater I don't have to figure it out myself."],["t","Just downloaded the python-json-rpc\n(http://json-rpc.org/wiki/python-json-rpc) from their svn and tested\nby talking to the Python interpreter directly. Like this:\n\npythons = ServiceProxy(\"http://localhost:8332\")\ns.getblockcount()"]],"u":"https://mmalmi.github.io/satoshi/#email-166","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: JSON-RPC status"}],"id":"x61"},{"k":"x","s":"martti-malmi","t":"Translation","u":"https://mmalmi.github.io/satoshi/#email-155","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1265642932,"b":[["t","Does Drupal have any special multi-language support, or do you just\ncreate copies of pages by hand?\n\nBlueSky offered to do translation on the forum.  If you create a\nwww.bitcoin.org/zh/ copy of the site and give him an account with just\nthe ability to create new pages and edit text, he'll probably translate\nthe site into Chinese for you and maybe maintain it."]],"u":"https://mmalmi.github.io/satoshi/#email-155","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1265730126,"b":[["t","Drupal supports multiple languages. I didn't yet figure out how to\nmake it automatically show the translation at bitcoin.org/zh-hans\nthough."],["q","Does Drupal have any special multi-language support, or do you just\ncreate copies of pages by hand?\n\nBlueSky offered to do translation on the forum.  If you create a\nwww.bitcoin.org/zh/ copy of the site and give him an account with just\nthe ability to create new pages and edit text, he'll probably translate\nthe site into Chinese for you and maybe maintain it."]],"u":"https://mmalmi.github.io/satoshi/#email-156","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Translation"},{"f":"mmalmi@cc.hut.fi","d":1265914212,"b":[["t","I got the translations working correctly, now it should automatically\ndetect the language from the browser settings. Choosing manually is of\ncourse also possible. I asked the translators to send me their\ntranslations as pm or e-mail. I guess I'll make a Finnish translation\nmyself at some point. Multiple translations add to the site's\ncredibility.\n\nDrupal is asking to do a security update. Do we have other customized\nfiles we need to backup than those located in the \"sites\" directory?"]],"u":"https://mmalmi.github.io/satoshi/#email-157","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Translation"},{"f":"Satoshi Nakamoto","d":1265929109,"b":[["t","I didn't make any changes to Drupal code.  The only thing other than\ninstalling themes was the .htaccess file (which really is needed, it\ndidn't work in the global config file).\n\nIt was only SMF where I made some PHP changes.\n\nYou might find it preferable not to translate it into your own language.\n  Often the standard answer about legalities is that it's only intended\nfor people in other countries.  Translating it into your home language\nweakens that argument."],["q","I got the translations working correctly, now it should automatically\ndetect the language from the browser settings. Choosing manually is of\ncourse also possible. I asked the translators to send me their\ntranslations as pm or e-mail. I guess I'll make a Finnish translation\nmyself at some point. Multiple translations add to the site's credibility.\n\nDrupal is asking to do a security update. Do we have other customized\nfiles we need to backup than those located in the \"sites\" directory?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-158","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Translation"},{"f":"mmalmi@cc.hut.fi","d":1265969203,"b":[["t","I'm not too worried about that, since I'm not doing anything illegal,\neven with my exchange service. If I were, it wouldn't help me that I'm\nonly offering the service for foreigners. Things may of course be\ndifferent under other jurisdictions, but that's how it is in my\ncountry. The law monopoly here is less uncivilized than many others."],["q","You might find it preferable not to translate it into your own\nlanguage.  Often the standard answer about legalities is that it's only\nintended for people in other countries.  Translating it into your home\nlanguage weakens that argument."]],"u":"https://mmalmi.github.io/satoshi/#email-159","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Translation"}],"id":"x62"},{"k":"x","s":"martti-malmi","t":"Non-GUI option","u":"https://mmalmi.github.io/satoshi/#email-167","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1266427924,"b":[["t","Just a few clues I've found about running the same binary without a GUI:\n\n1) GTK supports running a program without display:\nhttp://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check. This\ndoesn't tell if it's possible in wxWidgets though.\n\n2) wxAppConsole of wx 2.9 might be useful somehow. Just replacing\nwxApp with wxAppConsole doesn't work, I'm not sure how it should be\nused. It's not very well documented.\n\n3) Another option might be to use IMPLEMENT_APP_NO_MAIN() and make our\nown main method."]],"u":"https://mmalmi.github.io/satoshi/#email-167","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1266869862,"b":[["q","Just a few clues I've found about running the same binary without a GUI:\n\n1) GTK supports running a program without display:\nhttp://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.\nThis doesn't tell if it's possible in wxWidgets though.","mmalmi@cc.hut.fi wrote:"],["t","I see it calls gtk-init-check in wxApp::Initialize.\n\nI can subclass Initialize, call the original one while suppressing the\nerror message and ignore the return value.  It seems to be working.\n\nAny suggestions what to name the command line switches and how to\ndescribe them?  Is there any traditional standard?  I'm currently using:\n-daemon (or -d)   (Enables RPC and runs in the background)\n-server           (Enables RPC)"]],"u":"https://mmalmi.github.io/satoshi/#email-168","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Non-GUI option"},{"f":"Satoshi Nakamoto","d":1266889261,"b":[["q","> Just a few clues I've found about running the same binary without a GUI:\n>\n> 1) GTK supports running a program without display:\n> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.\n> This doesn't tell if it's possible in wxWidgets though.\n\nI see it calls gtk-init-check in wxApp::Initialize.\n\nI can subclass Initialize, call the original one while suppressing the\nerror message and ignore the return value.  It seems to be working."],["t","This is working.  A few more things and I'll upload it.\n\nWe'll need to tell people to install the GTK libraries.  Do you remember\nthe apt-get command to install GTK, and can you install it without\nhaving a GUI installed?"]],"u":"https://mmalmi.github.io/satoshi/#email-169","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Non-GUI option"},{"f":"mmalmi@cc.hut.fi","d":1266931191,"b":[["q","mmalmi@cc.hut.fi wrote:\n> Just a few clues I've found about running the same binary without a GUI:\n>\n> 1) GTK supports running a program without display:\n> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.\n> This doesn't tell if it's possible in wxWidgets though.\n\nI see it calls gtk-init-check in wxApp::Initialize.\n\nI can subclass Initialize, call the original one while suppressing the\nerror message and ignore the return value.  It seems to be working.\n\nAny suggestions what to name the command line switches and how to\ndescribe them?  Is there any traditional standard?  I'm currently using:\n-daemon (or -d)   (Enables RPC and runs in the background)\n-server           (Enables RPC)"],["t","That seems good, I don't know of any standards about it."]],"u":"https://mmalmi.github.io/satoshi/#email-170","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Non-GUI option"},{"f":"mmalmi@cc.hut.fi","d":1266936479,"b":[["q",">> Just a few clues I've found about running the same binary without a GUI:\n>>\n>> 1) GTK supports running a program without display:\n>> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.\n>> This doesn't tell if it's possible in wxWidgets though.\n>\n> I see it calls gtk-init-check in wxApp::Initialize.\n>\n> I can subclass Initialize, call the original one while suppressing\n> the error message and ignore the return value.  It seems to be\n> working.\n\nThis is working.  A few more things and I'll upload it.\n\nWe'll need to tell people to install the GTK libraries.  Do you\nremember the apt-get command to install GTK, and can you install it\nwithout having a GUI installed?"],["t","It was probably apt-get install libgtk2.0-0. You can search for\navailable packages like this: \"apt-cache search libgtk\".\n\nI'll give Drupal accounts to the bitcoin.org translators, so they can\nkeep the translations up to date."]],"u":"https://mmalmi.github.io/satoshi/#email-171","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Non-GUI option"},{"f":"Satoshi Nakamoto","d":1266993292,"b":[["q","I'll give Drupal accounts to the bitcoin.org translators, so they can\nkeep the translations up to date."],["t","Good, that gives them a little sense of ownership and responsibility.\n\nI hope we get at least one .mo file for the software translation in time\nto put into the 0.3 release."]],"u":"https://mmalmi.github.io/satoshi/#email-172","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Non-GUI option"}],"id":"x63"},{"k":"x","s":"martti-malmi","t":"Bitcoind","u":"https://mmalmi.github.io/satoshi/#email-173","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1267330364,"b":[["t","I tried debugging my build of bitcoind with ddd debugger, but didn't\nhave much success yet. It always ends up taking all the system's\nmemory and finally crashes. Could you please send me again the latest\n64 bit build of bitcoind, so I can see if the problem is about my build?"]],"u":"https://mmalmi.github.io/satoshi/#email-173","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1267368421,"b":[["t","I put it at bitcoin.org/download/linux64-0.2.7.1.tar.gz.  You can delete\nit when you've got it.\n\nI thought about what might cause the problem you're having and made a\nchange that this build includes.  This might have been unsafe code,\nalthough it would probably always get lucky.\n\nin util.cpp, old:\nconst char* wxGetTranslation(const char* pszEnglish)\n{\n     // Wrapper of wxGetTranslation returning the same const char* type\nas was passed in\n     static CCriticalSection cs;\n     CRITICAL_BLOCK(cs)\n     {\n         // Look in cache\n         static map<string, char*> mapCache;\n         map<string, char*>::iterator mi = mapCache.find(pszEnglish);\n         if (mi != mapCache.end())\n             return (*mi).second;\n\n         // wxWidgets translation\n         const char* pszTranslated =\nwxGetTranslation(wxString(pszEnglish, wxConvUTF8)).utf8_str();\n\n         // We don't cache unknown strings because caller might be\npassing in a\n         // dynamic string and we would keep allocating memory for each\nvariation.\n         if (strcmp(pszEnglish, pszTranslated) == 0)\n             return pszEnglish;\n\n         // Add to cache, memory doesn't need to be freed.  We only\ncache because\n         // we must pass back a pointer to permanently allocated memory.\n         char* pszCached = new char[strlen(pszTranslated)+1];\n         strcpy(pszCached, pszTranslated);\n         mapCache[pszEnglish] = pszCached;\n         return pszCached;\n     }\n     return NULL;\n}\n\nnew:\nconst char* wxGetTranslation(const char* pszEnglish)\n{\n     // Wrapper of wxGetTranslation returning the same const char* type\nas was passed in\n     static CCriticalSection cs;\n     CRITICAL_BLOCK(cs)\n     {\n         // Look in cache\n         static map<string, char*> mapCache;\n         map<string, char*>::iterator mi = mapCache.find(pszEnglish);\n         if (mi != mapCache.end())\n             return (*mi).second;\n\n         // wxWidgets translation\n         wxString strTranslated = wxGetTranslation(wxString(pszEnglish,\nwxConvUTF8));\n\n         // We don't cache unknown strings because caller might be\npassing in a\n         // dynamic string and we would keep allocating memory for each\nvariation.\n         if (strcmp(pszEnglish, strTranslated.utf8_str()) == 0)\n             return pszEnglish;\n\n         // Add to cache, memory doesn't need to be freed.  We only\ncache because\n         // we must pass back a pointer to permanently allocated memory.\n         char* pszCached = new char[strlen(strTranslated.utf8_str())+1];\n         strcpy(pszCached, strTranslated.utf8_str());\n         mapCache[pszEnglish] = pszCached;\n         return pszCached;\n     }\n     return NULL;\n}\n\nIf you still suspect this code, for testing you could change it to:\nconst char* wxGetTranslation(const char* pszEnglish)\n{\n     return pszEnglish;\n}"],["q","I tried debugging my build of bitcoind with ddd debugger, but didn't\nhave much success yet. It always ends up taking all the system's memory\nand finally crashes. Could you please send me again the latest 64 bit\nbuild of bitcoind, so I can see if the problem is about my build?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-174","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267387747,"b":[["t","Could you send me the debug.log?"],["q","I tried debugging my build of bitcoind with ddd debugger, but didn't\nhave much success yet. It always ends up taking all the system's memory\nand finally crashes. Could you please send me again the latest 64 bit\nbuild of bitcoind, so I can see if the problem is about my build?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-175","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267558404,"b":[["t","Here goes. I forgot to mention the crash error message:\n\nterminate called after throwing an instance of 'std::bad_alloc'\nwhat():  std::bad_alloc"],["q","Could you send me the debug.log?\n\nmmalmi@cc.hut.fi wrote:\n> I tried debugging my build of bitcoind with ddd debugger, but\n> didn't have much success yet. It always ends up taking all the\n> system's memory and finally crashes. Could you please send me again\n>  the latest 64 bit build of bitcoind, so I can see if the problem\n> is  about my build?\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-176","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267558570,"b":[["t","This was from the compilation you sent, the same problem occurred with it."],["q","Here goes. I forgot to mention the crash error message:\n\nterminate called after throwing an instance of 'std::bad_alloc'\nwhat():  std::bad_alloc\n\n> Could you send me the debug.log?\n>\n> mmalmi@cc.hut.fi wrote:\n>> I tried debugging my build of bitcoind with ddd debugger, but\n>> didn't have much success yet. It always ends up taking all the\n>> system's memory and finally crashes. Could you please send me\n>> again   the latest 64 bit build of bitcoind, so I can see if the\n>> problem  is  about my build?\n>>"]],"u":"https://mmalmi.github.io/satoshi/#email-177","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267568842,"b":[["t","Does it still do it if you didn't do getinfo?\n\nYou could comment out the CreateThreads listed below, then re-enable\nthem one at a time until it does it again.  Then we would know which\nthread the problem is in.\n\nnet.cpp, under // Start threads\n     CreateThread(ThreadIRCSeed, NULL)\n     CreateThread(ThreadSocketHandler, NULL, true)\n     CreateThread(ThreadOpenConnections, NULL)\n     CreateThread(ThreadMessageHandler, NULL)\n\ninit.cpp:\n     CreateThread(ThreadRPCServer, NULL);"],["q","Here goes. I forgot to mention the crash error message:\n\nterminate called after throwing an instance of 'std::bad_alloc'\nwhat():  std::bad_alloc\n\n> Could you send me the debug.log?\n>\n> mmalmi@cc.hut.fi wrote:\n>> I tried debugging my build of bitcoind with ddd debugger, but  didn't\n>> have much success yet. It always ends up taking all the  system's\n>> memory and finally crashes. Could you please send me again  the\n>> latest 64 bit build of bitcoind, so I can see if the problem is\n>> about my build?\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-178","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267581039,"b":[["t","I get the error regardless of the getinfo. Commenting out\nThreadIRCSeed fixed the problem."],["q","Does it still do it if you didn't do getinfo?\n\nYou could comment out the CreateThreads listed below, then re-enable\nthem one at a time until it does it again.  Then we would know which\nthread the problem is in.\n\nnet.cpp, under // Start threads\n    CreateThread(ThreadIRCSeed, NULL)\n    CreateThread(ThreadSocketHandler, NULL, true)\n    CreateThread(ThreadOpenConnections, NULL)\n    CreateThread(ThreadMessageHandler, NULL)\n\ninit.cpp:\n    CreateThread(ThreadRPCServer, NULL);\n\nmmalmi@cc.hut.fi wrote:\n> Here goes. I forgot to mention the crash error message:\n>\n> terminate called after throwing an instance of 'std::bad_alloc'\n> what():  std::bad_alloc\n>\n>> Could you send me the debug.log?\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>> didn't have much success yet. It always ends up taking all the\n>>> system's memory and finally crashes. Could you please send me\n>>> again  the latest 64 bit build of bitcoind, so I can see if the\n>>> problem is  about my build?\n>>>\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-179","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267588492,"b":[["t","That narrows it down a lot.  It didn't print any IRC activity in\ndebug.log, so I guess it couldn't have gotten past the RecvUntil.\nEyeballing it I don't see anything obvious.  I guess it would have to be\neither in ConnectSocket or RecvUntil.\n\nTry it with the attached irc.cpp and net.cpp and send me the debug.log.\n\nOr you could run it in gdb and step through ThreadIRCSeed\ngdb --args bitcoin [switches]\nb ThreadIRCSeed\nrun\nstep\nor u to step over and up out of routines."],["q","I get the error regardless of the getinfo. Commenting out ThreadIRCSeed\nfixed the problem.\n\n> Does it still do it if you didn't do getinfo?\n>\n> You could comment out the CreateThreads listed below, then re-enable\n> them one at a time until it does it again.  Then we would know which\n> thread the problem is in.\n>\n> net.cpp, under // Start threads\n>     CreateThread(ThreadIRCSeed, NULL)\n>     CreateThread(ThreadSocketHandler, NULL, true)\n>     CreateThread(ThreadOpenConnections, NULL)\n>     CreateThread(ThreadMessageHandler, NULL)\n>\n> init.cpp:\n>     CreateThread(ThreadRPCServer, NULL);\n>\n> mmalmi@cc.hut.fi wrote:\n>> Here goes. I forgot to mention the crash error message:\n>>\n>> terminate called after throwing an instance of 'std::bad_alloc'\n>> what():  std::bad_alloc\n>>\n>>> Could you send me the debug.log?\n>>>\n>>> mmalmi@cc.hut.fi wrote:\n>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>> didn't have much success yet. It always ends up taking all the\n>>>> system's memory and finally crashes. Could you please send me\n>>>> again  the latest 64 bit build of bitcoind, so I can see if the\n>>>> problem is  about my build?\n>>>>\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-180","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267619521,"b":[["t","debug.log attached"],["q","That narrows it down a lot.  It didn't print any IRC activity in\ndebug.log, so I guess it couldn't have gotten past the RecvUntil.\nEyeballing it I don't see anything obvious.  I guess it would have to\nbe either in ConnectSocket or RecvUntil.\n\nTry it with the attached irc.cpp and net.cpp and send me the debug.log.\n\nOr you could run it in gdb and step through ThreadIRCSeed\ngdb --args bitcoin [switches]\nb ThreadIRCSeed\nrun\nstep\nor u to step over and up out of routines.\n\nmmalmi@cc.hut.fi wrote:\n> I get the error regardless of the getinfo. Commenting out\n> ThreadIRCSeed fixed the problem.\n>\n>> Does it still do it if you didn't do getinfo?\n>>\n>> You could comment out the CreateThreads listed below, then re-enable\n>> them one at a time until it does it again.  Then we would know which\n>> thread the problem is in.\n>>\n>> net.cpp, under // Start threads\n>>    CreateThread(ThreadIRCSeed, NULL)\n>>    CreateThread(ThreadSocketHandler, NULL, true)\n>>    CreateThread(ThreadOpenConnections, NULL)\n>>    CreateThread(ThreadMessageHandler, NULL)\n>>\n>> init.cpp:\n>>    CreateThread(ThreadRPCServer, NULL);\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> Here goes. I forgot to mention the crash error message:\n>>>\n>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>> what():  std::bad_alloc\n>>>\n>>>> Could you send me the debug.log?\n>>>>\n>>>> mmalmi@cc.hut.fi wrote:\n>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>  didn't have much success yet. It always ends up taking all the\n>>>>>    system's memory and finally crashes. Could you please send\n>>>>> me   again  the latest 64 bit build of bitcoind, so I can see\n>>>>> if the   problem is  about my build?\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-181","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267636528,"b":[["t","It's in RecvUntil, but I still can't see anything wrong with it.  The\nonly thing I can think of is if the socket is receiving a spew of\ncharacters.\n\nTry this irc.cpp.  debug.log may grow rapidly so be ready to kill it."],["q","debug.log attached\n\n> That narrows it down a lot.  It didn't print any IRC activity in\n> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n> Eyeballing it I don't see anything obvious.  I guess it would have to\n> be either in ConnectSocket or RecvUntil.\n>\n> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>\n> Or you could run it in gdb and step through ThreadIRCSeed\n> gdb --args bitcoin [switches]\n> b ThreadIRCSeed\n> run\n> step\n> or u to step over and up out of routines.\n>\n> mmalmi@cc.hut.fi wrote:\n>> I get the error regardless of the getinfo. Commenting out\n>> ThreadIRCSeed fixed the problem.\n>>\n>>> Does it still do it if you didn't do getinfo?\n>>>\n>>> You could comment out the CreateThreads listed below, then re-enable\n>>> them one at a time until it does it again.  Then we would know which\n>>> thread the problem is in.\n>>>\n>>> net.cpp, under // Start threads\n>>>    CreateThread(ThreadIRCSeed, NULL)\n>>>    CreateThread(ThreadSocketHandler, NULL, true)\n>>>    CreateThread(ThreadOpenConnections, NULL)\n>>>    CreateThread(ThreadMessageHandler, NULL)\n>>>\n>>> init.cpp:\n>>>    CreateThread(ThreadRPCServer, NULL);\n>>>\n>>> mmalmi@cc.hut.fi wrote:\n>>>> Here goes. I forgot to mention the crash error message:\n>>>>\n>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>> what():  std::bad_alloc\n>>>>\n>>>>> Could you send me the debug.log?\n>>>>>\n>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>  didn't have much success yet. It always ends up taking all the\n>>>>>>    system's memory and finally crashes. Could you please send\n>>>>>> me   again  the latest 64 bit build of bitcoind, so I can see if\n>>>>>> the   problem is  about my build?\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-182","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267741628,"b":[["t","Here's the debug.log. I stopped bitcoind before it took up all the memory."],["q","It's in RecvUntil, but I still can't see anything wrong with it.  The\nonly thing I can think of is if the socket is receiving a spew of\ncharacters.\n\nTry this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n\nmmalmi@cc.hut.fi wrote:\n> debug.log attached\n>\n>> That narrows it down a lot.  It didn't print any IRC activity in\n>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>> be either in ConnectSocket or RecvUntil.\n>>\n>> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>>\n>> Or you could run it in gdb and step through ThreadIRCSeed\n>> gdb --args bitcoin [switches]\n>> b ThreadIRCSeed\n>> run\n>> step\n>> or u to step over and up out of routines.\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> I get the error regardless of the getinfo. Commenting out\n>>> ThreadIRCSeed fixed the problem.\n>>>\n>>>> Does it still do it if you didn't do getinfo?\n>>>>\n>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>> them one at a time until it does it again.  Then we would know which\n>>>> thread the problem is in.\n>>>>\n>>>> net.cpp, under // Start threads\n>>>>   CreateThread(ThreadIRCSeed, NULL)\n>>>>   CreateThread(ThreadSocketHandler, NULL, true)\n>>>>   CreateThread(ThreadOpenConnections, NULL)\n>>>>   CreateThread(ThreadMessageHandler, NULL)\n>>>>\n>>>> init.cpp:\n>>>>   CreateThread(ThreadRPCServer, NULL);\n>>>>\n>>>> mmalmi@cc.hut.fi wrote:\n>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>\n>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>> what():  std::bad_alloc\n>>>>>\n>>>>>> Could you send me the debug.log?\n>>>>>>\n>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>>     didn't have much success yet. It always ends up taking\n>>>>>>> all  the   system's memory and finally crashes. Could you\n>>>>>>> please  send me   again  the latest 64 bit build of bitcoind,\n>>>>>>> so I  can see if the  problem is  about my build?\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-183","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267747742,"b":[["t","Here's another test run debug.log I got when debugging with gdb. The\nprogram started eating memory after the debug line \"irc 8\" and within\na few seconds crashed with \"terminate called after throwing an\ninstance of 'std::bad_alloc'\"."],["q","It's in RecvUntil, but I still can't see anything wrong with it.  The\nonly thing I can think of is if the socket is receiving a spew of\ncharacters.\n\nTry this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n\nmmalmi@cc.hut.fi wrote:\n> debug.log attached\n>\n>> That narrows it down a lot.  It didn't print any IRC activity in\n>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>> be either in ConnectSocket or RecvUntil.\n>>\n>> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>>\n>> Or you could run it in gdb and step through ThreadIRCSeed\n>> gdb --args bitcoin [switches]\n>> b ThreadIRCSeed\n>> run\n>> step\n>> or u to step over and up out of routines.\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> I get the error regardless of the getinfo. Commenting out\n>>> ThreadIRCSeed fixed the problem.\n>>>\n>>>> Does it still do it if you didn't do getinfo?\n>>>>\n>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>> them one at a time until it does it again.  Then we would know which\n>>>> thread the problem is in.\n>>>>\n>>>> net.cpp, under // Start threads\n>>>>   CreateThread(ThreadIRCSeed, NULL)\n>>>>   CreateThread(ThreadSocketHandler, NULL, true)\n>>>>   CreateThread(ThreadOpenConnections, NULL)\n>>>>   CreateThread(ThreadMessageHandler, NULL)\n>>>>\n>>>> init.cpp:\n>>>>   CreateThread(ThreadRPCServer, NULL);\n>>>>\n>>>> mmalmi@cc.hut.fi wrote:\n>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>\n>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>> what():  std::bad_alloc\n>>>>>\n>>>>>> Could you send me the debug.log?\n>>>>>>\n>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>>     didn't have much success yet. It always ends up taking\n>>>>>>> all  the   system's memory and finally crashes. Could you\n>>>>>>> please  send me   again  the latest 64 bit build of bitcoind,\n>>>>>>> so I  can see if the  problem is  about my build?\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-184","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267749736,"b":[["t","It's in util.c ParseString.  I'm guessing the problem is incompatibility\nbetween the type \"unsigned int\" and the type of str.npos, which is\nsize_type.\n\nTry changing the two \"unsigned int\"s to \"size_type\".\n\nold:\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n     unsigned int i1 = 0;\n     unsigned int i2;\n     do\n     {\n         i2 = str.find(c, i1);\n         v.push_back(str.substr(i1, i2-i1));\n         i1 = i2+1;\n     }\n     while (i2 != str.npos);\n}\n\nnew:\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n     size_type i1 = 0;\n     size_type i2;\n     do\n     {\n         i2 = str.find(c, i1);\n         v.push_back(str.substr(i1, i2-i1));\n         i1 = i2+1;\n     }\n     while (i2 != str.npos);\n}"],["q","Here's another test run debug.log I got when debugging with gdb. The\nprogram started eating memory after the debug line \"irc 8\" and within a\nfew seconds crashed with \"terminate called after throwing an instance of\n'std::bad_alloc'\".\n\n> It's in RecvUntil, but I still can't see anything wrong with it.  The\n> only thing I can think of is if the socket is receiving a spew of\n> characters.\n>\n> Try this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n>\n> mmalmi@cc.hut.fi wrote:\n>> debug.log attached\n>>\n>>> That narrows it down a lot.  It didn't print any IRC activity in\n>>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>>> be either in ConnectSocket or RecvUntil.\n>>>\n>>> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>>>\n>>> Or you could run it in gdb and step through ThreadIRCSeed\n>>> gdb --args bitcoin [switches]\n>>> b ThreadIRCSeed\n>>> run\n>>> step\n>>> or u to step over and up out of routines.\n>>>\n>>> mmalmi@cc.hut.fi wrote:\n>>>> I get the error regardless of the getinfo. Commenting out\n>>>> ThreadIRCSeed fixed the problem.\n>>>>\n>>>>> Does it still do it if you didn't do getinfo?\n>>>>>\n>>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>>> them one at a time until it does it again.  Then we would know which\n>>>>> thread the problem is in.\n>>>>>\n>>>>> net.cpp, under // Start threads\n>>>>>   CreateThread(ThreadIRCSeed, NULL)\n>>>>>   CreateThread(ThreadSocketHandler, NULL, true)\n>>>>>   CreateThread(ThreadOpenConnections, NULL)\n>>>>>   CreateThread(ThreadMessageHandler, NULL)\n>>>>>\n>>>>> init.cpp:\n>>>>>   CreateThread(ThreadRPCServer, NULL);\n>>>>>\n>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>>\n>>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>>> what():  std::bad_alloc\n>>>>>>\n>>>>>>> Could you send me the debug.log?\n>>>>>>>\n>>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>>>     didn't have much success yet. It always ends up taking all\n>>>>>>>> the   system's memory and finally crashes. Could you please\n>>>>>>>> send me   again  the latest 64 bit build of bitcoind, so I  can\n>>>>>>>> see if the  problem is  about my build?\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-185","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267750480,"b":[["t","Actually, please try this instead, this is more correct:\n\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n     string::size_type i1 = 0;\n     string::size_type i2;\n     loop\n     {\n         i2 = str.find(c, i1);\n         if (i2 == str.npos)\n         {\n             v.push_back(str.substr(i1));\n             return;\n         }\n         v.push_back(str.substr(i1, i2-i1));\n         i1 = i2+1;\n     }\n}"],["q","It's in util.c ParseString.  I'm guessing the problem is incompatibility\nbetween the type \"unsigned int\" and the type of str.npos, which is\nsize_type.\n\nTry changing the two \"unsigned int\"s to \"size_type\".\n\nold:\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n    unsigned int i1 = 0;\n    unsigned int i2;\n    do\n    {\n        i2 = str.find(c, i1);\n        v.push_back(str.substr(i1, i2-i1));\n        i1 = i2+1;\n    }\n    while (i2 != str.npos);\n}\n\nnew:\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n    size_type i1 = 0;\n    size_type i2;\n    do\n    {\n        i2 = str.find(c, i1);\n        v.push_back(str.substr(i1, i2-i1));\n        i1 = i2+1;\n    }\n    while (i2 != str.npos);\n}\n\nmmalmi@cc.hut.fi wrote:\n> Here's another test run debug.log I got when debugging with gdb. The\n> program started eating memory after the debug line \"irc 8\" and within\n> a few seconds crashed with \"terminate called after throwing an\n> instance of 'std::bad_alloc'\".\n>\n>> It's in RecvUntil, but I still can't see anything wrong with it.  The\n>> only thing I can think of is if the socket is receiving a spew of\n>> characters.\n>>\n>> Try this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n>>\n>> mmalmi@cc.hut.fi wrote:\n>>> debug.log attached\n>>>\n>>>> That narrows it down a lot.  It didn't print any IRC activity in\n>>>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>>>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>>>> be either in ConnectSocket or RecvUntil.\n>>>>\n>>>> Try it with the attached irc.cpp and net.cpp and send me the\n>>>> debug.log.\n>>>>\n>>>> Or you could run it in gdb and step through ThreadIRCSeed\n>>>> gdb --args bitcoin [switches]\n>>>> b ThreadIRCSeed\n>>>> run\n>>>> step\n>>>> or u to step over and up out of routines.\n>>>>\n>>>> mmalmi@cc.hut.fi wrote:\n>>>>> I get the error regardless of the getinfo. Commenting out\n>>>>> ThreadIRCSeed fixed the problem.\n>>>>>\n>>>>>> Does it still do it if you didn't do getinfo?\n>>>>>>\n>>>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>>>> them one at a time until it does it again.  Then we would know which\n>>>>>> thread the problem is in.\n>>>>>>\n>>>>>> net.cpp, under // Start threads\n>>>>>>   CreateThread(ThreadIRCSeed, NULL)\n>>>>>>   CreateThread(ThreadSocketHandler, NULL, true)\n>>>>>>   CreateThread(ThreadOpenConnections, NULL)\n>>>>>>   CreateThread(ThreadMessageHandler, NULL)\n>>>>>>\n>>>>>> init.cpp:\n>>>>>>   CreateThread(ThreadRPCServer, NULL);\n>>>>>>\n>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>>>\n>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>>>> what():  std::bad_alloc\n>>>>>>>\n>>>>>>>> Could you send me the debug.log?\n>>>>>>>>\n>>>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>>>>     didn't have much success yet. It always ends up taking\n>>>>>>>>> all  the   system's memory and finally crashes. Could you\n>>>>>>>>> please  send me   again  the latest 64 bit build of bitcoind,\n>>>>>>>>> so I  can see if the  problem is  about my build?\n>>>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>>>\n>>>>>\n>>>>>\n>>>>>\n>>>\n>>>\n>>>\n>\n>\n>","Satoshi Nakamoto wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-186","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"},{"f":"mmalmi@cc.hut.fi","d":1267752814,"b":[["t","Great! Works fine now."],["q","Actually, please try this instead, this is more correct:\n\nvoid ParseString(const string& str, char c, vector<string>& v)\n{\n    string::size_type i1 = 0;\n    string::size_type i2;\n    loop\n    {\n        i2 = str.find(c, i1);\n        if (i2 == str.npos)\n        {\n            v.push_back(str.substr(i1));\n            return;\n        }\n        v.push_back(str.substr(i1, i2-i1));\n        i1 = i2+1;\n    }\n}\n\nSatoshi Nakamoto wrote:\n> It's in util.c ParseString.  I'm guessing the problem is\n> incompatibility between the type \"unsigned int\" and the type of\n> str.npos, which is size_type.\n>\n> Try changing the two \"unsigned int\"s to \"size_type\".\n>\n> old:\n> void ParseString(const string& str, char c, vector<string>& v)\n> {\n>    unsigned int i1 = 0;\n>    unsigned int i2;\n>    do\n>    {\n>        i2 = str.find(c, i1);\n>        v.push_back(str.substr(i1, i2-i1));\n>        i1 = i2+1;\n>    }\n>    while (i2 != str.npos);\n> }\n>\n> new:\n> void ParseString(const string& str, char c, vector<string>& v)\n> {\n>    size_type i1 = 0;\n>    size_type i2;\n>    do\n>    {\n>        i2 = str.find(c, i1);\n>        v.push_back(str.substr(i1, i2-i1));\n>        i1 = i2+1;\n>    }\n>    while (i2 != str.npos);\n> }\n>\n>\n> mmalmi@cc.hut.fi wrote:\n>> Here's another test run debug.log I got when debugging with gdb.\n>> The program started eating memory after the debug line \"irc 8\" and\n>>  within a few seconds crashed with \"terminate called after\n>> throwing  an instance of 'std::bad_alloc'\".\n>>\n>>> It's in RecvUntil, but I still can't see anything wrong with it.  The\n>>> only thing I can think of is if the socket is receiving a spew of\n>>> characters.\n>>>\n>>> Try this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n>>>\n>>> mmalmi@cc.hut.fi wrote:\n>>>> debug.log attached\n>>>>\n>>>>> That narrows it down a lot.  It didn't print any IRC activity in\n>>>>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>>>>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>>>>> be either in ConnectSocket or RecvUntil.\n>>>>>\n>>>>> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>>>>>\n>>>>> Or you could run it in gdb and step through ThreadIRCSeed\n>>>>> gdb --args bitcoin [switches]\n>>>>> b ThreadIRCSeed\n>>>>> run\n>>>>> step\n>>>>> or u to step over and up out of routines.\n>>>>>\n>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>> I get the error regardless of the getinfo. Commenting out\n>>>>>> ThreadIRCSeed fixed the problem.\n>>>>>>\n>>>>>>> Does it still do it if you didn't do getinfo?\n>>>>>>>\n>>>>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>>>>> them one at a time until it does it again.  Then we would know which\n>>>>>>> thread the problem is in.\n>>>>>>>\n>>>>>>> net.cpp, under // Start threads\n>>>>>>>  CreateThread(ThreadIRCSeed, NULL)\n>>>>>>>  CreateThread(ThreadSocketHandler, NULL, true)\n>>>>>>>  CreateThread(ThreadOpenConnections, NULL)\n>>>>>>>  CreateThread(ThreadMessageHandler, NULL)\n>>>>>>>\n>>>>>>> init.cpp:\n>>>>>>>  CreateThread(ThreadRPCServer, NULL);\n>>>>>>>\n>>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>>>>\n>>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>>>>> what():  std::bad_alloc\n>>>>>>>>\n>>>>>>>>> Could you send me the debug.log?\n>>>>>>>>>\n>>>>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger,\n>>>>>>>>>> but    didn't have much success yet. It always ends up\n>>>>>>>>>> taking all  the   system's memory and finally crashes.\n>>>>>>>>>> Could you please  send me   again  the latest 64 bit build\n>>>>>>>>>>  of bitcoind, so I  can see if the  problem is  about my\n>>>>>>>>>> build?\n>>>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-187","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoind"},{"f":"Satoshi Nakamoto","d":1267753320,"b":[["t","I confirmed that ParseString has this problem, and uploaded the fixed\nutil.cpp to SVN.\n\nstring::npos == -1\n\nComparing unsigned int -1 (0xffffffff) with long unsigned int -1\n(0xffffffffffffffff) results in the unsigned int being promoted to\n64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff."],["q","Here's another test run debug.log I got when debugging with gdb. The\nprogram started eating memory after the debug line \"irc 8\" and within a\nfew seconds crashed with \"terminate called after throwing an instance of\n'std::bad_alloc'\".\n\n> It's in RecvUntil, but I still can't see anything wrong with it.  The\n> only thing I can think of is if the socket is receiving a spew of\n> characters.\n>\n> Try this irc.cpp.  debug.log may grow rapidly so be ready to kill it.\n>\n> mmalmi@cc.hut.fi wrote:\n>> debug.log attached\n>>\n>>> That narrows it down a lot.  It didn't print any IRC activity in\n>>> debug.log, so I guess it couldn't have gotten past the RecvUntil.\n>>> Eyeballing it I don't see anything obvious.  I guess it would have to\n>>> be either in ConnectSocket or RecvUntil.\n>>>\n>>> Try it with the attached irc.cpp and net.cpp and send me the debug.log.\n>>>\n>>> Or you could run it in gdb and step through ThreadIRCSeed\n>>> gdb --args bitcoin [switches]\n>>> b ThreadIRCSeed\n>>> run\n>>> step\n>>> or u to step over and up out of routines.\n>>>\n>>> mmalmi@cc.hut.fi wrote:\n>>>> I get the error regardless of the getinfo. Commenting out\n>>>> ThreadIRCSeed fixed the problem.\n>>>>\n>>>>> Does it still do it if you didn't do getinfo?\n>>>>>\n>>>>> You could comment out the CreateThreads listed below, then re-enable\n>>>>> them one at a time until it does it again.  Then we would know which\n>>>>> thread the problem is in.\n>>>>>\n>>>>> net.cpp, under // Start threads\n>>>>>   CreateThread(ThreadIRCSeed, NULL)\n>>>>>   CreateThread(ThreadSocketHandler, NULL, true)\n>>>>>   CreateThread(ThreadOpenConnections, NULL)\n>>>>>   CreateThread(ThreadMessageHandler, NULL)\n>>>>>\n>>>>> init.cpp:\n>>>>>   CreateThread(ThreadRPCServer, NULL);\n>>>>>\n>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>> Here goes. I forgot to mention the crash error message:\n>>>>>>\n>>>>>> terminate called after throwing an instance of 'std::bad_alloc'\n>>>>>> what():  std::bad_alloc\n>>>>>>\n>>>>>>> Could you send me the debug.log?\n>>>>>>>\n>>>>>>> mmalmi@cc.hut.fi wrote:\n>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but\n>>>>>>>>     didn't have much success yet. It always ends up taking all\n>>>>>>>> the   system's memory and finally crashes. Could you please\n>>>>>>>> send me   again  the latest 64 bit build of bitcoind, so I  can\n>>>>>>>> see if the  problem is  about my build?\n>>>>>>>>\n>>>>>>\n>>>>>>\n>>>>>>\n>>>>\n>>>>\n>>>>\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-188","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoind"}],"id":"x64"},{"k":"x","s":"single-emails","t":"Email to Jon Matonis","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-jon-matonis.txt","m":[{"f":"Satoshi Nakamoto","d":1267660800,"b":[["t","Jon Matonis\nExecutive Director\n\nMembers\nPip\n56 posts\nPosted 22 December 2012 - 11:04 AM\n\nThanks for sharing that, Gavin and Mike. It made me go back and look for my Satoshi correspondence, which unfortunately has been purged except for my last email from Satoshi on 4th March 2010. We went back and forth a bit on how bitcoin was an evolution over issuing mint functionality like Chaum's DigiCash and on what I could do to promote the protocol effort because we shared a lot of similar contacts from the \"early\" days. I am attaching it here partly so I don't misplace it again.\n\n--- On Thu, 3/4/10, Satoshi Nakamoto <satoshin@gmx.com> wrote:\n\nFrom: Satoshi Nakamoto <satoshin@gmx.com>\nSubject: Re: Introduction\nTo: \"Jon Matonis\" <matonis@yahoo.com>\nDate: Thursday, March 4, 2010, 9:55 PM\n\nNice blog.  That's the first I've seen that focuses on this subject.  I wish there was something like that when I originally researched this three years ago, there was scant to nothing back then.  I think I'll be a regular reader.\n\nBitcoin would be right up your alley.  Its advantage is that it's P2P. There isn't a central mint or company running it.  As long as there are users, it survives.\n\nI'm sure you've already found the FAQ and Forum at bitcoin.org.\n\nThe logo is here:\nhttp://www.bitcoin.org/smf/index.php?topic=64.0\n\nWas there anything particular you were interested in?"]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-jon-matonis.txt","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-jon-matonis.txt","to":"Jon Matonis","fe":null,"s":1,"dp":"source-file"}],"id":"x65"},{"k":"x","s":"martti-malmi","t":"Blog","u":"https://mmalmi.github.io/satoshi/#email-189","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1267857593,"b":[["t","There's a blog writer who wants to write a story about Bitcoin, but I\ndon't have time right now to answer his questions.  Would you be\ninterested in answering his questions if I refer him to you?  We might\nget a good link out of it.\n\nThe blog is\nhttp://themonetaryfuture.blogspot.com"]],"u":"https://mmalmi.github.io/satoshi/#email-189","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1267922795,"b":[["t","Yes, I could do that."],["q","There's a blog writer who wants to write a story about Bitcoin, but I\ndon't have time right now to answer his questions.  Would you be\ninterested in answering his questions if I refer him to you?  We might\nget a good link out of it.\n\nThe blog is\nhttp://themonetaryfuture.blogspot.com"]],"u":"https://mmalmi.github.io/satoshi/#email-190","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Blog"}],"id":"x66"},{"k":"x","s":"martti-malmi","t":"Status update","u":"https://mmalmi.github.io/satoshi/#email-191","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1273817812,"b":[["t","Hi!\n\nHow are you doing? Haven't seen you around in a while.\n\nI've been at full-time work lately, and will be until the end of June,\nso I haven't had that much time to work with Bitcoin or my exchange\nservice. I have a working beta of my service though, and a few weeks\nago made my first transaction: sold 10,000 btc for 20 euros via EU\nbank transfer. Maybe I can make it public soon.\n\nI divided the forum into 6 boards, which are Bitcoin Discussion,\nDevelopment & Technical Discussion, Technical support, Economics,\nMarketplace and Trading Discussion. Hope this is ok?\n\nI also added a page \"Trade\" on the bitcoin.org site, where\nbtc-accepting services are listed. It's nice to see that there are\nalready useful services that accept btc.\n\nThe community has been growing nicely. We've had around 10-20 people\nand active discussion at #bitcoin-dev lately.\n\nIt would be nice to get the daemon-able binaries to SF.net. We have\nsome skilled programmers in the community now, so maybe we can finish\nthe JSON API functions if you don't have time to.\n\nBest regards."]],"u":"https://mmalmi.github.io/satoshi/#email-191","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1274037141,"b":[["t","I've also been busy with other things for the last month and a half.  I\njust now downloaded my e-mail since the beginning of April.  I mostly\nhave things sorted and should be back to Bitcoin shortly.  Glad that\nyou've been handling things in my absence.  Congrats on your first\ntransaction!\n\nAs I recall, the code was nearly ready for a 0.3 release.  I think all\nit needed was a little testing time and to install the new icon xpm.\n\nThe JSON API functions are complete.  I wanted to take another fresh\nlook at them in case I think of any better function names before\ncommitting.  I ought to write some sample code showing the proper way to\nuse them, particularly with polling for received transactions.  When I\nleft off, I was thinking about bolting a payment mechanism onto a free\nupload server software as an example.  It would make sense to actually\nbuild one practical application with the API before releasing it.  You\ndon't realise the problems with an API until you actually try to use it."],["q","Hi!\n\nHow are you doing? Haven't seen you around in a while.\n\nI've been at full-time work lately, and will be until the end of June,\nso I haven't had that much time to work with Bitcoin or my exchange\nservice. I have a working beta of my service though, and a few weeks ago\nmade my first transaction: sold 10,000 btc for 20 euros via EU bank\ntransfer. Maybe I can make it public soon.\n\nI divided the forum into 6 boards, which are Bitcoin Discussion,\nDevelopment & Technical Discussion, Technical support, Economics,\nMarketplace and Trading Discussion. Hope this is ok?\n\nI also added a page \"Trade\" on the bitcoin.org site, where btc-accepting\nservices are listed. It's nice to see that there are already useful\nservices that accept btc.\n\nThe community has been growing nicely. We've had around 10-20 people and\nactive discussion at #bitcoin-dev lately.\n\nIt would be nice to get the daemon-able binaries to SF.net. We have some\nskilled programmers in the community now, so maybe we can finish the\nJSON API functions if you don't have time to.\n\nBest regards.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-192","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Status update"}],"id":"x67"},{"k":"x","s":"single-emails","t":"Email to Laszlo Hanyecz","u":null,"su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-laszlo-hanyecz.txt","m":[{"f":"Satoshi Nakamoto","d":1274054400,"b":[["t","nathanielpopper\n\nHere's what Satoshi wrote to the man responsible for Pizza Day, Laszlo Hanecz -- a r/bitcoin exclusive from \"Digital Gold\"\n\nIn the course of reporting for my book Digital Gold I learned a lot more about the story of Laszlo Hanecz, the man who spent 10,000 Bitcoins for pizza back in 2010.\n\nHow did Laszlo have all those Bitcoins? It is not widely known, but in April 2010, Laszlo was essentially the first person to experiment with using the GPU card in his computer to more efficiently mine Bitcoins. Before that, most Bitcoin users had been employing their much less efficient CPU to do the computations. Laszlo’s CPU had been winning, at most, one block of 50 Bitcoins each day, of the approximately 140 blocks that were released daily. Once Laszlo got his GPU card hooked in he began winning one or two blocks an hour, and occasionally more.\n\nWhen Laszlo first emailed Satoshi and told him about his plans to mine with his GPU, Satoshi had mixed feelings. Here is the email Satoshi wrote to Laszlo.\n\nA big attraction to new users is that anyone with a computer can generate some free coins. When there are 5000 users, that incentive may fade, but for now it's still true.\nGPUs would prematurely limit the incentive to only those with high end GPU hardware. It's inevitable that GPU compute clusters will eventually hog all the generated coins, but I don't want to hasten that day. If the difficulty gets really high, that increases the value of each coin in a way since the supply becomes more limited. The supply is the same: 50 coins every 10 minutes.\nBut GPUs are much less evenly distributed, so the generated coins only go towards rewarding 20% of the people for joining the network instead of 100%.\nI don't mean to sound like a socialist, I don't care if wealth is concentrated, but for now, we get more growth by giving that money to 100% of the people than giving it to 20%. Also, the longer we can delay the GPU arms race, the more mature the OpenCL libraries get, and the more people will have OpenCL compatible video cards. If we see from the difficulty factor that someone is using too much GPU, we can certainly pick this OpenCL stuff up again then. Maybe my effort to maintain GPU innocence is running out of time. It's worked out so far.\n\nThanks to Laszlo for sharing this piece of Bitcoin history.\n\nIf you'd like to learn more about Laszlo, Satoshi and the rest of Bitcoin's history, please buy a copy of Digital Gold on Amazon, or on Overstock if you want to pay with Bitcoins."]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-laszlo-hanyecz.txt","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-laszlo-hanyecz.txt","to":"Laszlo Hanyecz","fe":null,"s":1,"dp":"source-file"}],"id":"x68"},{"k":"x","s":"martti-malmi","t":"0.3.0 rc1 quickie download link","u":"https://mmalmi.github.io/satoshi/#email-193","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1277228182,"b":[["t","If bandwidth is a problem, delete my link in the \"0.3 almost ready\"\nthread.  I just don't want to upload it to sourceforge for a quickie\nshare for a day or two, possibly taking it down immediately if there's a\nbug.  Sourceforge has a policy of not allowing removal of files once\nthey're added, and it's a pain to upload to.  I'll delete the file once\nthe release is ready.\n\nBTW, it's looking like I may be able to get us some money soon to cover\nweb host costs, back your exchange service, etc, in the form of cash in\nthe mail.  Can you receive it and act as the project's treasurer?"]],"u":"https://mmalmi.github.io/satoshi/#email-193","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1277232681,"b":[["q","If bandwidth is a problem, delete my link in the \"0.3 almost ready\"\nthread.  I just don't want to upload it to sourceforge for a quickie\nshare for a day or two, possibly taking it down immediately if there's\na bug.  Sourceforge has a policy of not allowing removal of files once\nthey're added, and it's a pain to upload to.  I'll delete the file once\nthe release is ready."],["t","Ok, I'll monitor it. Bandwidth hasn't been a problem so far - it's\nbeen about 2 GB (0.5 dollars) per month at most. Other costs are about\n15$ a month."],["q","BTW, it's looking like I may be able to get us some money soon to cover\nweb host costs, back your exchange service, etc, in the form of cash in\nthe mail.  Can you receive it and act as the project's treasurer?"],["t","That would be nice, I can do it. Sending cash in the mail may have its\nrisks, but maybe it's still the best anonymous option. We can also ask\nfor donations in BTC on the forum."]],"u":"https://mmalmi.github.io/satoshi/#email-194","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: 0.3.0 rc1 quickie download link"}],"id":"x69"},{"k":"x","s":"martti-malmi","t":"Donation","u":"https://mmalmi.github.io/satoshi/#email-195","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1277325237,"b":[["q","> BTW, it's looking like I may be able to get us some money soon to cover\n> web host costs, back your exchange service, etc, in the form of cash in\n> the mail.  Can you receive it and act as the project's treasurer?\n\nThat would be nice, I can do it. Sending cash in the mail may have its\nrisks, but maybe it's still the best anonymous option. We can also ask\nfor donations in BTC on the forum."],["t","I got a donation offer for $2000 USD.  I need to get your postal mailing\naddress to have him send to.  And yes, he wants to remain anonymous, so\nplease keep the envelope's origin private."]],"u":"https://mmalmi.github.io/satoshi/#email-195","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: donation"},{"f":"mmalmi@cc.hut.fi","d":1277445314,"b":[["t","You can give this address:\n\nMartti Malmi\nVisakoivunkuja 15 F 42\n02130 Espoo\nFinland"],["q",">> BTW, it's looking like I may be able to get us some money soon to cover\n>> web host costs, back your exchange service, etc, in the form of cash in\n>> the mail.  Can you receive it and act as the project's treasurer?\n>\n> That would be nice, I can do it. Sending cash in the mail may have\n> its risks, but maybe it's still the best anonymous option. We can\n> also ask for donations in BTC on the forum.\n\nI got a donation offer for $2000 USD.  I need to get your postal\nmailing address to have him send to.  And yes, he wants to remain\nanonymous, so please keep the envelope's origin private."]],"u":"https://mmalmi.github.io/satoshi/#email-196","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: donation"},{"f":"mmalmi@cc.hut.fi","d":1279744398,"b":[["t","Good news: I received the donation of $3600. At least the hosting\ncosts are no problem anymore.\n\nWhat do you think of the idea to offer rewards of $100-200 to the\nfirst 5-10 established companies that start accepting Bitcoin? We'd\nalso assign them a dedicated support person to help with integration.\nI have companies like prq.se, ipredator.se, relakks.com or\nperfect-privacy.com in mind. We could also make the offer public."]],"u":"https://mmalmi.github.io/satoshi/#email-212","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1279751313,"b":[["q","Good news: I received the donation of $3600. At least the hosting costs\nare no problem anymore.","mmalmi@cc.hut.fi wrote:"],["t","That's great!  I'll let him know it was received and thank him.\n\nIt might be a long time before we get another donation like that, we\nshould save a lot of it.\n\nSpend what you need on hosting.  Email me a simple accounting when you\ntake out money for expenses, like:\n    -$60 rackspace monthly\n   $2540 balance"],["q","What do you think of the idea to offer rewards of $100-200 to the first\n5-10 established companies that start accepting Bitcoin? We'd also\nassign them a dedicated support person to help with integration. I have\ncompanies like prq.se, ipredator.se, relakks.com or perfect-privacy.com\nin mind. We could also make the offer public."],["t","$100-200 is chump change if they're a serious company, it would only\nmake us sound small.\n\nWhat they need most is confidence they can convert it to fiat currency.\n  That VOIP company essentially said so in a recent post.  The best\nthing we can do is make sure there's cash available to cash out and\nsupport and steady the conversion rate.\n\nThe money is leveraged better that way too.  Theoretically, imagine 10\nbusinesses have their eye on a $100 bill being offered for bitcoins, but\ndon't actually cash out because they know it's there if they need it.\nThat one $100 bill allowed 10 different people to act like their 5000\nbitcoins were equivalent to $100.\n\nI think we should allocate $1000 at this point to your exchange."]],"u":"https://mmalmi.github.io/satoshi/#email-213","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Donation"},{"f":"mmalmi@cc.hut.fi","d":1279860071,"b":[["q","Spend what you need on hosting.  Email me a simple accounting when you\ntake out money for expenses, like:\n   -$60 rackspace monthly\n  $2540 balance"],["t","Ok."],["q","> What do you think of the idea to offer rewards of $100-200 to the\n> first 5-10 established companies that start accepting Bitcoin? We'd\n>  also assign them a dedicated support person to help with\n> integration. I have companies like prq.se, ipredator.se,\n> relakks.com or perfect-privacy.com in mind. We could also make the\n> offer public.\n\n$100-200 is chump change if they're a serious company, it would only\nmake us sound small.\n\nWhat they need most is confidence they can convert it to fiat currency.\n That VOIP company essentially said so in a recent post.  The best\nthing we can do is make sure there's cash available to cash out and\nsupport and steady the conversion rate.\n\nThe money is leveraged better that way too.  Theoretically, imagine 10\nbusinesses have their eye on a $100 bill being offered for bitcoins,\nbut don't actually cash out because they know it's there if they need\nit. That one $100 bill allowed 10 different people to act like their\n5000 bitcoins were equivalent to $100.\n\nI think we should allocate $1000 at this point to your exchange."],["t","Alright, I'll add $1000 dollars to the exchange reserves. That way I\ncan offer more stable pricing.\n\nA week ago somebody bought coins with 1000 €. That was probably meant\nas a donation to some extent, since 1000 € would have bought him a lot\nmore coins at bitcoinmarket.com than at my service."]],"u":"https://mmalmi.github.io/satoshi/#email-214","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Donation"},{"f":"Satoshi Nakamoto","d":1279900782,"b":[["q","> I think we should allocate $1000 at this point to your exchange.\n\nAlright, I'll add $1000 dollars to the exchange reserves. That way I can\noffer more stable pricing.\n\nA week ago somebody bought coins with 1000 €. That was probably meant as\na donation to some extent, since 1000 € would have bought him a lot more\ncoins at bitcoinmarket.com than at my service."],["t","Interesting, so how is the balance between purchases of coins and cash\ngoing?\n\nBtw, are you able to use my builds of bitcoind on your host, or do you\nhave to build it yourself?"]],"u":"https://mmalmi.github.io/satoshi/#email-215","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Donation"},{"f":"mmalmi@cc.hut.fi","d":1279945957,"b":[["q","Interesting, so how is the balance between purchases of coins and cash going?"],["t","About +1000€ (plus the $1000) and -40000 BTC since when I started. I\nshould have set the initial BTC price higher, it was only 1€ / 1000\nBTC in the beginning."],["q","Btw, are you able to use my builds of bitcoind on your host, or do you\nhave to build it yourself?"],["t","I had to build it myself. It had the same problem that has been\nreported on the forums: /usr/lib/libstdc++.so.6: version\n`GLIBCXX_3.4.11' not found."]],"u":"https://mmalmi.github.io/satoshi/#email-216","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Donation"},{"f":"Satoshi Nakamoto","d":1279982333,"b":[["q","A week ago somebody bought coins with 1000 €. That was probably meant as\na donation to some extent, since 1000 € would have bought him a lot more\ncoins at bitcoinmarket.com than at my service."],["t","They probably couldn't have gotten that large of a trade on\nbitcoinmarket.com."]],"u":"https://mmalmi.github.io/satoshi/#email-217","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Donation"},{"f":"mmalmi@cc.hut.fi","d":1281478778,"b":[["t","I deposited the donation to a bank as euros. The donation was actually\nnot $3600 but 3500$. I miscalculated it as it was packed in (18 + 17)\n* $100 instead of (18 + 18) * $100.\n\n$3500 made 2608.28€.\n\n-750€ to back up BitcoinExchange.com\n-28.92€ for the hosting in July\n1829€ balance"]],"u":"https://mmalmi.github.io/satoshi/#email-227","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Donation"}],"id":"x70"},{"k":"x","s":"martti-malmi","t":"Anonymous, homepage changes","u":"https://mmalmi.github.io/satoshi/#email-197","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1278385197,"b":[["t","I think we should de-emphasize the anonymous angle.  With the popularity\nof bitcoin addresses instead of sending by IP, we can't give the\nimpression it's automatically anonymous.  It's possible to be\npseudonymous, but you have to be careful.  If someone digs through the\ntransaction history and starts exposing information people thought was\nanonymous, the backlash will be much worse if we haven't prepared\nexpectations by warning in advance that you have to take precautions if\nyou really want to make that work.  Like Tor says, \"Tor does not\nmagically encrypt all of your Internet activities.  Understand what Tor\ndoes and does not do for you.\"\n\nAlso, anonymous sounds a bit shady.  I think the people who want\nanonymous will still figure it out without us trumpeting it.\n\nI made some changes to the bitcoin.org homepage.  It's not really\ncrucial to update the translations.  I tend to keep editing and\ncorrecting for some time afterwards, so if they want to update, they\nshould wait.\n\nI removed the word \"anonymous\", and the sentence about \"anonymity\nmeans\", although you worded it so carefully \"...CAN be kept hidden...\"\nit was a shame to remove it.\n\nInstead, I added Tor instructions at the bottom, with instructions for\nhow to stay anonymous (pseudonymous) directly after the Tor\ninstructions: \"If you want to remain anonymous (pseudonymous, really),\nbe careful not to reveal any information linking your bitcoin addresses\nto your identity, and use a new bitcoin address for each payment you\nreceive.\"\n\nIt helps that it can now seed automatically through Tor.\n\nEven though it doesn't say anonymous until the bottom, I think anonymous\nseekers would already suspect it based on all the other attributes like\nno central authority to take your ID info and the way bitcoin addresses\nlook."]],"u":"https://mmalmi.github.io/satoshi/#email-197","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1278454674,"b":[["t","Ok, that sounds reasonable."],["q","I think we should de-emphasize the anonymous angle.  With the\npopularity of bitcoin addresses instead of sending by IP, we can't give\nthe impression it's automatically anonymous.  It's possible to be\npseudonymous, but you have to be careful.  If someone digs through the\ntransaction history and starts exposing information people thought was\nanonymous, the backlash will be much worse if we haven't prepared\nexpectations by warning in advance that you have to take precautions if\nyou really want to make that work.  Like Tor says, \"Tor does not\nmagically encrypt all of your Internet activities.  Understand what Tor\ndoes and does not do for you.\"\n\nAlso, anonymous sounds a bit shady.  I think the people who want\nanonymous will still figure it out without us trumpeting it.\n\nI made some changes to the bitcoin.org homepage.  It's not really\ncrucial to update the translations.  I tend to keep editing and\ncorrecting for some time afterwards, so if they want to update, they\nshould wait.\n\nI removed the word \"anonymous\", and the sentence about \"anonymity\nmeans\", although you worded it so carefully \"...CAN be kept hidden...\"\nit was a shame to remove it.\n\nInstead, I added Tor instructions at the bottom, with instructions for\nhow to stay anonymous (pseudonymous) directly after the Tor\ninstructions: \"If you want to remain anonymous (pseudonymous, really),\nbe careful not to reveal any information linking your bitcoin addresses\nto your identity, and use a new bitcoin address for each payment you\nreceive.\"\n\nIt helps that it can now seed automatically through Tor.\n\nEven though it doesn't say anonymous until the bottom, I think\nanonymous seekers would already suspect it based on all the other\nattributes like no central authority to take your ID info and the way\nbitcoin addresses look."]],"u":"https://mmalmi.github.io/satoshi/#email-201","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Anonymous, homepage changes"}],"id":"x71"},{"k":"x","s":"martti-malmi","t":"0.3.0 released","u":"https://mmalmi.github.io/satoshi/#email-198","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1278439430,"b":[["t","I uploaded 0.3.0 beta to sourceforge and updated the links on\nbitcoin.org.  I still need to post the announcement message on the forum\nand mailing list.  Here's what I've prepared:\n\nAnnouncing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a\ndigital currency using cryptography and a distributed network to replace\nthe need for a trusted central server.  Escape the arbitrary inflation\nrisk of centrally managed currencies!  Bitcoin's total circulation is\nlimited to 21 million coins.  The coins are gradually being released to\nthe networks nodes based on the CPU power they contribute.  You can get\na share of them just by installing the software and contributing your\nidle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Tabs for sent and received transactions\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie\nand Joozero)"]],"u":"https://mmalmi.github.io/satoshi/#email-198","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"Satoshi Nakamoto","d":1278441611,"b":[["t","Actually, \"tabs for sent and received transactions\" sounds really\nimmature if it doesn't have that already.  \"Transaction filter tabs\"\nsounds better.\n\nI'm still editing it a little more and then I'll e-mail it to\nbitcoin-list and send it to the cryptography list.\n\n\"Get it at http://www.bitcoin.org or read the forum to find out more.\""],["q","I uploaded 0.3.0 beta to sourceforge and updated the links on\nbitcoin.org.  I still need to post the announcement message on the forum\nand mailing list.  Here's what I've prepared:\n\nAnnouncing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a\ndigital currency using cryptography and a distributed network to replace\nthe need for a trusted central server.  Escape the arbitrary inflation\nrisk of centrally managed currencies!  Bitcoin's total circulation is\nlimited to 21 million coins.  The coins are gradually being released to\nthe networks nodes based on the CPU power they contribute.  You can get\na share of them just by installing the software and contributing your\nidle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Tabs for sent and received transactions\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie\nand Joozero)","Satoshi Nakamoto wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-199","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1,"sj":"Re: 0.3.0 released"}],"id":"x72"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] Bitcoin 0.3 released!","u":"https://mmalmi.github.io/satoshi/#email-200","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1278453187,"b":[["t","Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a\ndigital currency using cryptography and a distributed network to replace\nthe need for a trusted central server.  Escape the arbitrary inflation\nrisk of centrally managed currencies!  Bitcoin's total circulation is\nlimited to 21 million coins.  The coins are gradually released to the\nnetwork's nodes based on the CPU power they contribute, so you can get a\nshare of them by contributing your idle CPU time.\n\nWhat's new:\n- Command line and JSON-RPC control\n- Includes a daemon version without GUI\n- Transaction filter tabs\n- 20% faster hashing\n- Hashmeter performance display\n- Mac OS X version (thanks to Laszlo)\n- German, Dutch and Italian translations (thanks to DataWraith, Xunie\nand Joozero)\n\nGet it at www.bitcoin.org, and read the forum to find out more.\n\n------------------------------------------------------------------------------\nThis SF.net email is sponsored by Sprint\nWhat will you do first with EVO, the first 4G phone?\nVisit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first"],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-200","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x73"},{"k":"x","s":"martti-malmi","t":"Fwd: Re: bitcoin!!!!","u":"https://mmalmi.github.io/satoshi/#email-202","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1279144366,"b":[["t","I see the interior pages of the old sourceforge wiki are still up,\nthough the homepage forwards.\n\n-------- Original Message --------\nSubject: Re: bitcoin!!!!\nDate: Wed, 14 Jul 2010 10:56:21 -0400\nFrom: Sam <samm@sammaloney.com>\nTo: Satoshi Nakamoto <satoshin@gmx.com>\nReferences: <201004111508.52168.samm@sammaloney.com>\n<201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com>\n\nIt was an old FAQ on sourceforge that had been linked from slashdot (on a\nhighly visible comment). people were going there because bitcoin.org was\ndown\nfor a while.\n\nhttp://bitcoin.sourceforge.net/wiki/index.php?page=FAQ\n\nProbably not an issue anymore, but might be a good idea to delete or update\nthat wiki page."],["q","I don't see any 0.1.5 download links on the FAQ.  Do you mean\nbitcoin.org/faq?  Is it on one of the other languages?  Or maybe someone\nelse fixed it already.\n\n> Anyways, I write to you now to let you know you must update the FAQ\n> immediately. It points to 0.15 of bitcoin for download. You must update\n> it to 0.30, as it is slashdotted!"]],"u":"https://mmalmi.github.io/satoshi/#email-202","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1279330426,"b":[["t","Relocated the old site to /oldsite, now there's only the redirection."],["q","I see the interior pages of the old sourceforge wiki are still up,\nthough the homepage forwards.\n\n-------- Original Message --------\nSubject: Re: bitcoin!!!!\nDate: Wed, 14 Jul 2010 10:56:21 -0400\nFrom: Sam <samm@sammaloney.com>\nTo: Satoshi Nakamoto <satoshin@gmx.com>\nReferences: <201004111508.52168.samm@sammaloney.com>\n<201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com>\n\nIt was an old FAQ on sourceforge that had been linked from slashdot (on a\nhighly visible comment). people were going there because bitcoin.org was down\nfor a while.\n\nhttp://bitcoin.sourceforge.net/wiki/index.php?page=FAQ\n\nProbably not an issue anymore, but might be a good idea to delete or update\nthat wiki page.\n\n> I don't see any 0.1.5 download links on the FAQ.  Do you mean\n> bitcoin.org/faq?  Is it on one of the other languages?  Or maybe someone\n> else fixed it already.\n>\n>> Anyways, I write to you now to let you know you must update the FAQ\n>> immediately. It points to 0.15 of bitcoin for download. You must update\n>> it to 0.30, as it is slashdotted!\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-207","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Fwd: Re: bitcoin!!!!"}],"id":"x74"},{"k":"x","s":"martti-malmi","t":"bitcoin.org drupal users","u":"https://mmalmi.github.io/satoshi/#email-203","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1279215670,"b":[["t","Is it possible for the translators (at least the more trusted ones) to\nhave user accounts on drupal so they can update their translated text\ndirectly?  The user accounts on drupal appear to be pretty weak.  I\ncreated a satoshi account and it can't even edit the side bar stuff,\njust the main text of pages.  I don't think user accounts can access any\nof the admin stuff.  Do you think it's safe, or do you feel insecure\nabout doing that?  If you're worried, maybe there's a way to lock just\nthe english version of the homepage.\n\nIt would be nice if when I need to make changes to the homepage, I could\nenlist someone like Xunie to do the rote work of reflecting it to all\nthe translations instead of having to do all that work myself.  (many\nlight changes don't require understanding the language to fix the\ntranslated pages)"]],"u":"https://mmalmi.github.io/satoshi/#email-203","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1279330058,"b":[["t","Yes, we could give accounts to trusted translators. I haven't found a\nway to give them edit permissions to only one page, but they can be\nforced to create a new revision with every page change they make, and\nnot be allowed to delete revisions. Xunie would be the first on the\nlist I'd give an account. :)"],["q","Is it possible for the translators (at least the more trusted ones) to\nhave user accounts on drupal so they can update their translated text\ndirectly?  The user accounts on drupal appear to be pretty weak.  I\ncreated a satoshi account and it can't even edit the side bar stuff,\njust the main text of pages.  I don't think user accounts can access\nany of the admin stuff.  Do you think it's safe, or do you feel\ninsecure about doing that?  If you're worried, maybe there's a way to\nlock just the english version of the homepage.\n\nIt would be nice if when I need to make changes to the homepage, I\ncould enlist someone like Xunie to do the rote work of reflecting it to\nall the translations instead of having to do all that work myself.\n(many light changes don't require understanding the language to fix the\ntranslated pages)"]],"u":"https://mmalmi.github.io/satoshi/#email-206","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: bitcoin.org drupal users"}],"id":"x75"},{"k":"x","s":"martti-malmi","t":"Fwd: Please update the bitcoin FAQ so new member can have the right info","u":"https://mmalmi.github.io/satoshi/#email-204","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1279215835,"b":[["t","-------- Original Message --------\nSubject: \tPlease update the bitcoin FAQ so new member can have the right\ninfo\nDate: \tMon, 12 Jul 2010 14:13:20 -0700\nFrom: \tJim Nguyen <jimmy.winn@gmail.com>\nTo: \tsatoshin@gmx.com\n\nHi,\n\nIn the FAQ of bitcoin.org <http://bitcoin.org> the backing up of the\nwallet had old instructions, right?  Should it just be to back up\nwallat.dat instead of the entire folder???  See below.\n\n\"How do I backup my wallet?\n\nYour data is stored in the directory ''%appdata%\\Bitcoin'', which is\ntypically:\n\n  Windows XP:\n    C:\\Documents and Settings\\username\\Application Data\\Bitcoin\n  Windows Vista:\n    C:\\Users\\username\\AppData\\Roaming\\Bitcoin\n\nIt’s recommended that you stop Bitcoin before backing it up to make sure\nthe backup will be correct.\""]],"u":"https://mmalmi.github.io/satoshi/#email-204","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x76"},{"k":"x","s":"martti-malmi","t":"bitcoin.org server","u":"https://mmalmi.github.io/satoshi/#email-205","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1279224012,"b":[["t","You did some research when choosing hosting, this was a well chosen one,\nright?  It seems like it would be a tremendous hassle to change, and\nwe've had good luck with this one.  Cheaper will usually have some\noffsetting drawback in quality.\n\nI wonder if that extra memory is just disk cache or something.\n\nI take it you haven't received anything from that donor yet?  He seemed\npretty certain he was going to send it, maybe more.  (if you get\nanything, we need to keep private for him the fact that we got a donation)"]],"u":"https://mmalmi.github.io/satoshi/#email-205","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x77"},{"k":"x","s":"martti-malmi","t":"Fwd: bitcoin hosting","u":"https://mmalmi.github.io/satoshi/#email-208","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1279408905,"b":[["t","Rackspace has very good support, good backend, good connections and\nnicely scaling cloud based virtual servers. I got this offer from\nThufir:\n\n-----\nHi Sirius,\n\nCheck out www.citrusdesignstudio.com. You will see through the portfolio that\nI am a real business with many clients.\n\nThat is my business that I provide managed hosting through.\nI also do unmanaged VPSes.\n\nNormally I would charge $15/mo for 512MB.\nI will do it for $10/mo for you.\n\nTo see my pricing, go to www.linnode.com. I match everything they have except\ntheir great panel -- you have to email or call my people.\n\nI provide VPS services normally for 3/4ths the posted cost on linnode.com.\n(Rackspace is even more expensive.)\n\nI will do it for 1/2 of linnode's price for you.\n\nIt scales linerally just like linnodes, so for 2048 MB of memory, I would\ncharge $40, etc.\n\nLater!\n-----\n\nThat would be worth considering, if they have good datacenters and\nconnections. $10 / month is about $20 less than what Rackspace costs.\nOn the other hand, Rackspace prices are no problem if the donation is\nto arrive."]],"u":"https://mmalmi.github.io/satoshi/#email-208","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1279466590,"b":[["t","Please promise me you won't make a switch now.  The last thing we need\nis switchover hassle on top of the slashdot flood of work we've got now.\n  I'm losing my mind there are so many things that need to be done.\n\nAlso, it would suck to be on a smaller, less reliable host just to save\na measly $20.\n\nI will try to think of a polite way to ask the donor if he sent it, but\nright now there are other higher priority things that are going to bump\neven that for a few days.\n\nWould a donation of bitcoins help in the short term?"],["q","Rackspace has very good support, good backend, good connections and\nnicely scaling cloud based virtual servers. I got this offer from Thufir:\n\n-----\nHi Sirius,\n\nCheck out www.citrusdesignstudio.com. You will see through the portfolio\nthat\nI am a real business with many clients.\n\nThat is my business that I provide managed hosting through.\nI also do unmanaged VPSes.\n\nNormally I would charge $15/mo for 512MB.\nI will do it for $10/mo for you.\n\nTo see my pricing, go to www.linnode.com. I match everything they have\nexcept\ntheir great panel -- you have to email or call my people.\n\nI provide VPS services normally for 3/4ths the posted cost on linnode.com.\n(Rackspace is even more expensive.)\n\nI will do it for 1/2 of linnode's price for you.\n\nIt scales linerally just like linnodes, so for 2048 MB of memory, I would\ncharge $40, etc.\n\nLater!\n-----\n\nThat would be worth considering, if they have good datacenters and\nconnections. $10 / month is about $20 less than what Rackspace costs. On\nthe other hand, Rackspace prices are no problem if the donation is to\narrive.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-210","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Fwd: bitcoin hosting"},{"f":"mmalmi@cc.hut.fi","d":1279497071,"b":[["t","Ok, I won't switch it. Donations in Bitcoin are helpful and can be\nsent to 14EXchS9j3AAfim6mL4jtw6VWMosSUiG5U."],["q","Please promise me you won't make a switch now.  The last thing we need\nis switchover hassle on top of the slashdot flood of work we've got\nnow.  I'm losing my mind there are so many things that need to be done.\n\nAlso, it would suck to be on a smaller, less reliable host just to save\na measly $20.\n\nI will try to think of a polite way to ask the donor if he sent it, but\nright now there are other higher priority things that are going to bump\neven that for a few days.\n\nWould a donation of bitcoins help in the short term?\n\nmmalmi@cc.hut.fi wrote:\n> Rackspace has very good support, good backend, good connections and\n>  nicely scaling cloud based virtual servers. I got this offer from\n> Thufir:\n>\n> -----\n> Hi Sirius,\n>\n> Check out www.citrusdesignstudio.com. You will see through the\n> portfolio that\n> I am a real business with many clients.\n>\n> That is my business that I provide managed hosting through.\n> I also do unmanaged VPSes.\n>\n> Normally I would charge $15/mo for 512MB.\n> I will do it for $10/mo for you.\n>\n> To see my pricing, go to www.linnode.com. I match everything they\n> have except\n> their great panel -- you have to email or call my people.\n>\n> I provide VPS services normally for 3/4ths the posted cost on linnode.com.\n> (Rackspace is even more expensive.)\n>\n> I will do it for 1/2 of linnode's price for you.\n>\n> It scales linerally just like linnodes, so for 2048 MB of memory, I would\n> charge $40, etc.\n>\n> Later!\n> -----\n>\n> That would be worth considering, if they have good datacenters and\n> connections. $10 / month is about $20 less than what Rackspace\n> costs. On the other hand, Rackspace prices are no problem if the\n> donation is to arrive.\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-211","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Fwd: bitcoin hosting"}],"id":"x78"},{"k":"x","s":"martti-malmi","t":"wiki","u":"https://mmalmi.github.io/satoshi/#email-209","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1279466601,"b":[["t","http://www.bitcoin.org/smf/index.php?topic=393.msg3785#msg3785\n\nAndrewBuck:\n...\n\nEDIT:  The wiki doesn't seem to be sending the registration e-mail so I\ncan log in to edit, is there some problem with the server or something?\n\n-Buck"]],"u":"https://mmalmi.github.io/satoshi/#email-209","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x79"},{"k":"x","s":"martti-malmi","t":"Re: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11'","u":"https://mmalmi.github.io/satoshi/#email-218","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280168528,"b":[["q","> Btw, are you able to use my builds of bitcoind on your host, or do you\n> have to build it yourself?\n\nI had to build it myself. It had the same problem that has been reported\non the forums: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found."],["t","Wish I could figure out how to fix that.  What version of GLIBCXX does\nyour system have?\n\nMake sure you upgrade to Bitcoin 0.3.3 as soon as possible."]],"u":"https://mmalmi.github.io/satoshi/#email-218","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1}],"id":"x80"},{"k":"x","s":"martti-malmi","t":"Forum e-mail notifications and PBL blacklist and wiki registration","u":"https://mmalmi.github.io/satoshi/#email-219","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280369936,"b":[["t","http://www.bitcoin.org/smf/index.php?topic=338.0"],["q","of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.\n\n\"Looks like bitcoin.org is listed on the PBL.\"\nhttp://www.spamhaus.org/pbl/query/PBL340779"],["t","I think our problem may be that we have forum notifications on, like\ne-mail you when you receive a PM, but we don't have e-mail verification\nof new accounts.  Can someone put someone else's e-mail address without\nverifying it, then have stuff sent there?  We need to stop that right\naway before it gets used for something bad.  Either disallow all\nnotification, or make sure e-mail addresses are verified.\n\nI'm more inclined to disallow notifications or anything where the forum\nsends you e-mail.  I kinda like not requiring e-mail verification.  But\nif that's the only way to make sure we don't send e-mails to un-verified\naddresses, then we could do that.\n\nIf we request to get off of PBL, we'd better make sure we've got the\nproblem secured first.\n\nI changed Registration->settings->registration of new members to \"Member\nActivation\".  I assume that means it e-mail verifies.\n\"Member Activation\nWhen this option is enabled any members registering to the forum will\nhave a activation link emailed to them which they must click before they\ncan become full members\"\n\nI think that's the only way to make sure the forum can't be used to send\nto other people's e-mail addresses and potentially use it to spam."]],"u":"https://mmalmi.github.io/satoshi/#email-219","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x81"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] Alert: upgrade to bitcoin 0.3.6","u":"https://mmalmi.github.io/satoshi/#email-220","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280468078,"b":[["t","Please upgrade to 0.3.6 ASAP to get an important bugfix.\n\nSee the bitcoin.org homepage for download links.\n\n------------------------------------------------------------------------------\nThe Palm PDK Hot Apps Program offers developers who use the\nPlug-In Development Kit to bring their C/C++ apps to Palm for a share\nof $1 Million in cash or HP Products. Visit us here for more details:\nhttp://p.sf.net/sfu/dev2dev-palm"],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-220","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x82"},{"k":"x","s":"martti-malmi","t":"[Fwd: no activation mail]","u":"https://mmalmi.github.io/satoshi/#email-221","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280782566,"b":[["t","Oh great, now we're screwed.\n\nWe probably got spam blocked because we were allowing registrations\nwithout e-mail verification.  But now that we've enabled it, our\nverification e-mails are blocked.\n\nThere could still be some existing user accounts created before the\nregistration requirement being used by spammers.\n\nWe're kind of in a jam here.  Can you make sure there's nothing else you\ncan think of that might be acting as an open e-mail gateway or way for\nspammers to use our system for putting out spam?  Check the e-mail logs\nand see if there's been a lot of traffic and what it's from.  If you can\nfigure out what the problem was and shut it down, then after you're sure\nit's fixed, request PBL to take us off the block list.\n\nIf there's a way to prohibit the forum from sending e-mail\nnotifications, maybe we should do that.\n\n-------- Original Message --------\nSubject: no activation mail\nDate: Mon, 02 Aug 2010 22:30:35 +0200\nFrom: Youri <youri.de.bruycker@telenet.be>\nTo: satoshin@gmx.com\n\nHey Satoshin,\n\nI tried to register me at the bitcoinforum, but I didn't get an activation\nmail.\nTried the resend activation code option a few times, changed the\nmailadress from my telenet to my gmail and back, but no luck. Looked at my\nspam folder but it's not there. So I guess something went wrong, could you\nactivate my account?\n\nMy username is Skull88.\n\nThanks in advance,\nYouri"]],"u":"https://mmalmi.github.io/satoshi/#email-221","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1280871433,"b":[["t","The logs don't tell very much, they just confirm that many servers\nreject the emails sent by our server. I can't think of anything other\nthan pm notifications that could have caused the spam listing. I'll\ncheck if I can disable the notifications from the code.\n\nWe can allow registrations without email confirmation. It's no problem\nwhen we're already on the spam list and no problem after the\nnotifications are disabled."],["q","Oh great, now we're screwed.\n\nWe probably got spam blocked because we were allowing registrations\nwithout e-mail verification.  But now that we've enabled it, our\nverification e-mails are blocked.\n\nThere could still be some existing user accounts created before the\nregistration requirement being used by spammers.\n\nWe're kind of in a jam here.  Can you make sure there's nothing else\nyou can think of that might be acting as an open e-mail gateway or way\nfor spammers to use our system for putting out spam?  Check the e-mail\nlogs and see if there's been a lot of traffic and what it's from.  If\nyou can figure out what the problem was and shut it down, then after\nyou're sure it's fixed, request PBL to take us off the block list.\n\nIf there's a way to prohibit the forum from sending e-mail\nnotifications, maybe we should do that.\n\n-------- Original Message --------\nSubject: no activation mail\nDate: Mon, 02 Aug 2010 22:30:35 +0200\nFrom: Youri <youri.de.bruycker@telenet.be>\nTo: satoshin@gmx.com\n\nHey Satoshin,\n\nI tried to register me at the bitcoinforum, but I didn't get an activation\nmail.\nTried the resend activation code option a few times, changed the\nmailadress from my telenet to my gmail and back, but no luck. Looked at my\nspam folder but it's not there. So I guess something went wrong, could you\nactivate my account?\n\nMy username is Skull88.\n\nThanks in advance,\nYouri"]],"u":"https://mmalmi.github.io/satoshi/#email-224","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: [Fwd: no activation mail]"},{"f":"mmalmi@cc.hut.fi","d":1281027791,"b":[["t","I edited the forum code, it shouldn't send notifications anymore."],["q","Oh great, now we're screwed.\n\nWe probably got spam blocked because we were allowing registrations\nwithout e-mail verification.  But now that we've enabled it, our\nverification e-mails are blocked.\n\nThere could still be some existing user accounts created before the\nregistration requirement being used by spammers.\n\nWe're kind of in a jam here.  Can you make sure there's nothing else\nyou can think of that might be acting as an open e-mail gateway or way\nfor spammers to use our system for putting out spam?  Check the e-mail\nlogs and see if there's been a lot of traffic and what it's from.  If\nyou can figure out what the problem was and shut it down, then after\nyou're sure it's fixed, request PBL to take us off the block list.\n\nIf there's a way to prohibit the forum from sending e-mail\nnotifications, maybe we should do that.\n\n-------- Original Message --------\nSubject: no activation mail\nDate: Mon, 02 Aug 2010 22:30:35 +0200\nFrom: Youri <youri.de.bruycker@telenet.be>\nTo: satoshin@gmx.com\n\nHey Satoshin,\n\nI tried to register me at the bitcoinforum, but I didn't get an activation\nmail.\nTried the resend activation code option a few times, changed the\nmailadress from my telenet to my gmail and back, but no luck. Looked at my\nspam folder but it's not there. So I guess something went wrong, could you\nactivate my account?\n\nMy username is Skull88.\n\nThanks in advance,\nYouri"]],"u":"https://mmalmi.github.io/satoshi/#email-225","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: [Fwd: no activation mail]"}],"id":"x83"},{"k":"x","s":"martti-malmi","t":"Disabled some notifications","u":"https://mmalmi.github.io/satoshi/#email-222","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280783302,"b":[["t","For \"normal members\" I disabled \"Request notification on replies\" and\n\"Request notification on new topics\".\n\nI'm pretty sure there's a notification option for when you receive PMs,\nbut I don't see a way to disable it.  If we have to, I guess we could\nedit the php code."]],"u":"https://mmalmi.github.io/satoshi/#email-222","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x84"},{"k":"x","s":"martti-malmi","t":"[Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]","u":"https://mmalmi.github.io/satoshi/#email-223","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1280783360,"b":[["t","Here's the info about PBL again.\n\n-------- Original Message --------\nSubject: Forum e-mail notifications and PBL blacklist and wiki registration\nDate: Thu, 29 Jul 2010 03:18:56 +0100\nFrom: Satoshi Nakamoto <satoshin@gmx.com>\nTo: Martti Malmi <mmalmi@cc.hut.fi>\n\nhttp://www.bitcoin.org/smf/index.php?topic=338.0"],["q","of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.\n\n\"Looks like bitcoin.org is listed on the PBL.\"\nhttp://www.spamhaus.org/pbl/query/PBL340779"],["t","I think our problem may be that we have forum notifications on, like\ne-mail you when you receive a PM, but we don't have e-mail verification\nof new accounts.  Can someone put someone else's e-mail address without\nverifying it, then have stuff sent there?  We need to stop that right\naway before it gets used for something bad.  Either disallow all\nnotification, or make sure e-mail addresses are verified.\n\nI'm more inclined to disallow notifications or anything where the forum\nsends you e-mail.  I kinda like not requiring e-mail verification.  But\nif that's the only way to make sure we don't send e-mails to un-verified\naddresses, then we could do that.\n\nIf we request to get off of PBL, we'd better make sure we've got the\nproblem secured first.\n\nI changed Registration->settings->registration of new members to \"Member\nActivation\".  I assume that means it e-mail verifies.\n\"Member Activation\nWhen this option is enabled any members registering to the forum will\nhave a activation link emailed to them which they must click before they\ncan become full members\"\n\nI think that's the only way to make sure the forum can't be used to send\nto other people's e-mail addresses and potentially use it to spam."]],"u":"https://mmalmi.github.io/satoshi/#email-223","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x85"},{"k":"x","s":"martti-malmi","t":"Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki\tregistration]","u":"https://mmalmi.github.io/satoshi/#email-226","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1281403718,"b":[["t","I sent a removal request to PBL.\n\nThe FAQ says: \"The first thing to know is: THE PBL IS NOT A BLACKLIST.\nYou are not listed for spamming or for anything you have done. The PBL\nis simply a list of all of the world's dynamic IP space, i.e: IP\nranges normally assigned to ISP broadband customers (DSL, DHCP, PPP,\ncable, dialup). It is perfectly normal for dynamic IP addresses to be\nlisted on the PBL. In fact all dynamic IP addresses in the world\nshould be on the PBL. Even static IPs which do not send mail should be\nlisted in the PBL.\" So we didn't even need to allow spam to be on the\nlist."],["q","Here's the info about PBL again.\n\n-------- Original Message --------\nSubject: Forum e-mail notifications and PBL blacklist and wiki registration\nDate: Thu, 29 Jul 2010 03:18:56 +0100\nFrom: Satoshi Nakamoto <satoshin@gmx.com>\nTo: Martti Malmi <mmalmi@cc.hut.fi>\n\nhttp://www.bitcoin.org/smf/index.php?topic=338.0\n\n> of e-mail blackhole list or at least the ISP that hosts the e-mail\n> server for registration is on one of those lists.\n>\n> \"Looks like bitcoin.org is listed on the PBL.\"\n> http://www.spamhaus.org/pbl/query/PBL340779\n\nI think our problem may be that we have forum notifications on, like\ne-mail you when you receive a PM, but we don't have e-mail verification\nof new accounts.  Can someone put someone else's e-mail address without\nverifying it, then have stuff sent there?  We need to stop that right\naway before it gets used for something bad.  Either disallow all\nnotification, or make sure e-mail addresses are verified.\n\nI'm more inclined to disallow notifications or anything where the forum\nsends you e-mail.  I kinda like not requiring e-mail verification.  But\nif that's the only way to make sure we don't send e-mails to un-verified\naddresses, then we could do that.\n\nIf we request to get off of PBL, we'd better make sure we've got the\nproblem secured first.\n\nI changed Registration->settings->registration of new members to \"Member\nActivation\".  I assume that means it e-mail verifies.\n\"Member Activation\nWhen this option is enabled any members registering to the forum will\nhave a activation link emailed to them which they must click before they\ncan become full members\"\n\nI think that's the only way to make sure the forum can't be used to send\nto other people's e-mail addresses and potentially use it to spam."]],"u":"https://mmalmi.github.io/satoshi/#email-226","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1281491667,"b":[["t","Are PM notifications still disabled?  (All we really need is disable the\nforum's access to the mail server)"],["q","Does it work correctly now? I had made some forum code changes to\ndisable PM email notification, but just reverted most of them as\nunnecessary."],["q","I sent a removal request to PBL.\n\nThe FAQ says: \"The first thing to know is: THE PBL IS NOT A BLACKLIST.\nYou are not listed for spamming or for anything you have done. The PBL\nis simply a list of all of the world's dynamic IP space, i.e: IP ranges\nnormally assigned to ISP broadband customers (DSL, DHCP, PPP, cable,\ndialup). It is perfectly normal for dynamic IP addresses to be listed on\nthe PBL. In fact all dynamic IP addresses in the world should be on the\nPBL. Even static IPs which do not send mail should be listed in the\nPBL.\" So we didn't even need to allow spam to be on the list.\n\n> Here's the info about PBL again.\n>\n>\n> -------- Original Message --------\n> Subject: Forum e-mail notifications and PBL blacklist and wiki\n> registration\n> Date: Thu, 29 Jul 2010 03:18:56 +0100\n> From: Satoshi Nakamoto <satoshin@gmx.com>\n> To: Martti Malmi <mmalmi@cc.hut.fi>\n>\n> http://www.bitcoin.org/smf/index.php?topic=338.0\n>\n>> of e-mail blackhole list or at least the ISP that hosts the e-mail\n>> server for registration is on one of those lists.\n>>\n>> \"Looks like bitcoin.org is listed on the PBL.\"\n>> http://www.spamhaus.org/pbl/query/PBL340779\n>\n> I think our problem may be that we have forum notifications on, like\n> e-mail you when you receive a PM, but we don't have e-mail verification\n> of new accounts.  Can someone put someone else's e-mail address without\n> verifying it, then have stuff sent there?  We need to stop that right\n> away before it gets used for something bad.  Either disallow all\n> notification, or make sure e-mail addresses are verified.\n>\n> I'm more inclined to disallow notifications or anything where the forum\n> sends you e-mail.  I kinda like not requiring e-mail verification.  But\n> if that's the only way to make sure we don't send e-mails to un-verified\n> addresses, then we could do that.\n>\n> If we request to get off of PBL, we'd better make sure we've got the\n> problem secured first.\n>\n> I changed Registration->settings->registration of new members to \"Member\n> Activation\".  I assume that means it e-mail verifies.\n> \"Member Activation\n> When this option is enabled any members registering to the forum will\n> have a activation link emailed to them which they must click before they\n> can become full members\"\n>\n> I think that's the only way to make sure the forum can't be used to send\n> to other people's e-mail addresses and potentially use it to spam.","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-228","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1281498152,"b":[["t","Yes, they're still disabled. Disabling the access to the mail server\nwould be easy, but we probably want to keep the password recovery by\nemail."],["q","Are PM notifications still disabled?  (All we really need is disable\nthe forum's access to the mail server)\n\n> Does it work correctly now? I had made some forum code changes to\n> disable PM email notification, but just reverted most of them as\n> unnecessary.\n\nmmalmi@cc.hut.fi wrote:\n> I sent a removal request to PBL.\n>\n> The FAQ says: \"The first thing to know is: THE PBL IS NOT A\n> BLACKLIST. You are not listed for spamming or for anything you have\n>  done. The PBL is simply a list of all of the world's dynamic IP\n> space, i.e: IP ranges normally assigned to ISP broadband customers\n> (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for dynamic\n>  IP addresses to be listed on the PBL. In fact all dynamic IP\n> addresses in the world should be on the PBL. Even static IPs which\n> do not send mail should be listed in the PBL.\" So we didn't even\n> need to allow spam to be on the list.\n>\n>> Here's the info about PBL again.\n>>\n>>\n>> -------- Original Message --------\n>> Subject: Forum e-mail notifications and PBL blacklist and wiki registration\n>> Date: Thu, 29 Jul 2010 03:18:56 +0100\n>> From: Satoshi Nakamoto <satoshin@gmx.com>\n>> To: Martti Malmi <mmalmi@cc.hut.fi>\n>>\n>> http://www.bitcoin.org/smf/index.php?topic=338.0\n>>\n>>> of e-mail blackhole list or at least the ISP that hosts the\n>>> e-mail  server for registration is on one of those lists.\n>>>\n>>> \"Looks like bitcoin.org is listed on the PBL.\"\n>>> http://www.spamhaus.org/pbl/query/PBL340779\n>>\n>> I think our problem may be that we have forum notifications on, like\n>> e-mail you when you receive a PM, but we don't have e-mail verification\n>> of new accounts.  Can someone put someone else's e-mail address without\n>> verifying it, then have stuff sent there?  We need to stop that right\n>> away before it gets used for something bad.  Either disallow all\n>> notification, or make sure e-mail addresses are verified.\n>>\n>> I'm more inclined to disallow notifications or anything where the forum\n>> sends you e-mail.  I kinda like not requiring e-mail verification.  But\n>> if that's the only way to make sure we don't send e-mails to un-verified\n>> addresses, then we could do that.\n>>\n>> If we request to get off of PBL, we'd better make sure we've got the\n>> problem secured first.\n>>\n>> I changed Registration->settings->registration of new members to \"Member\n>> Activation\".  I assume that means it e-mail verifies.\n>> \"Member Activation\n>> When this option is enabled any members registering to the forum will\n>> have a activation link emailed to them which they must click before they\n>> can become full members\"\n>>\n>> I think that's the only way to make sure the forum can't be used to send\n>> to other people's e-mail addresses and potentially use it to spam.\n>\n>\n>"]],"u":"https://mmalmi.github.io/satoshi/#email-229","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1281556813,"b":[["t","Right, forgot about that.\n\nHopefully theymos was right that the PBL is the source of the problem."],["q","Yes, they're still disabled. Disabling the access to the mail server\nwould be easy, but we probably want to keep the password recovery by email.\n\n> Are PM notifications still disabled?  (All we really need is disable\n> the forum's access to the mail server)\n>\n>> Does it work correctly now? I had made some forum code changes to\n>> disable PM email notification, but just reverted most of them as\n>> unnecessary.\n>\n> mmalmi@cc.hut.fi wrote:\n>> I sent a removal request to PBL.\n>>\n>> The FAQ says: \"The first thing to know is: THE PBL IS NOT A\n>> BLACKLIST. You are not listed for spamming or for anything you have\n>>  done. The PBL is simply a list of all of the world's dynamic IP\n>> space, i.e: IP ranges normally assigned to ISP broadband customers\n>> (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for dynamic\n>>  IP addresses to be listed on the PBL. In fact all dynamic IP\n>> addresses in the world should be on the PBL. Even static IPs which\n>> do not send mail should be listed in the PBL.\" So we didn't even\n>> need to allow spam to be on the list.\n>>\n>>> Here's the info about PBL again.\n>>>\n>>>\n>>> -------- Original Message --------\n>>> Subject: Forum e-mail notifications and PBL blacklist and wiki\n>>> registration\n>>> Date: Thu, 29 Jul 2010 03:18:56 +0100\n>>> From: Satoshi Nakamoto <satoshin@gmx.com>\n>>> To: Martti Malmi <mmalmi@cc.hut.fi>\n>>>\n>>> http://www.bitcoin.org/smf/index.php?topic=338.0\n>>>\n>>>> of e-mail blackhole list or at least the ISP that hosts the\n>>>> e-mail  server for registration is on one of those lists.\n>>>>\n>>>> \"Looks like bitcoin.org is listed on the PBL.\"\n>>>> http://www.spamhaus.org/pbl/query/PBL340779\n>>>\n>>> I think our problem may be that we have forum notifications on, like\n>>> e-mail you when you receive a PM, but we don't have e-mail verification\n>>> of new accounts.  Can someone put someone else's e-mail address without\n>>> verifying it, then have stuff sent there?  We need to stop that right\n>>> away before it gets used for something bad.  Either disallow all\n>>> notification, or make sure e-mail addresses are verified.\n>>>\n>>> I'm more inclined to disallow notifications or anything where the forum\n>>> sends you e-mail.  I kinda like not requiring e-mail verification.  But\n>>> if that's the only way to make sure we don't send e-mails to\n>>> un-verified\n>>> addresses, then we could do that.\n>>>\n>>> If we request to get off of PBL, we'd better make sure we've got the\n>>> problem secured first.\n>>>\n>>> I changed Registration->settings->registration of new members to\n>>> \"Member\n>>> Activation\".  I assume that means it e-mail verifies.\n>>> \"Member Activation\n>>> When this option is enabled any members registering to the forum will\n>>> have a activation link emailed to them which they must click before\n>>> they\n>>> can become full members\"\n>>>\n>>> I think that's the only way to make sure the forum can't be used to\n>>> send\n>>> to other people's e-mail addresses and potentially use it to spam.\n>>\n>>\n>>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-230","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1}],"id":"x86"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] ALERT - we are investigating a problem","u":"https://mmalmi.github.io/satoshi/#email-231","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1281904648,"b":[["t","*** WARNING ***  We are investigating a problem.  DO NOT TRUST ANY\nTRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638)\nuntil the issue is resolved.\n\n------------------------------------------------------------------------------\nThis SF.net email is sponsored by\n\nMake an app they can't live without\nEnter the BlackBerry Developer Challenge\nhttp://p.sf.net/sfu/RIM-dev2dev "],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-231","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x87"},{"k":"x","s":"martti-malmi","t":"[Fwd: SweepMines now accept bitcoins]","u":"https://mmalmi.github.io/satoshi/#email-232","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1282876603,"b":[["t","-------- Original Message --------\nSubject: \tSweepMines now accept bitcoins\nDate: \tTue, 24 Aug 2010 19:50:47 +0600\nFrom: \tKirill Kisel <kisel2626@gmail.com>\nTo: \tsatoshin@gmx.com\n\nDear BitCoin.\n\nhttp://apps.facebook.com/sweepmines/ now accepts BitCoins.\n\nThis is single-player computer game based on Windows Minesweeper version.\n\nWould you be so kind to add us to the http://www.bitcoin.org/trade page?\n\nThank you."]],"u":"https://mmalmi.github.io/satoshi/#email-232","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x88"},{"k":"x","s":"martti-malmi","t":"Bookkeeping","u":"https://mmalmi.github.io/satoshi/#email-233","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1285507630,"b":[["t","+1829€\n-23,32€ August hosting bill\n-24,40 September hosting bill"]],"u":"https://mmalmi.github.io/satoshi/#email-233","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1285510637,"b":[["q","+1829€\n-23,32€ August hosting bill\n-24,40 September hosting bill"],["t","--------\n+1781,28"]],"u":"https://mmalmi.github.io/satoshi/#email-234","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bookkeeping"}],"id":"x89"},{"k":"x","s":"martti-malmi","t":"SMF php code","u":"https://mmalmi.github.io/satoshi/#email-235","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1286137649,"b":[["t","I noticed my custom captcha stuff is gone.  I guess it got lost in an\nupgrade?  What are we doing for captcha now?  If we only have default\ncaptcha, we'd be getting flooded with spam accounts.  Do I need to\nre-integrate the custom captcha stuff or do we have another solution now?"]],"u":"https://mmalmi.github.io/satoshi/#email-235","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1286206910,"b":[["t","Sorry, I didn't notice your custom code when updating. Re-integration\nis a good idea if it's not too much work. I've removed hundreds of\nspam accounts by making a search for old accounts that have a webpage\nurl and 0 posts."],["q","I noticed my custom captcha stuff is gone.  I guess it got lost in an\nupgrade?  What are we doing for captcha now?  If we only have default\ncaptcha, we'd be getting flooded with spam accounts.  Do I need to\nre-integrate the custom captcha stuff or do we have another solution\nnow?"]],"u":"https://mmalmi.github.io/satoshi/#email-236","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: SMF php code"},{"f":"Satoshi Nakamoto","d":1286219126,"b":[["t","I reuploaded the changes.  For future reference, the files in Sources\nwith customisations are:\nRegister.php\nPersonalMessage.php\nManageRegistration.php\nSubs.php\n\nLet me know whenever you do an upgrade so I can make sure all my changes\nsurvived.\n\nHopefully the 1.1.x line is mature and updates are infrequent.  We\nshouldn't upgrade to 2.0.  I made a ton of customisations that wouldn't\nbe compatible, and I kind of prefer the look of 1.1 over 2.0 anyway.\n\nThe captcha url has mycode=4 added to it, and the register page has\nextra hidden mycode=2 through 5 images so any automated thing wouldn't\nknow which one to pick.  Everything that uses captcha has to have that\nmycode=4 thing added.  Something in sending personal messages also uses\ncaptcha."],["q","Sorry, I didn't notice your custom code when updating. Re-integration is\na good idea if it's not too much work. I've removed hundreds of spam\naccounts by making a search for old accounts that have a webpage url and\n0 posts.\n\n> I noticed my custom captcha stuff is gone.  I guess it got lost in an\n> upgrade?  What are we doing for captcha now?  If we only have default\n> captcha, we'd be getting flooded with spam accounts.  Do I need to\n> re-integrate the custom captcha stuff or do we have another solution\n> now?","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-237","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: SMF php code"}],"id":"x90"},{"k":"x","s":"martti-malmi","t":"[Fwd: Bitcoin.org is down]","u":"https://mmalmi.github.io/satoshi/#email-238","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1291165117,"b":[["t","-------- Original Message --------\nSubject: Bitcoin.org is down\nDate: Tue, 30 Nov 2010 18:27:02 -0600\nFrom: theymos <theymos@mm.st>\nTo: satoshin@gmx.com\n\nBitcoin.org has been down for several hours."]],"u":"https://mmalmi.github.io/satoshi/#email-238","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x91"},{"k":"x","s":"martti-malmi","t":"What was the bitcoin.org outage?","u":"https://mmalmi.github.io/satoshi/#email-239","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1291327256,"b":[["t","Do you know what caused that outage?  Did it need to be rebooted, or was\nit a DoS or something?  The IP was pingable during the outage.\n\nDid you get back to davidonpda about his doing a mirror backup?  I think\nthat's a really good idea.  Do you do any backups, or the VPS do any for\nyou automatically?"]],"u":"https://mmalmi.github.io/satoshi/#email-239","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1291370933,"b":[["q","Do you know what caused that outage?  Did it need to be rebooted, or\nwas it a DoS or something?  The IP was pingable during the outage."],["t","I don't know what it was. It started working again when I rebooted it.\nSomeone suggested it might have been the heavy load from a Reddit post\nabout Bitcoin. Inspecting the logs would be useful, but I don't have\nmuch time now."],["q","Did you get back to davidonpda about his doing a mirror backup?  I\nthink that's a really good idea.  Do you do any backups, or the VPS do\nany for you automatically?"],["t","I told him to go ahead. I don't do automatic backups atm. We should\nhave more server admins soon when I get bitcoinexchange.com to another\nserver. I could give the root password to you and somebody else. Xunie\nhas volunteered, but we might find somebody even more professional  outage was due to heavy load, he could help us move to lighttpd or\noptimize resources otherwise. Should we make a recruitment thread on\nthe forum?"]],"u":"https://mmalmi.github.io/satoshi/#email-240","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: What was the bitcoin.org outage?"},{"f":"Satoshi Nakamoto","d":1291406320,"b":[["q","I told him to go ahead. I don't do automatic backups atm. We should have\nmore server admins soon when I get bitcoinexchange.com to another\nserver. I could give the root password to you and somebody else. Xunie\nhas volunteered, but we might find somebody even more professional from\nthe forum and keep the number of admins at the minimum. If the outage\nwas due to heavy load, he could help us move to lighttpd or optimize\nresources otherwise. Should we make a recruitment thread on the forum?"],["t","It should be Gavin.  I trust him, he's responsible, professional, and\ntechnically much more linux capable than me.\n\n(I don't know Xunie, but he hasn't posted for months and he was a goofball)"]],"u":"https://mmalmi.github.io/satoshi/#email-241","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: What was the bitcoin.org outage?"},{"f":"mmalmi@cc.hut.fi","d":1291635181,"b":[["t","I'm ready to send you the password. Can you send me your PGP key so I\ndon't have to send it in plaintext?"],["q","It should be Gavin.  I trust him, he's responsible, professional, and\ntechnically much more linux capable than me."],["t","Ok, I'll ask him."]],"u":"https://mmalmi.github.io/satoshi/#email-242","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: What was the bitcoin.org outage?"},{"f":"Satoshi Nakamoto","d":1291651736,"b":[["q","I'm ready to send you the password. Can you send me your PGP key so I\ndon't have to send it in plaintext?\n\n> It should be Gavin.  I trust him, he's responsible, professional, and\n> technically much more linux capable than me.\n\nOk, I'll ask him.","mmalmi@cc.hut.fi wrote:"],["t","Thanks, did you finish moving bitcoinexchange to another server?\n\n-----BEGIN PGP PUBLIC KEY BLOCK-----\nVersion: GnuPG v1.4.7 (MingW32)\n\nmQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r\npiOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6\nVxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW\ndBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv\n/LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow\nmXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE\ngAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5\nHHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7\nFZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO\nYWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH\nAwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q\nRME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t\ndZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs\nSGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ\nLrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO\nXRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME\nI7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq\nsUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c\nICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK\nMqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu\nO5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0\nUwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ\nA25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ\nEBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R\n8RHwN4Gk8w==\n=3FTe\n-----END PGP PUBLIC KEY BLOCK-----\n\nIt's also at\nhttp://www.bitcoin.org/Satoshi_Nakamoto.asc"]],"u":"https://mmalmi.github.io/satoshi/#email-243","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: What was the bitcoin.org outage?"},{"f":"mmalmi@cc.hut.fi","d":1291689458,"b":[["t","Attached is the root password encrypted."],["q","Thanks, did you finish moving bitcoinexchange to another server?"],["t","I moved all the files, database and bitcoind, but still some work\nneeded to get it running. The old site is down atm anyway, so feel\nfree to reboot if needed."]],"u":"https://mmalmi.github.io/satoshi/#email-244","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: What was the bitcoin.org outage?"}],"id":"x92"},{"k":"x","s":"martti-malmi","t":"Project Developers","u":"https://mmalmi.github.io/satoshi/#email-245","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1291736308,"b":[["t","Mind if I add you to the Project Developers list on the Contact page?\nYou wrote some code before so you should be there.  It would have to be\nyour real name for consistency.  If you want to have an e-mail address\nlisted, I'll make an image out of it so it doesn't attract spam."]],"u":"https://mmalmi.github.io/satoshi/#email-245","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1},{"f":"mmalmi@cc.hut.fi","d":1291738378,"b":[["t","Ok. You can include the e-mail address."],["q","Mind if I add you to the Project Developers list on the Contact page?\nYou wrote some code before so you should be there.  It would have to be\nyour real name for consistency.  If you want to have an e-mail address\nlisted, I'll make an image out of it so it doesn't attract spam."]],"u":"https://mmalmi.github.io/satoshi/#email-246","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Project Developers"}],"id":"x93"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] Bitcoin 0.3.18 is released","u":"https://mmalmi.github.io/satoshi/#email-247","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1291849785,"b":[["t","Version 0.3.18 is now available.\n\nChanges:\n- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17\nand then upgraded again\n- IsStandard() check to only include known transaction types in blocks\n- Jgarzik's optimisation to speed up the initial block download a little\n\nThe main addition in this release is the Accounts-based JSON-RPC\ncommands that Gavin's been working on (more details at\nhttp://www.bitcoin.org/smf/index.php?topic=1886.0).\n- getaccountaddress\n- sendfrom\n- move\n- getbalance\n- listtransactions\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/\n\n------------------------------------------------------------------------------\nThis SF Dev2Dev email is sponsored by:\n\nWikiLeaks The End of the Free Internet\nhttp://p.sf.net/sfu/therealnews-com"],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-247","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x94"},{"k":"x","s":"martti-malmi","t":"Resizing Bitcoin server","u":"https://mmalmi.github.io/satoshi/#email-248","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1292092592,"b":[["t","Bitcoin.org was down again today for some time. It responded to ping\nbut not ssh or http. I rebooted it and found out it was an out of\nmemory error and mysqld got killed. It was the same error last time,\nbut with apache getting killed. I couldn't think of anything better,\nso I resized the server from 512MB to 1024MB of memory."]],"u":"https://mmalmi.github.io/satoshi/#email-248","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Gavin Andresen <gavinandresen@gmail.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x95"},{"k":"x","s":"martti-malmi","t":"[bitcoin-list] Bitcoin 0.3.19 is released","u":"https://mmalmi.github.io/satoshi/#email-249","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1292256713,"b":[["t","This is a minor release to add some DoS protection.\n\nChanges:\n- Added some DoS limits, though it's still far from DoS resistant.\n- Removed \"safe mode\" alerts.\n\nhttp://www.bitcoin.org/smf/index.php?topic=2228.0\n\nDownload:\nhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/\n\n------------------------------------------------------------------------------\nOracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,\nnew data types, scalar functions, improved concurrency, built-in packages,\nOCI, SQL*Plus, data movement tools, best practices and more.\nhttp://p.sf.net/sfu/oracle-sfdev2dev "],["f","bitcoin-list mailing list\nbitcoin-list@lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://mmalmi.github.io/satoshi/#email-249","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"bitcoin-list@lists.sourceforge.net","fe":"satoshin@gmx.com","s":1}],"id":"x96"},{"k":"x","s":"martti-malmi","t":"Bitcoin.org backups","u":"https://mmalmi.github.io/satoshi/#email-250","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1292860504,"b":[["t","ShadowOfHarbringer described a way of mirroring the bitcoin.org\nwebsite and forum here:\nhttp://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043\n\nShould we go by it and trust the database along with its password\nhashes to some reliable community members who have servers? Another\noption is to encrypt the backups with pgp and store them in multiple\nplaces."]],"u":"https://mmalmi.github.io/satoshi/#email-250","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Gavin Andresen <gavinandresen@gmail.com>, Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1292868606,"b":[["q","On Mon, Dec 20, 2010 at 10:55 AM,  <mmalmi@cc.hut.fi> wrote:\n> ShadowOfHarbringer described a way of mirroring the bitcoin.org website and\n> forum here:\n> http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043\n>\n> Should we go by it and trust the database along with its password hashes to\n> some reliable community members who have servers?\n\nThat seems like asking for trouble, and I think it would violate the\nimplicit trust of everybody who's registered for the forums.","Gavin Andresen wrote:"],["t","I agree, don't let the database out of your hands.  There's private PM\nin there, e-mail addresses, passwords.\n\nBTW, password hashes = passwords.  It's easy to break the hash of short\npasswords people use on forums.\n6 chars = 3 difficulty\n7 chars = 410 difficulty\n8 chars = 25418 difficulty"],["q","> Another option is to\n> > encrypt the backups with pgp and store them in multiple places.\n\nThat seems wiser.  Daily backups copied ... somewhere ... seems like\nthe right thing to do.  If they're reasonably small (less than a\ngigabyte), I'd be happy to pay for Amazon S3 storage/bandwidth for\nthem."],["t","+1\n\nEven with encryption, a trusted storage place is better."]],"u":"https://mmalmi.github.io/satoshi/#email-251","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Gavin Andresen <gavinandresen@gmail.com>","fe":"satoshin@gmx.com","s":1,"sj":"Re: Bitcoin.org backups"},{"f":"mmalmi@cc.hut.fi","d":1292880087,"b":[["t","Ok. I'll start backing up to another server I'm using. I'll send you\nthe SSH key when I've set it up, so you can start backing up to any\nserver you want. The backup file size is about 50 MB atm.\n\nHere's my pgp key btw: http://www.bitcoin.org/mmalmi.asc"],["q","Gavin Andresen wrote:\n> On Mon, Dec 20, 2010 at 10:55 AM,  <mmalmi@cc.hut.fi> wrote:\n>> ShadowOfHarbringer described a way of mirroring the bitcoin.org website and\n>> forum here:\n>> http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043\n>>\n>> Should we go by it and trust the database along with its password hashes to\n>> some reliable community members who have servers?\n>\n> That seems like asking for trouble, and I think it would violate the\n> implicit trust of everybody who's registered for the forums.\n\nI agree, don't let the database out of your hands.  There's private PM\nin there, e-mail addresses, passwords.\n\nBTW, password hashes = passwords.  It's easy to break the hash of short\npasswords people use on forums.\n6 chars = 3 difficulty\n7 chars = 410 difficulty\n8 chars = 25418 difficulty\n\n>> Another option is to\n>>> encrypt the backups with pgp and store them in multiple places.\n>\n> That seems wiser.  Daily backups copied ... somewhere ... seems like\n> the right thing to do.  If they're reasonably small (less than a\n> gigabyte), I'd be happy to pay for Amazon S3 storage/bandwidth for\n> them.\n\n+1\n\nEven with encryption, a trusted storage place is better."]],"u":"https://mmalmi.github.io/satoshi/#email-252","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org backups"},{"f":"mmalmi@cc.hut.fi","d":1292939042,"b":[["t","You can fetch the backup with:\nwget --no-check-certificate\nhttps://backup:cAr26Ram@www.bitcoin.org/backup/bitcoinsite.tar.bz2.gpg\n\nIt's updated every day 11:00 GMT."]],"u":"https://mmalmi.github.io/satoshi/#email-253","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mmalmi@cc.hut.fi","sj":"Re: Bitcoin.org backups"}],"id":"x97"},{"k":"x","s":"mike-hearn","t":"More BitCoin questions","u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","m":[{"f":"Mike Hearn","d":1293481260,"b":[["t","Happy Christmas Satoshi, assuming you celebrate it wherever you are in\nthe world :-)\n\nI have been working on a Java implementation of the simplified payment\nverification, with an eye to building a client that runs on Android\nphones. So I've been thinking a lot about storage requirements and the\nscalability of BitCoin, which led to some questions that the paper did\nnot answer (maybe there could be a new version of the paper at some\npoint, as I think aspects of it are now out of date).\n\nSpecifically, BitCoin has a variety of magic numbers and neither the\ncode nor the paper explain where they came from. For example, the fact\nthat inflation ceases when 21 million coins have been issued. This\nnumber must have been arrived at somehow, but I can't see how.\n\nAnother is the 10 minute block target. I understand this was chosen to\nallow transactions to propagate through the network. However existing\nlarge P2P networks like BGP can propagate new data worldwide in <1\nminute.\n\nThe final number I'm interested in is the 500kb limit on block sizes.\nAccording to Wikipedia, Visa alone processed 62 billion transactions\nin 2009. Dividing through we get an average of 2000 transactions per\nsecond, so peak rate is probably around double that at 4000\ntransactions/sec. With a ten minute block target, at peak a block\nmight need to contain 2.4 million transactions, which just won't fit\ninto 500kb. Is this 500kb a temporary limitation that will be slowly\nremoved over time from the official client or something more\nfundamental?"]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1293662520,"b":[["t","I have been working on a Java implementation of the simplified payment\nverification, with an eye to building a client that runs on Android\nphones. So I've been thinking a lot about storage requirements and the\nscalability of BitCoin, which led to some questions that the paper did\nnot answer (maybe there could be a new version of the paper at some\npoint, as I think aspects of it are now out of date).\n\nThe simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server.\n\nInstead, I think client-only nodes should receive full blocks so they can scan them for their own transactions.  They don't need to store them or index them.  For the initial download, they only need to download headers, since there couldn't be any payments before the first time the program was run (a header download command was added in 0.3.18).  From then on, they download full blocks (but only store the headers).\n\nCode for client-only mode is mostly implemented.  There's a feature branch on github with it, also I'm attaching the patch to this message.\n\nHere's some more about it:\n\n\"Here's my client-mode implementation so far.  Client-only mode only records block headers and doesn't use the tx index.  It can't generate, but it can still send and receive transactions.  It's not fully finished for use by end-users, but it doesn't matter because it's a complete no-op if fClient is not enabled.  At this point it's mainly documentation showing the cut-lines for client-only re-implementers.\n\nWith fClient=true, I've only tested the header-only initial download.\n\nA little background.  CBlockIndex contains all the information of the block header, so to operate with headers only, I just maintain the CBlockIndex structure as usual.  The nFile/nBlockPos are null, since the full block is not recorded on disk.\n\nThe code to gracefully switch between client-mode on/off without deleting blk*.dat in between is not implemented yet.  It would mostly be a matter of having non-client LoadBlockIndex ignore block index entries with null block pos.  That would make it re-download those as full blocks.  Switching back to client-mode is no problem, it doesn't mind if the full blocks are there.\n\nIf the initial block download becomes too long, we'll want client mode as an option so new users can get running quickly.  With graceful switch-off of client mode, they can later turn off client mode and have it download the full blocks if they want to start generating.  They should rather just use a getwork miner to join a pool instead.\n\nClient-only re-implementations would not need to implement EvalScript at all, or at most just implement the five ops used by the standard transaction templates.\"\n\nSpecifically, BitCoin has a variety of magic numbers and neither the\ncode nor the paper explain where they came from. For example, the fact\nthat inflation ceases when 21 million coins have been issued. This\nnumber must have been arrived at somehow, but I can't see how.\n\nEducated guess, and the maths work out to round numbers.  I wanted something that would be not too low if it was very popular and not too high if it wasn't.\n\nAnother is the 10 minute block target. I understand this was chosen to\nallow transactions to propagate through the network. However existing\nlarge P2P networks like BGP can propagate new data worldwide in <1\nminute.\n\nIf propagation is 1 minute, then 10 minutes was a good guess.  Then nodes are only losing 10% of their work (1 minute/10 minutes).  If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of.  An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage.  The chain would temporarily fork more often due to latency.\n\nThe final number I'm interested in is the 500kb limit on block sizes.\nAccording to Wikipedia, Visa alone processed 62 billion transactions\nin 2009. Dividing through we get an average of 2000 transactions per\nsecond, so peak rate is probably around double that at 4000\ntransactions/sec. With a ten minute block target, at peak a block\nmight need to contain 2.4 million transactions, which just won't fit\ninto 500kb. Is this 500kb a temporary limitation that will be slowly\nremoved over time from the official client or something more\nfundamental?\n\nA higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.\n\nEventually when we have client-only implementations, the block chain size won't matter much.  Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.\n\nWith very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only.  With dev work on optimising and parallelising, it can keep scaling up.\n\nWhatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.\n\ndiff -u old\\db.cpp new\\db.cpp\n--- old\\db.cpp  Sat Dec 18 18:35:59 2010\n+++ new\\db.cpp  Sun Dec 19 20:53:59 2010\n@@ -464,29 +464,32 @@\n     ReadBestInvalidWork(bnBestInvalidWork);\n\n     // Verify blocks in the best chain\n-    CBlockIndex* pindexFork = NULL;\n-    for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)\n+    if (!fClient)\n     {\n-        if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count(\"-checkblocks\"))\n-            break;\n-        CBlock block;\n-        if (!block.ReadFromDisk(pindex))\n-            return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\n-        if (!block.CheckBlock())\n+        CBlockIndex* pindexFork = NULL;\n+        for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)\n         {\n-            printf(\"LoadBlockIndex() : *** found bad block at %d, hash=%s\\n\", pindex->nHeight, pindex->GetBlockHash().ToString().c_str());\n-            pindexFork = pindex->pprev;\n+            if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count(\"-checkblocks\"))\n+                break;\n+            CBlock block;\n+            if (!block.ReadFromDisk(pindex))\n+                return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\n+            if (!block.CheckBlock())\n+            {\n+                printf(\"LoadBlockIndex() : *** found bad block at %d, hash=%s\\n\", pindex->nHeight, pindex->GetBlockHash().ToString().c_str());\n+                pindexFork = pindex->pprev;\n+            }\n+        }\n+        if (pindexFork)\n+        {\n+            // Reorg back to the fork\n+            printf(\"LoadBlockIndex() : *** moving best chain pointer back to block %d\\n\", pindexFork->nHeight);\n+            CBlock block;\n+            if (!block.ReadFromDisk(pindexFork))\n+                return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\n+            CTxDB txdb;\n+            block.SetBestChain(txdb, pindexFork);\n         }\n-    }\n-    if (pindexFork)\n-    {\n-        // Reorg back to the fork\n-        printf(\"LoadBlockIndex() : *** moving best chain pointer back to block %d\\n\", pindexFork->nHeight);\n-        CBlock block;\n-        if (!block.ReadFromDisk(pindexFork))\n-            return error(\"LoadBlockIndex() : block.ReadFromDisk failed\");\n-        CTxDB txdb;\n-        block.SetBestChain(txdb, pindexFork);\n     }\n\n     return true;\ndiff -u old\\main.cpp new\\main.cpp\n--- old\\main.cpp        Sat Dec 18 18:35:59 2010\n+++ new\\main.cpp        Sun Dec 19 20:53:59 2010\n@@ -637,6 +637,9 @@\n     if (!IsStandard())\n         return error(\"AcceptToMemoryPool() : nonstandard transaction type\");\n\n+    if (fClient)\n+        return true;\n+\n     // Do we already have it?\n     uint256 hash = GetHash();\n     CRITICAL_BLOCK(cs_mapTransactions)\n@@ -1308,23 +1311,26 @@\n     if (!CheckBlock())\n         return false;\n\n-    //// issue here: it doesn't know the version\n-    unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size());\n-\n-    map<uint256, CTxIndex> mapUnused;\n-    int64 nFees = 0;\n-    foreach(CTransaction& tx, vtx)\n+    if (!fClient)\n     {\n-        CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);\n-        nTxPos += ::GetSerializeSize(tx, SER_DISK);\n+        //// issue here: it doesn't know the version\n+        unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size());\n+\n+        map<uint256, CTxIndex> mapUnused;\n+        int64 nFees = 0;\n+        foreach(CTransaction& tx, vtx)\n+        {\n+            CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);\n+            nTxPos += ::GetSerializeSize(tx, SER_DISK);\n\n-        if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))\n+            if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))\n+                return false;\n+        }\n+\n+        if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))\n             return false;\n     }\n\n-    if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))\n-        return false;\n-\n     // Update block index on disk without changing it in memory.\n     // The memory index structure will be changed after the db commits.\n     if (pindex->pprev)\n@@ -1378,7 +1384,7 @@\n     foreach(CBlockIndex* pindex, vDisconnect)\n     {\n         CBlock block;\n-        if (!block.ReadFromDisk(pindex))\n+        if (!block.ReadFromDisk(pindex, !fClient))\n             return error(\"Reorganize() : ReadFromDisk for disconnect failed\");\n         if (!block.DisconnectBlock(txdb, pindex))\n             return error(\"Reorganize() : DisconnectBlock failed\");\n@@ -1395,7 +1401,7 @@\n     {\n         CBlockIndex* pindex = vConnect[i];\n         CBlock block;\n-        if (!block.ReadFromDisk(pindex))\n+        if (!block.ReadFromDisk(pindex, !fClient))\n             return error(\"Reorganize() : ReadFromDisk for connect failed\");\n         if (!block.ConnectBlock(txdb, pindex))\n         {\n@@ -1526,7 +1532,7 @@\n\n     txdb.Close();\n\n-    if (pindexNew == pindexBest)\n+    if (!fClient && pindexNew == pindexBest)\n     {\n         // Notify UI to display prev block's coinbase if it was ours\n         static uint256 hashPrevBestCoinBase;\n@@ -1547,10 +1553,6 @@\n     // These are checks that are independent of context\n     // that can be verified before saving an orphan block.\n\n-    // Size limits\n-    if (vtx.empty() || vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_SIZE)\n-        return error(\"CheckBlock() : size limits failed\");\n-\n     // Check proof of work matches claimed amount\n     if (!CheckProofOfWork(GetHash(), nBits))\n         return error(\"CheckBlock() : proof of work failed\");\n@@ -1559,6 +1561,13 @@\n     if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)\n         return error(\"CheckBlock() : block timestamp too far in the future\");\n\n+    if (fClient && vtx.empty())\n+        return true;\n+\n+    // Size limits\n+    if (vtx.empty() || vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_SIZE)\n+        return error(\"CheckBlock() : size limits failed\");\n+\n     // First transaction must be coinbase, the rest must not be\n     if (vtx.empty() || !vtx[0].IsCoinBase())\n         return error(\"CheckBlock() : first tx is not coinbase\");\n@@ -1623,13 +1632,14 @@\n         return error(\"AcceptBlock() : out of disk space\");\n     unsigned int nFile = -1;\n     unsigned int nBlockPos = 0;\n-    if (!WriteToDisk(nFile, nBlockPos))\n-        return error(\"AcceptBlock() : WriteToDisk failed\");\n+    if (!fClient)\n+        if (!WriteToDisk(nFile, nBlockPos))\n+            return error(\"AcceptBlock() : WriteToDisk failed\");\n     if (!AddToBlockIndex(nFile, nBlockPos))\n         return error(\"AcceptBlock() : AddToBlockIndex failed\");\n\n     // Relay inventory, but don't relay old inventory during initial block download\n-    if (hashBestChain == hash)\n+    if (!fClient && hashBestChain == hash)\n         CRITICAL_BLOCK(cs_vNodes)\n             foreach(CNode* pnode, vNodes)\n                 if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 55000))\n@@ -2405,6 +2415,8 @@\n         {\n             if (fShutdown)\n                 return true;\n+            if (fClient && inv.type == MSG_TX)\n+                continue;\n             pfrom->AddInventoryKnown(inv);\n\n             bool fAlreadyHave = AlreadyHave(txdb, inv);\n@@ -2441,6 +2453,9 @@\n\n             if (inv.type == MSG_BLOCK)\n             {\n+                if (fClient)\n+                    return true;\n+\n                 // Send block from disk\n                 map<uint256, CBlockIndex*>::iterator mi = mapBlockIndex.find(inv.hash);\n                 if (mi != mapBlockIndex.end())\n@@ -2486,6 +2501,8 @@\n\n     else if (strCommand == \"getblocks\")\n     {\n+        if (fClient)\n+            return true;\n         CBlockLocator locator;\n         uint256 hashStop;\n         vRecv >> locator >> hashStop;\n@@ -2556,6 +2573,8 @@\n\n     else if (strCommand == \"tx\")\n     {\n+        if (fClient)\n+            return true;\n         vector<uint256> vWorkQueue;\n         CDataStream vMsg(vRecv);\n         CTransaction tx;\n@@ -2620,6 +2639,33 @@\n\n         if (ProcessBlock(pfrom, &block))\n             mapAlreadyAskedFor.erase(inv);\n+    }\n+\n+\n+    else if (strCommand == \"headers\")\n+    {\n+        if (!fClient)\n+            return true;\n+        vector<CBlock> vHeaders;\n+        vRecv >> vHeaders;\n+\n+        uint256 hashBestBefore = hashBestChain;\n+        foreach(CBlock& block, vHeaders)\n+        {\n+            block.vtx.clear();\n+\n+            printf(\"received header %s\\n\", block.GetHash().ToString().substr(0,20).c_str());\n+\n+            CInv inv(MSG_BLOCK, block.GetHash());\n+            pfrom->AddInventoryKnown(inv);\n+\n+            if (ProcessBlock(pfrom, &block))\n+                mapAlreadyAskedFor.erase(inv);\n+        }\n+\n+        // Request next batch\n+        if (hashBestChain != hashBestBefore)\n+            pfrom->PushGetBlocks(pindexBest, uint256(0));\n     }\n\ndiff -u old\\main.h new\\main.h\n--- old\\main.h  Sat Dec 18 18:35:59 2010\n+++ new\\main.h  Sun Dec 19 20:53:59 2010\n@@ -619,6 +619,8 @@\n\n     bool ReadFromDisk(CDiskTxPos pos, FILE** pfileRet=NULL)\n     {\n+        assert(!fClient);\n+\n         CAutoFile filein = OpenBlockFile(pos.nFile, 0, pfileRet ? \"rb+\" : \"rb\");\n         if (!filein)\n             return error(\"CTransaction::ReadFromDisk() : OpenBlockFile failed\");\n@@ -1174,6 +1176,7 @@\n\n     bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)\n     {\n+        assert(!fClient);\n         SetNull();\n\n         // Open history file to read\n@@ -1231,7 +1234,7 @@\n\n //\n-// The block chain is a tree shaped structure starting with the\n+// The block index is a tree shaped structure starting with the\n // genesis block at the root, with each block potentially having multiple\n // candidates to be the next block.  pprev and pnext link a path through the\n // main/longest chain.  A blockindex may have multiple pprev pointing back\ndiff -u old\\net.cpp new\\net.cpp\n--- old\\net.cpp Wed Dec 15 22:33:09 2010\n+++ new\\net.cpp Sun Dec 19 21:51:27 2010\n@@ -51,7 +51,15 @@\n     pindexLastGetBlocksBegin = pindexBegin;\n     hashLastGetBlocksEnd = hashEnd;\n\n-    PushMessage(\"getblocks\", CBlockLocator(pindexBegin), hashEnd);\n+    /// Client todo: After the initial block header download, start using getblocks\n+    /// here instead of getheaders.  For blocks generated after the first time the\n+    /// program was run, we need to download full blocks to watch for received\n+    /// transactions in them.  We're able to download headers only for blocks\n+    /// generated before we ever ran because they can't contain txes for us.\n+    if (::fClient)\n+        PushMessage(\"getheaders\", CBlockLocator(pindexBegin), hashEnd);\n+    else\n+        PushMessage(\"getblocks\", CBlockLocator(pindexBegin), hashEnd);\n }"]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1293668820,"b":[["t","Thanks for the info.\n\nI reached the same conclusions about client only nodes and this is\nwhat I've been implementing. I'm nearly there ..... I have block chain\ndownload, parsing and verification of the blocks/transactions done,\nwith creation of spend transactions almost done.\n\nv1 will basically do as you propose, with the possible optimization of\nstoring only the blocks needed to form the block locator (with the\nexponential thinning). As Android provides local storage that is\nprivate to the app, you don't need to store the entire block chain to\nbe able to accept new blocks ... just enough to ensure you can always\nstay on the longest chain.\n\nBy the way, your code is easy to read and has been an invaluable\nreference. So thanks for that.\n\nIn v2 I'm thinking of showing transactions before they are integrated\ninto the block chain by running secure/locked down relay nodes that\nsend messages to the phones when a transaction is accepted into the\nmemory pool. Android provides a secure, low power back channel to\nevery phone. Messages are stored server side if the device is offline\nand apps are automatically started on the phone to handle incoming\nmessages.\n\nSo as long as the relay nodes are unhacked, this system should give\nenough trust that low value transactions can be shown in the UI\nimmediately. It introduces some centralization/single points of\nfailure, but if the relay mechanism dies or is hacked, the damage only\nlasts for 10 minutes until the new blocks are downloaded."],["q","Client-only re-implementations would not need to implement EvalScript at\nall, or at most just implement the five ops used by the standard transaction\ntemplates.\""],["t","Indeed, there's no point in client-only implementations implementing\nEvalScript because they can't verify transactions aren't being double\nspent without storing and indexing the entire block chain. My code\nparses the scripts and then relies on them having a standard\nstructure, but doesn't actually run them."],["q","Educated guess, and the maths work out to round numbers.  I wanted something\nthat would be not too low if it was very popular and not too high if it\nwasn't."],["t","It'd be interesting to see the working for this. In some sense the\nnumber of coins is arbitrary as the nanocoin representation means the\nissuance is so huge it's practically infinite."],["q","A higher limit can be phased in once we have actual use closer to the limit\nand make sure it's working OK."],["t","It'd be worth implementing some kind of more robust auto update\nmechanism, or a schedule for the phase in of this, if only because\nwhen people evaluate \"is BitCoin worth my time and effort\" a solid\nplan for scaling up is good to have written down.\n\nI'm not worried about the physical capabilities of the hardware, but\nmore protocol ossification as the app is reimplemented and nodes which\ndon't auto-update themselves increase in number. Client only\nreimplementations pose no problems of course, but other systems like\nSMTP have proven impossible to globally upgrade despite having\nextension mechanisms built in .... just too many implementations and\ntoo many installations."]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1294405200,"b":[["t","I reached the same conclusions about client only nodes and this is\nwhat I've been implementing. I'm nearly there ..... I have block chain\ndownload, parsing and verification of the blocks/transactions done,\nwith creation of spend transactions almost done.\n\nThat's great!  The first client-only implementation will really start to move things to the next step.  Is it going to be open source, or Google proprietary?"]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1294406640,"b":[["q","That's great!  The first client-only implementation will really start to\nmove things to the next step.  Is it going to be open source, or Google\nproprietary?"],["t","Open source. It has to be - I am developing it as a personal project\nin my spare time and Googles policy is that this is only allowed if\nyou open source the results. But I would have done that anyway.\n\nI managed to spend my first coins on the testnet with my app a few\ndays ago, hopefully will get another chance to make progress this\nweekend. Probably will have something to show publically sometime in\nFeb, touch wood."]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1294677240,"b":[["t","Open source.\n\nPerfect.  Once your code shows how to simplify it down, other authors can follow your lead.  Client is a less daunting challenge than full implementation.  If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of.  I expect the original software will become the industrial old thing used by GPU farms and pool servers.\n\nBTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send.\n\nI managed to spend my first coins on the testnet with my app a few\ndays ago, hopefully will get another chance to make progress this\nweekend. Probably will have something to show publically sometime in\nFeb, touch wood.\n\nGreat, keep me updated.\n\nI wanted something\nthat would be not too low if it was very popular and not too high if it\nwasn't.\n\n It'd be interesting to see the working for this. In some sense the\nnumber of coins is arbitrary as the nanocoin representation means the\nissuance is so huge it's practically infinite.\n\nIt works out to an even 10 minutes per block:\n21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour\n\nI fudged it to 364.58333 days/year.  The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort.\n\nI thought about 100 BTC and 42 million, but 42 million seemed high.\n\nI wanted typical amounts to be in a familiar range.  If you're tossing around 100000 units, it doesn't feel scarce.  The brain is better able to work with numbers from 0.01 to 1000.\n\nIf it gets really big, the decimal can move two places and cents become the new coins."]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1294678080,"b":[["t","Ah, of course, that makes sense. \n\nBy the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:\n\nhttp://www.bitcoin.org/smf/index.php?topic=2699.0\n\nHal (i presume this is Hal Finney) seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1294692420,"b":[["t","By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:\n\nhttp://www.bitcoin.org/smf/index.php?topic=2699.0\n\nHal (i presume this is Hal Finney)\n\nYes, it's him.  He was supportive on the Cryptography list and ran one of the first nodes.\n\nseems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?\n\nI must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues.  I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new.  I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security.  I didn't find anything to recommend a curve type so I just... picked one.  Hopefully there is enough key size to make up for any deficiency.\n\nAt the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA.  RSA's huge keys were out of the question.  Storage and bandwidth seemed tighter back then.  I felt the size was either only just becoming practical, or would be soon.  When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved.\n\nAs it turns out, ECDSA verification time may be the greater bottleneck.  (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second)  Client versions bypass the problem.\n\nAs things have evolved, the number of people who need to run full nodes is less than I originally imagined.  The network would be fine with a small number of nodes if processing load becomes heavy."]],"u":"https://plan99.net/~mike/satoshi-emails/thread3.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread3.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"}],"id":"x98"},{"k":"x","s":"martti-malmi","t":"Re: Writing about BitCoin","u":"https://mmalmi.github.io/satoshi/#email-254","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1294338686,"b":[["q","I'd be happy to talk to Rainey; ","Gavin Andresen wrote:"],["t","Great"],["q","Satoshi, I assume you don't want to\ndeal with press/PR/interviews ?"],["t","True"],["q","We could decline to talk to the press-- Satoshi, I know you've\nexpressed concern about bitcoin growing too big too fast, and being\nunable to keep up with traffic/attacks/feature requests/etc.  But I\ndon't think ignoring the press will make them go away; they'll just\ntalk to somebody else.  I think it is better to give a realistic\nimpression of bitcoin (it is cutting-edge, beta software that is still\nbeing developed, it is not poised to replace PayPal or the Euro\nanytime soon, etc) rather than let somebody over-enthusiastic become\n\"the unofficial bitcoin spokesperson.\""],["t","You're the best person to do it.\n\nEFF is really important.  We want to have a good relationship with them.\n  We're the type of project they like; they've helped the TOR project\nand done a lot to protect P2P file sharing."]],"u":"https://mmalmi.github.io/satoshi/#email-254","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Gavin Andresen <gavinandresen@gmail.com>","fe":"satoshin@gmx.com","s":1}],"id":"x99"},{"k":"x","s":"martti-malmi","t":"Fwd: Bitcoin question","u":"https://mmalmi.github.io/satoshi/#email-255","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1295940312,"b":[["t","Martti,\nThank you for the pdf. It looks great. I do not see a date on it. When was it written?\n\nMr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my attention for inclusion in my thesis. The thesis working title is: Digital Currency Systems: Emerging B2B e-Commerce Alternative During Monetary Crisis in the United States. I discuss the five types of systems per Mr. Herpels suggestion.\n\nAppreciate it and hope to talk soon.\n\nC.\n\nConstance J. Wells, CeM, PMP: PMI certified\nDenver, CO   U.S.A.\n303-730-6609\n\n--- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:\n\nFrom: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>\nSubject: Re:\nTo: \"Constance J. Wells\"\n<cjwells_1@yahoo.com>\nDate: Monday, January 24, 2011, 1:22 AM\n\nHi Constance,\n\nThanks for your interest in Bitcoin, feel free to cite. There's also Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf if you want something with a more formal touch. Please let us know when your thesis is finished!\n\n-Martti"],["q","Martti Malmi\nCurrently I am a full time student at-\nhttp://info.aspen.edu/\nAspen University, in Denver, CO, 303-333-4224.\nMasters of Science in Technology and Innovation.\n\nI am writing my Thesis under the subject heading, digital currency  systems. May I cite your site in my Thesis?\n\nThank you.\nConstance\nConstance J. Wells, CeM,"],["t","PMP: PMI certified"],["q","Denver, CO   U.S.A.\n303-730-6609"]],"u":"https://mmalmi.github.io/satoshi/#email-255","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"},{"f":"Satoshi Nakamoto","d":1295980443,"b":[["t","The paper was published in 2008.\n\nSomeone needs to correct Wikipedia; it incorrectly says the paper was\npublished in 2009.  The paper was released earlier than the software."],["q","Can you comment on this?\n\n----- Forwarded message from cjwells_1@yahoo.com -----\n    Date: Mon, 24 Jan 2011 00:32:48 -0800 (PST)\n    From: \"Constance J. Wells\" <cjwells_1@yahoo.com>\nReply-To: \"Constance J. Wells\" <cjwells_1@yahoo.com>\n Subject: Re:\n      To: mmalmi@cc.hut.fi\n\nMartti,\nThank you for the pdf. It looks great. I do not see a date on it. When\nwas it written?\n\nMr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my\nattention for inclusion in my thesis. The thesis working title is:\nDigital Currency Systems: Emerging B2B e-Commerce Alternative During\nMonetary Crisis in the United States. I discuss the five types of\nsystems per Mr. Herpels suggestion.\n\nAppreciate it and hope to talk soon.\n\nC.\n\nConstance J. Wells, CeM, PMP: PMI certified\nDenver, CO   U.S.A.\n303-730-6609\n\n--- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:\n\nFrom: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>\nSubject: Re:\nTo: \"Constance J. Wells\" <cjwells_1@yahoo.com>\nDate: Monday, January 24, 2011, 1:22 AM\n\nHi Constance,\n\nThanks for your interest in Bitcoin, feel free to cite. There's also\nSatoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf\nif you want something with a more formal touch. Please let us know when\nyour thesis is finished!\n\n-Martti\n\n> Martti Malmi\n> Currently I am a full time student at-\n> http://info.aspen.edu/\n> Aspen University, in Denver, CO, 303-333-4224.\n> Masters of Science in Technology and Innovation.\n>\n> I am writing my Thesis under the subject heading, digital currency\n> systems. May I cite your site in my Thesis?\n>\n> Thank you.\n> Constance\n> Constance J. Wells, CeM, PMP: PMI certified\n> Denver, CO   U.S.A.\n> 303-730-6609\n>\n>\n>","mmalmi@cc.hut.fi wrote:"]],"u":"https://mmalmi.github.io/satoshi/#email-256","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"mmalmi@cc.hut.fi","fe":"satoshin@gmx.com","s":1,"sj":"Re: Fwd: Bitcoin question"}],"id":"x100"},{"k":"x","s":"martti-malmi","t":"Bookkeeping","u":"https://mmalmi.github.io/satoshi/#email-257","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1296414113,"b":[["t","+1781.28\n-22.63 October hosting\n-28.70 November hosting\n-30.36 December hosting\n-48.35 January hosting (server upscaled to 1024MB RAM)\n+0.78 Annual interest on deposit\n\n-------\n+1652.02\n\nSince I'm no longer maintaining bitcoinexchange.com, I'm returning the\n750€ to the project budget. I'll do this when I get a payment from the\nSMS gateway provider."]],"u":"https://mmalmi.github.io/satoshi/#email-257","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"satoshin@gmx.com","fe":"mmalmi@cc.hut.fi"}],"id":"x101"},{"k":"x","s":"martti-malmi","t":"Re: Bitcoin @ EPCA Conference Amsterdam 4-6 April?","u":"https://mmalmi.github.io/satoshi/#email-258","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"mmalmi@cc.hut.fi","d":1297071576,"b":[["t","Looks like an excellent opportunity to reach an important audience\nthat doesn't follow Slashdot or Reddit. I'd recommend this job for\nGavin or Bruce Wagner. Or maybe there can be two attendees. S3052 from\nthe forum also seemed potentially competent.\n\nGavin, would you be interested in organizing this?"],["q","Hello,\n\nI am writing you on behalf of the EPCA Conference because we are\ninterested to learn more about Bitcoin. Possibly Bitcoin is an\ninteresting topic for the upcoming conference 4-6 April in Amsterdam.\n\nAt this top rated conference we deal with the key strategic\ndevelopments in the 'transaction industry' so not limited to\npayments. The event is truly 'professional for professional', so\nevery presentation is screened on quality and relevance (no sales\npitches). See also:\nwww.epcaconference.com<http://www.epcaconference.com> .\n\nSince we discuss the most relevant topics in the industry, I would\nlike to investigate whether the Bitcoin paradigm is interesting for\nthe attendees. This should give the attendees (bankers and other\nfinancial professionals) a lot of inspiration for their own\nbusiness. At the same time it is a good opportunity to position\nBitcoin within the international audience, to gain unique strategic\ninsights and to network within the European professional scene.\n\nCan we have contact this week to elaborate this further? Thank you\nin advance,\n\nLook forward hearing from you,\n\nKind regards,\nDouwe Lycklama\nEPCA Conference Chaiman\n\nDouwe Lycklama | Innopay\ndouwe@innopay.com<mailto:douwe@innopay.com>\n+31 655 711 150\n\n'Imagine - Create - Innovate: Unlocking the Payments Potential'\n10th international EPCA conference\n4-6 April 2011, Amsterdam\nwww.epcaconference.com<http://www.epcaconference.com/>\n\nTriport III 7th floor\nWestelijke Randweg 43\n1118 CR SCHIPHOL AIRPORT\nThe Netherlands"]],"u":"https://mmalmi.github.io/satoshi/#email-258","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":null,"fe":"mmalmi@cc.hut.fi"},{"f":"mmalmi@cc.hut.fi","d":1297370122,"b":[["t","Hello,\n\nThanks for contacting and sorry for the late response. EPCA seems very\ninteresting for the Bitcoin project, a good opportunity for\nnetworking. I'll find somebody who can work with you on this. In the\nmeantime please ask me for any questions.\n\nBest regards,\n\nMartti Malmi\nBitcoin project developer"],["q","Hello,\n\nI am writing you on behalf of the EPCA Conference because we are\ninterested to learn more about Bitcoin. Possibly Bitcoin is an\ninteresting topic for the upcoming conference 4-6 April in Amsterdam.\n\nAt this top rated conference we deal with the key strategic\ndevelopments in the 'transaction industry' so not limited to\npayments. The event is truly 'professional for professional', so\nevery presentation is screened on quality and relevance (no sales\npitches). See also:\nwww.epcaconference.com<http://www.epcaconference.com> .\n\nSince we discuss the most relevant topics in the industry, I would\nlike to investigate whether the Bitcoin paradigm is interesting for\nthe attendees. This should give the attendees (bankers and other\nfinancial professionals) a lot of inspiration for their own\nbusiness. At the same time it is a good opportunity to position\nBitcoin within the international audience, to gain unique strategic\ninsights and to network within the European professional scene.\n\nCan we have contact this week to elaborate this further? Thank you\nin advance,\n\nLook forward hearing from you,\n\nKind regards,\nDouwe Lycklama\nEPCA Conference Chaiman\n\nDouwe Lycklama | Innopay\ndouwe@innopay.com<mailto:douwe@innopay.com>\n+31 655 711 150\n\n'Imagine - Create - Innovate: Unlocking the Payments Potential'\n10th international EPCA conference\n4-6 April 2011, Amsterdam\nwww.epcaconference.com<http://www.epcaconference.com/>\n\nTriport III 7th floor\nWestelijke Randweg 43\n1118 CR SCHIPHOL AIRPORT\nThe Netherlands"]],"u":"https://mmalmi.github.io/satoshi/#email-259","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Douwe Lycklama | Innopay <douwe@mail.innopay.com>","fe":"mmalmi@cc.hut.fi"}],"id":"x102"},{"k":"x","s":"martti-malmi","t":"Re: 0.3.20 release : shipped","u":"https://mmalmi.github.io/satoshi/#email-260","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","m":[{"f":"Satoshi Nakamoto","d":1298404159,"b":[["q","I have not sent a message to the sourceforge bitcoin-list mailing list\nbecause I don't think I have permission; Satoshi, can you give me\npermission, encrypt the mailman password with my public key and send\nit to me, or just post the announcement?"],["t","Martti should give you the Drupal admin password.\n\nAny subscriber can post to bitcoin-list.  Here's the admin password in\ncase you need it later.\n\nGavin:\n-----BEGIN PGP MESSAGE-----\nVersion: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0\n\nhQIOAxfAPINgyySWEAf9GHyuMqxkhoBe96hbHoFPIR4ORpMS/v2mpCT70UmgTt46\nGVO5MeEOFE4JUqltYUaAE2u7e7+BbyNFeNk4o0kwJIWUXbRoBHj59vx+yzmeRLd9\nYxTWxZA2zOVcYcYoDkiYAatwlQWQefzwYFcCnBSSsY1F9XLHMtLqNadhftOregoE\n5Prhjk4ScAEOAmJ2CfYvWLD6FPAe4s6nXzP656oQghMgUivYoowHAjGUSvd8f1Qb\nfkV0isGIYCpHCOSZDZpysPCm63ibEeiuylvkT7Ayj2HoonqypFdv05mtyS7Jtq6a\ns06UqjLSyICoGJVk4x5HZhusgmbqViLvb6gM+iadbQf/U9KEKA5KyF0JvjYlx97k\nBm7WpBIxKnP6Migl/Otol85EYt9rWN0lozLGw5Ko1JTZzXv3RrTsJafUYnDyAvtR\n20JExoG84LatTeFiTqVWHiWZbYG2ECJHTO6jOmITvNvq/OgCID4hQvjvNQiXghae\nqzolzmZVEwDGAybWJoSvAsXjDWbAyHt9WJztHPgVRxgTBrnhoLAX0FwKGTCr7L/t\nemVEUqgEf3WqmljD+cCXSNVloQxGmPvaSsbITIZvX/emwq4MAC+SuRmJLJp6kSmu\nUhkxZMipvYHfyBPXoonAM7oYXNIaFQryS66UlEziSUevvU8TXiZMeUyyiMirOBXC\nitKhAedpc7NQYG+/KohTS0U9QfdygBfE2o6M96tRKFdMmbQz3Gyq0BaBpp98+ve+\nVOVp90mYv9zq43G7tHnZektEjGzplHj0HzWhfbiy2dBrDGhkByYN4G6kX0JvU4ZX\n/ixmbOf5qZPqcgmz7fYDxKnkUQVumoEIfNXrUlAPcI2Ql9TnY0NIg9ZIVOGeT4lE\n80kYloQVdCdnrJ7yLWexO0W1kSs=\n=S7eV\n-----END PGP MESSAGE-----\n\nMartti:\n-----BEGIN PGP MESSAGE-----\nVersion: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0\n\nhQEMA+kEt/4bukJEAQgAlt5/Ks5pZPeusK0yefyMn7BqIVcOVHDaXbnf4dLKqq5J\n6bKyMlkyYjhm1itZabi+IaV9k+1r7Wo50qOqfZNCSmG63hX3asXWd7QxThj4KDxr\nfvuUfiduf2AyZcB4r/baw1hsdC3VGxQutU0ookuJqfvCIse77clS2WimKJ5hrh5G\nKVdGApk3TxbILknalIs3mUw81sL0nvbO/aNrHiiNj44YU3Ehf5CieEJInHeYGTsJ\nAABLZcH6B7nymA8D4nrAAnDcjcSE8+iWMOtzI2duCHKtA+LVJOsg8n/zHqK9SZNF\nw+Xud7mBi/ZvnFGwCZh7cqJ/jZhNLLTQHiLr8M+i7dKhAekFho8aarOV9V4Cp2hT\na8bQdbgwsednyjCzaq+C8xU+aYJcAV95qK6QG2hlT8xpDU2KHBHWIjDmPKlzgvKb\n8/dQo5VDvtQkdyvrd9pMJeOUxFKEVW5ph+4LzKjKEWE1kJhzAwbxQMNKkXLzZJIa\nhJMNAVHDjnYcuI8EgJT+TjH2Kx+KwHX/OEOFaDXGP7XwMOuVZTVtbXnsJ24SFa1i\nm4U=\n=0TBL\n-----END PGP MESSAGE-----"]],"u":"https://mmalmi.github.io/satoshi/#email-260","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/mmalmi-satoshi.html","to":"Gavin Andresen <gavinandresen@gmail.com>, Martti Malmi <mmalmi@cc.hut.fi>","fe":"satoshin@gmx.com","s":1}],"id":"x103"},{"k":"x","s":"mike-hearn","t":"Open sourced my Java SPV impl","u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","m":[{"f":"Mike Hearn","d":1299507180,"b":[["t","Hi Satoshi,\n\nI hope you are doing well. I finally got all the lawyers happy enough\nto release BitCoinJ under the Google name using the Apache 2 license:\n\nhttp://www.bitcoin.org/smf/index.php?topic=4236.0\n\nIt's incomplete - notably it doesn't properly handle block chain\nsplits yet - but the rest is coming. I put a lot of work into\ndocumentation and comments so hopefully it'll open up BitCoin to a new\naudience who weren't able to understand/build the current code. Over\nthe next month or two I'll be finishing off some of the bigger missing\npieces for a full client-mode implementation.\n\nI know you are busy right now but I'm hoping you can find time to\nanswer a few questions I had.\n\nAs part of doing full SPV I'm thinking of adding a getmerklebranch\nmessage to the protocol. This would return a set of {blockhash,\nbranch} pairs given tx hashes, so allowing verification of a broadcast\ntransaction before it was incorporated into a block without storing\nthe full chain. Does that approach sound good to you?\n\nAlso, I've been thinking of exploring different transaction types\nlately, eg by removing the IsStandard() checks for the testnet. It's\nclear you put a lot of thought into transactions beyond simply moving\ncoins around up front, but unfortunately none of it was in the paper\nor documented in the code. Escrow, multi-pay and so on are all\ninteresting but I was wondering if you could compile a list of ideas\nfor things we can do with the scripting language at some point.\n\nFinally, the code that allows for transaction replacement has been\ndisabled but the comment doesn't say why. Is this just to reduce the\nattack surface/complexity or is there a deeper reason? I haven't fully\nunderstood why sequence numbers are a property of the tx inputs rather\nthan the tx itself.\n\nHope you can find the time/energy to rejoin us soon! I don't know if\nyou've seen this:\n\nhttp://bitcoin.sipa.be/speed-lin.png\n\nbut it's exciting times for the network!\n\nthanks!\n/mike"]],"u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1299690900,"b":[["t","I hope you are doing well. I finally got all the lawyers happy enough\nto release BitCoinJ under the Google name using the Apache 2 license:\n\nIt's incomplete - notably it doesn't properly handle block chain\nsplits yet - but the rest is coming. I put a lot of work into\ndocumentation and comments so hopefully it'll open up BitCoin to a new\naudience who weren't able to understand/build the current code. Over\nthe next month or two I'll be finishing off some of the bigger missing\npieces for a full client-mode implementation.\n\nThat's great news!  Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too.\n\nI know you are busy right now but I'm hoping you can find time to\nanswer a few questions I had.\n\nI'm happy to answer any questions.\n\nAs part of doing full SPV I'm thinking of adding a getmerklebranch\nmessage to the protocol. This would return a set of {blockhash,\nbranch} pairs\n\nThat's a CMerkleTx\n\ngiven tx hashes, so allowing verification of a broadcast\ntransaction before it was incorporated into a block without storing\nthe full chain. Does that approach sound good to you?\n\nI don't understand.  A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work.  Linking back to an as-yet unsolved block proves nothing.\n\nNetwork nodes are able to verify 0-conf txes because they have the complete tx index, so they can:\n1) verify signatures against dependencies.\n2) say that they haven't seen another spend yet, because they know about every tx in existence.\n\nAre you talking about CMerkleTxes for the tx's dependencies?  That would get part 1), but not part 2).\n\nIf you don't know about all txes in existence, I don't know how to do 2).  You could only rely on trusting other nodes for that.  That trust can be distributed over multiple nodes.  Nodes only relay transactions they accept as valid.  If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.\n\nAlso, I've been thinking of exploring different transaction types\nlately, eg by removing the IsStandard() checks for the testnet.\n\nVery good idea.  That should definitely be allowed on -testnet.\n\nIt's\nclear you put a lot of thought into transactions beyond simply moving\ncoins around up front, but unfortunately none of it was in the paper\nor documented in the code. Escrow, multi-pay and so on are all\ninteresting but I was wondering if you could compile a list of ideas\nfor things we can do with the scripting language at some point.\n\nFinally, the code that allows for transaction replacement has been\ndisabled but the comment doesn't say why. Is this just to reduce the\nattack surface/complexity or is there a deeper reason?\n\nJust to reduce surface area.  It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime.  It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.\n\nSee these threads:\nhttp://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119\nhttp://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729\n\nI haven't fully\nunderstood why sequence numbers are a property of the tx inputs rather\nthan the tx itself.\n\nIt's for contracts.  An unrecorded open transaction can keep being replaced until nLockTime.  It may contain payments by multiple parties.  Each input owner signs their input.  For a new version to be written, each must sign a higher sequence number (see IsNewerThan).  By signing, an input owner says \"I agree to put my money in, if everyone puts their money in and the outputs are this.\"  There are other options in SignatureHash such as SIGHASH_SINGLE which means \"I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.\".  If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.\n\nThe parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature.  The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.\n\nOne use of nLockTime is high frequency trades between a set of parties.  They can keep updating a tx by unanimous agreement.  The party giving money would be the first to sign the next version.  If one party stops agreeing to changes, then the last state will be recorded at nLockTime.  If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out.  Intermediate transactions do not need to be broadcast.  Only the final outcome gets recorded by the network.  Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw."]],"u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1299692340,"b":[["t","If you don't know about all txes in existence, I don't know how to do 2).  You could only rely on trusting other nodes for that.  That trust can be distributed over multiple nodes.  Nodes only relay transactions they accept as valid.  If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.\n\nGood point. I was talking about verifying the inputs yes, but it is indeed pointless unless you hear about all open transactions as well. So being able to fetch a CMerkleTx is not important.\n\n \n\nJust to reduce surface area.  It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime.  It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.\n\nSee these threads:\nhttp://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119\nhttp://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729\n\nI see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.\n\n \n\nIt's for contracts.\n\nAh ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think.\n\nI have more questions!\n\nThere's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?\n\nThere was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:\n\n   http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171\n\nBut I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?\n\nThanks!"]],"u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1299699540,"b":[["t","See these threads:\n    http://www.bitcoin.org/smf/index.php?topic=1786.msg22119#msg22119\n    http://www.bitcoin.org/smf/index.php?topic=2181.msg28729#msg28729\n\nI see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.\n\nThe network won't forget, and the owner's client will keep rebroadcasting it.  The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished.\n\nPriority includes age, so as a transaction waits it ages and will eventually have enough priority.\n\nSee one of the links above where I contemplate sending an honest double-spend to increase the fee.  It's a lot of work but could be done.  I don't think it's worth it right now.\n\nThe current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough.  Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them.\n\nUsers still worried about processing speed uncertainty should think of it as encouragement to include a fee.\n\nThere's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?\n\nI was trying to implement an eBay style marketplace built in to the client.  Publish/subscribe would be used for broadcasting product offers and ratings/reviews.  Your reviews would be weighted by the blocks you've generated.  I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally.  The publish/subscribe \"meet in the middle\" mechanism was an interesting concept, but nothing remains that uses it.\n\nIt was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started.\n\nThere was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:\n\n   http://www.bitcoin.org/smf/index.php?topic=3414.msg48171#msg48171\n\nBut I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?\n\nNo, other chains do not follow Bitcoin's rules.  They are completely independent chains.  They share nothing except the miners.  The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it.  They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once.\n\nProcedure to hash a BitDNS block:\n - hash the BitDNS block\n - construct a Bitcoin block\n - insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block\n - hash the Bitcoin block\n\nThe BitDNS block is valid if that hash is below BitDNS's target.\n\nThe BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash:\n - the Bitcoin block header\n - the merkle branch to tx 0\n - tx 0  (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes)\n\nNote that it doesn't matter if the fodder \"Bitcoin block\" was actually valid in the Bitcoin chain, though it could have been.  To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce).\n\nTo further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS.  This is the merkle tree that is conceptually at the top."]],"u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1299700320,"b":[["t","Thanks again.\n\nHal speculated that you intended to stash the new merkle root in the tx0 scriptSig. Good to know at least he had the right idea :-)"]],"u":"https://plan99.net/~mike/satoshi-emails/thread4.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread4.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"}],"id":"x104"},{"k":"x","s":"mike-hearn","t":"Holding coins in an unspendable state for a rolling time window","u":"https://plan99.net/~mike/satoshi-emails/thread5.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread5.html","m":[{"f":"Mike Hearn","d":1303168440,"b":[["t","Hello Satoshi,\n\nI hope this mail finds you well. Recently I've been thinking about how\nBitCoin can help handle internet abuse and would appreciate your\nthoughts.\n\nMy \"day job\" is on the Google abuse team. We make extensive use of\nphone verification to control outbound spam from our network. Facebook\nand Craigslist do the same. Phone verification works well because\nphone numbers are something most people have access to at least one or\ntwo of, but rarely more. Yet it has significant downsides - it's\nexpensive (for us), flaky, some people don't like the privacy\nimplications, and some spam is profitable enough that buying lots of\nSIM cards is worth it.\n\nIt would be ideal if BitCoins could be put up as collateral against an\naccount. The amount put up would help determine the limits the system\nplaced on your behavior (eg how much mail you can send), in an\nanonymous and private way. But how to implement this?\n\nBurning coins forever is easy, just set the only output to be <pubkey>\nOP_FALSE. Now you can sign some server-provided challenge with that\nkey and prove you did indeed burn those coins. A key would only be\nusable with one account so spammers cannot simply put up a huge\ncollateral and then resell signatures generated with that key. If the\naccount was found to be abused it'd be terminated like today, and the\ncoins would be \"gone\".\n\nBut people do come and go from these big networks and the thought of\nlosing the coins if you quit Google to run your own mail is\nunappealing. It would be ideal if coins could be locked up for a\nperiod of time such that they cannot be spent until time X, where X\ncan be constantly pushed into the future if the owner desires it but\notherwise the coins eventually become spendable again. To verify your\nGoogle account, you would take some amount of coins (say 10) and set\nit up so you cannot spend them for 6 months.\n\nThe script language has no concept of time. OP_BLOCKNUMBER was ruled\nout because re-orgs could potentially invalidate entire chains of\ntransactions. But is an OP_DAY feasible? I'm thinking of an opcode\nthat returns the timestamp from the block header, but rounded to the\nnearest day to handle the natural clock drift seen in the block chain.\nIf it could work then a TX that ties up coins until past a certain day\nis easy to construct. Updating it so the deadline is constantly moving\nis harder. A simple brute force solution is to require the user to put\nup 2x the coins such that at the point the first tx is about to expire\nand become spendable again, the second tx is created. In this way you\nalways have at least one tx of sufficiently distant deadline to act as\ncollateral. But this is inelegant. A better way would be to introduce\na new rule allowing a tx to connect to such an output before the\ndeadline has passed, as long as the output of that tx is once again a\ndeadlined output of the same form. However this is less general than\nthe scripting language so is also somewhat inelegant.\n\nWhat do you think?"]],"u":"https://plan99.net/~mike/satoshi-emails/thread5.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread5.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1303299540,"b":[["t","If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain.  The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.\n\nSince Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?\n\nTo answer your question though, yes it can be done without using trust:\n\nTx 1 from User pays to a script that requires the signature of both Google and User to spend.\n\nTx 2 (the contract) spends Tx 1 and pays it to User.  nLockTime is the time to release the money.\n\nSteps:\n1) Google gives User a pubkey to use in creating Tx 1.\n2) User privately creates Tx 1, does not broadcast it yet.\n3) User gives the hash of Tx 1 to Google.\n4) Google signs its part of Tx 2, with nLockTime set, and gives it to User.\n5) User broadcasts Tx 1.\n6) User signs his half of Tx 2 and broadcasts it.\n\nWith these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to.\n\nThis is the general pattern for safely signing contracts.  Tx 2 is prepared first so the parties know what they're paying into.  Tx 1 is broadcast to lock up the money and assign it to Tx 2.  In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature.\n\nBy mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately.\n\n[Quoted text hidden]"]],"u":"https://plan99.net/~mike/satoshi-emails/thread5.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread5.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"},{"f":"Mike Hearn","d":1303307700,"b":[["t","Thanks, that's helpful. I'm understanding contracts better now.\n\nSo the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight.\n\nSince Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?\n\nGoogle and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification ... a few people don't want to give us their phone number.\n\nFor this case it'd probably be OK because trust around data privacy is different to trust around obeying contracts. I'm sure nobody would doubt that Google will pay them back - I bet we'd have an even better credit rating than the US Government in that sense :-) But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I've seen much sillier conspiracy theories gain traction.\n\nBesides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn't understand yet so it's a good chance to learn more about BitCoin.\n\n \n\nTo answer your question though, yes it can be done without using trust\n\nIf I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?\n\nI'm thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren't widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining.\n\nDid you have any list of tasks for re-activation, some kind of audit or finishing off some code?\n\nI had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I'm peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there's little guidance on how to do it. And frankly, I don't think I'm smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame.\n\nAnother is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a \"Tragedy of the commons\" to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it's too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?\n\nAs always thanks for your insights."]],"u":"https://plan99.net/~mike/satoshi-emails/thread5.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread5.html","to":"Satoshi Nakamoto <satoshin@gmx.com>","fe":"mike@plan99.net","dp":"local"},{"f":"Satoshi Nakamoto","d":1303573200,"b":[["t","I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?\n\nI've moved on to other things.  It's in good hands with Gavin and everyone.\n\nI do hope your BitcoinJ continues to be developed into an alternative client.  It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything.  It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain."]],"u":"https://plan99.net/~mike/satoshi-emails/thread5.html","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/thread5.html","to":"Mike Hearn <mike@plan99.net>","fe":"satoshin@gmx.com","s":1,"dp":"local"}],"id":"x105"},{"k":"x","s":"single-emails","t":"Email to Gavin Andresen","u":"https://riski.wiki/wiki/User:Gavinandresen/Blog/2022-04-26_Eleven_years_ago_today%E2%80%A6","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-gavin-andresen.txt","m":[{"f":"Satoshi Nakamoto","d":1303806540,"b":[["t","I wish you wouldn’t keep talking about me as a mysterious shadowy\nfigure, the press just turns that into a pirate currency angle. Maybe\ninstead make it about the open source project and give more credit to\nyour dev contributors; it helps motivate them.\n\nI’ve moved on to other things and will probably be unavailable. Here’s\nthe CAlert key and broadcast code in case you need it. You should\nprobably give it to at least one or two other people. There are a few\nlong time users who are always around all the time."]],"u":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-gavin-andresen.txt","su":"https://github.com/lugaxker/nakamoto-archive/blob/8405b13482ae1a1bc55d6fe5bb3a5f2f46a58ffc/src/email-to-gavin-andresen.txt","to":"Gavin Andresen","fe":"satoshin@gmx.com","s":1,"sj":"alert key","od":"26 Apr 2011, 10:29; Gavin's reply quotes it as Tue, Apr 26, 2011 at 4:29 AM (US Eastern)"},{"f":"Gavin Andresen","d":1303806600,"dp":"day","sj":"Re: alert key","to":"satoshin@gmx.com","fe":"","b":[["t","On Tue, Apr 26, 2011 at 4:29 AM, Satoshi Nakamoto satoshin@gmx.com wrote:"],["q","I wish you wouldn’t keep talking about me as a mysterious shadowy figure,\nthe press just turns that into a pirate currency angle. Maybe instead make\nit about the open source project and give more credit to your dev\ncontributors; it helps motivate them."],["t","You must’ve read the Forbes article… yeah, I’m not happy with the\n‘wacky pirate money’ tone, either.\n\nMore credit for the rest of the contributors is a very good idea.\n\nRE: forwarding the key/code: fricking fracking… now I’ve gotta\nfigure out a couple of people who I can trust to keep them safe…\n\nOn a completely different subject: I did something that I hope turns\nout to be smart, but might be stupid.\n\nI was contacted by http://www.iqt.org/ – they’re a US-govt-funded\n‘strategic investment’ company, and part of what they do is holding an\nannual conference on emerging technologies for US intelligence\nagencies. This year the theme is “Mobility of Money”.\n\nThey asked if I’d be willing to talk about Bitcoin, and I committed to\ngiving a 50-minute presentation and participating in a panel\ndiscussion.\n\nI hope that by talking directly to “them” and, more importantly,\nlistening to their questions/concerns, they will think of Bitcoin the\nway I do– as a just-plain-better, more efficient,\nless-subject-to-political-whims money. Not as an all-powerful\nblack-market tool that will be used by anarchists to overthrow The\nSystem.\n\nIt might be really stupid if it just raises Bitcoin’s visibility on\ntheir radar, but I think it is way too late for that; Bitcoin is\nalready on their radar.\n\nI plan on posting about this on the forums soon, because “Gavin\nsecretly visits the CIA” would spin all sorts of conspiracy theories.\n“Gavin openly visits the CIA” will create enough conspiracy theories\nas it is."]],"u":"https://riski.wiki/wiki/User:Gavinandresen/Blog/2022-04-26_Eleven_years_ago_today%E2%80%A6","su":"https://riski.wiki/wiki/User:Gavinandresen/Blog/2022-04-26_Eleven_years_ago_today%E2%80%A6"}],"id":"x106"},{"k":"x","s":"nicholas-bohm","t":"[bitcoin-list] Problems","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1232924100,"b":[["t","Satoshi Nakamoto wrote:"],["q","From: Nicholas Bohm 2009-01-25 10:17\nI have had a couple of problems running bitcoin: is this an appropriate\nlist for reporting them (with about 70kb of attachments)?\n\n\nWhat's the problem you're having?\n\nIf you send me your debug.log file directly (best not to send attachments\nto the list), I can take a look at what's happening."],["t","Thanks (I realise lists don't usually like attachments).\n\nBitcoin is mostly running fine, and has made good progress (as far as I\ncan tell) - see screenshot of progress.\n\nMy first problem was finding it reported as a virus by NOD32 (from Eset)\n- see screenshot of report. I have reported this to Eset as an error,\nand they are investigating. If other AV vendors' products do likewise,\nthis might be a barrrier to takeup.\n\nMy second problem occurred yesterday, and consisted of a number of\ncrashes by Bitcoin (four or five). The program simply closed, with the\nusual MS error report. I attach the file generated by the error report.\n The Event viewer describes the incident as \"Faulting application\nbitcoin.exe, version 0.0.0.0, faulting module bitcoin.exe, version\n0.0.0.0, fault address 0x000bd598.\"\n\nand its data are:\n\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 64 35 t 000bd5\n0050: 39 38 0d 0a           98..\n\n(This is one example.)\n\nThe problem has not recurred, and I am not aware of any significant\nsystem changes before or after the crashes. (I get regular AV updates,\nbut NOD32 still detects bitcoin as a virus both before and after the\ncrashes.)\n\nMy system details are as follows:\n\n\n\n\n\n\n\n Microsoft Windows XP\n Professional\n Version 2002\n\n Service Pack 3\n\n\n Hewlett-Packard\n HP Compaq dc5750 Microtower\n\n AMD Athlon(tm) 64 X2 Dual\n Core Processor 4200+\n\n 2.19 GHz, 1.87 GB of RAM\n Physical Address Extension\n\nI attach the debug.log.\n\nPlease let me know if there is more information that would be helpful.\n\nRegards,\n\nNicholas Bohm"],["f","Attachments (not included in the exhibit): Progress.png, AV report.png, 7ab6_appcompat.txt, debug.log"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.2%203%2020090125-Re_%5Bbitcoin-list%5D%20Problems-63216.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.2%203%2020090125-Re_%5Bbitcoin-list%5D%20Problems-63216.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"25/01/2009, 22:55 (UK time)"},{"f":"Nicholas Bohm","d":1232966040,"b":[["t","Time:             04:51:09\nUser:             N/A\nComputer:         [computer name removed]\nDescription:\nFaulting application bitcoin.exe, version 0.0.0.0, faulting module\nbitcoin.exe, version 0.0.0.0, fault address 0x000bd598.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 64 35 t 000bd5\n0050: 39 38 0d 0a            98..\n\nWould it be useful to send an updated copy of debug.log?\n\nI have restarted Bitcoin, and it is running normally.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.3%204%2020090126-Re_%5Bbitcoin-list%5D%20Problems-68653.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.3%204%2020090126-Re_%5Bbitcoin-list%5D%20Problems-68653.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"26/01/2009, 10:34 (UK time)"},{"f":"Satoshi Nakamoto","d":1232983080,"b":[["t","Time:         04:51:09\nUser:         N/A\nComputer: [computer name removed]\nDescription:\nFaulting application bitcoin.exe, version 0.0.0.0, faulting module\nbitcoin.exe, version 0.0.0.0, fault address 0x000bd598.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 64 35 t 000bd5\n0050: 39 38 0d 0a         98..\n\n\n\n\n\n\n\nWould it be useful to send an updated copy of debug.log?\n\nI have restarted Bitcoin, and it is running normally.\n\nRegards,\n\nNicholas\n--"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.4%205%20s20090126-Re_%5Bbitcoin-list%5D%20Problems-70731.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.4%205%20s20090126-Re_%5Bbitcoin-list%5D%20Problems-70731.pdf","sj":"Re: [bitcoin-list] Problems","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"26/01/2009, 15:18 (UK time)"},{"f":"Nicholas Bohm","d":1232987460,"b":[["q","Time:             04:51:09\nUser:             N/A\nComputer:         [computer name removed]\nDescription:\nFaulting application bitcoin.exe, version 0.0.0.0, faulting module\nbitcoin.exe, version 0.0.0.0, fault address 0x000bd598.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 64 35 t 000bd5\n0050: 39 38 0d 0a            98..\n\nWould it be useful to send an updated copy of debug.log?\n\nI have restarted Bitcoin, and it is running normally."],["t","Regards,\n\nNicholas"],["f","Attachments (not included in the exhibit): debug.log"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.5%206%2020090126-Re_%5Bbitcoin-list%5D%20Problems-73902.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.5%206%2020090126-Re_%5Bbitcoin-list%5D%20Problems-73902.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"26/01/2009, 16:31 (UK time)"},{"f":"Nicholas Bohm","d":1233010260,"b":[["t","Time:             21:16:01\nUser:             N/A\nComputer:         [computer name removed]\nDescription:\nFaulting application bitcoin.exe, version 0.0.0.0, faulting module\nbitcoin.exe, version 0.0.0.0, fault address 0x000bd598.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 64 35 t 000bd5\n0050: 39 38 0d 0a            98..\n\nIs it useful for me to continue sending these as they occur?\n\nRegards,\n\nNicholas"],["f","Attachments (not included in the exhibit): debug.zip"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.6%207%2020090126-Re_%5Bbitcoin-list%5D%20Problems-78182.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.6%207%2020090126-Re_%5Bbitcoin-list%5D%20Problems-78182.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"26/01/2009, 22:51 (UK time)"},{"f":"Nicholas Bohm","d":1233061380,"b":[["t","Two further crashes yesterday at 21:16 and 23:59 (GMT). They seem to\nfollow exactly the same pattern, and I don't know if there is likely to\nbe anything informative in the log, but I attach it in case.\n\nRegards,\n\nNicholas"],["f","Attachments (not included in the exhibit): debug.rar"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.7%208%2020090127-Re_%5Bbitcoin-list%5D%20Problems-87111.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.7%208%2020090127-Re_%5Bbitcoin-list%5D%20Problems-87111.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"27/01/2009, 13:03 (UK time)"},{"f":"Nicholas Bohm","d":1233241740,"b":[["t","I have had no further problems since I ceased running a daily late\nevening scheduled operation consisting of a wipe of various folders\ncontaining temporary files using Eraser.\n\nWhether this operation accounted for the crashes I don't know, as Eraser\nhas never had that effect before, and typically ignores any file it\nfinds to be in use.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.8%209%2020090129-Re_%5Bbitcoin-list%5D%20Problems-80862.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/1.8%209%2020090129-Re_%5Bbitcoin-list%5D%20Problems-80862.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"29/01/2009, 15:09 (UK time)"},{"f":"Satoshi Nakamoto","d":1233253740,"b":[["t","Thanks for the update. There are many programs named Eraser, do\nyou know where I could find it or the name of the company that\nmakes it or a keyword to search on?\n\nSatoshi\n\n\n I have had no further problems since I ceased running a daily late\n evening scheduled operation consisting of a wipe of various folders\n containing temporary files using Eraser.\n\n Whether this operation accounted for the crashes I don't know, as Eraser\n has never had that effect before, and typically ignores any file it\n finds to be in use.\n\n Regards,\n\n Nicholas\n --"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/10%20s20090129-Re_%5Bbitcoin-list%5D%20Problems-82226.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/10%20s20090129-Re_%5Bbitcoin-list%5D%20Problems-82226.pdf","sj":"Re: [bitcoin-list] Problems","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"29/01/2009, 18:29 (UK time)"},{"f":"Nicholas Bohm","d":1233255900,"b":[["t","Satoshi Nakamoto wrote:"],["q","Thanks for the update. There are many programs named Eraser, do\nyou know where I could find it or the name of the company that\nmakes it or a keyword to search on?"],["t","Sorry not to be more specific: it's free software from www.heidi.ie/eraser/\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/11%2020090129-Re_%5Bbitcoin-list%5D%20Problems-84459.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/11%2020090129-Re_%5Bbitcoin-list%5D%20Problems-84459.pdf","sj":"Re: [bitcoin-list] Problems","to":"satoshi@vistomail.com","fe":"","od":"29/01/2009, 19:05 (UK time)"}],"id":"x107"},{"k":"x","s":"nicholas-bohm","t":"Bitcoin Problems","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1233330600,"b":[["t","Bitcoin continues to run without failures since I stopped scheduled\nEraser operations.\n\nIf you can tell me which temporary folders Bitcoin uses, I could try and\nreplicate the fault by trying one-off operations.\n\n(It would also be useful to know which files or folders I need to back\nup in order to preserve my accumulated hoard of bitcoins.)\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/13%2020090130-Re_Bitcoin%20Problems-85751.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/13%2020090130-Re_Bitcoin%20Problems-85751.pdf","sj":"Re: Bitcoin Problems","to":"satoshi@vistomail.com","fe":"","od":"30/01/2009, 15:50 (UK time)"},{"f":"Satoshi Nakamoto","d":1233339600,"b":[["t","That would be great.\n\nThe directory is \"%appdata%\\Bitcoin\"\nIt has spaces in it so you need the quotes\ncd \"%appdata%\\bitcoin\"\n\nOn XP it would typically be:\nC:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\n\nBackup that whole directory. All data files are in that\ndirectory. There are no temporary files.\n\nIt looks to me like other than unused space, Eraser only erases a\nfew specific directories that it knows. Whatever \"Windows\nTemporary Files\" is and internet cookies. It would be strange for\nit to scan the disk guessing at files to delete.\n\nI think I know what happened. It probably fills up the disk with\na giant random data file to overwrite all the deleted space, and\nBitcoin ran out of disk space.\n\nDisk full checking is coming in the next release. It's already in\nthe bitcoin-0.1.4-debug.rar I sent you. You should definitely\nswitch to that. If you run Eraser and Bitcoin gives you a disk\nfull warning dialog, that would confirm what happened.\n\nCertainly backup the %appdata%\\Bitcoin directory before running\nEraser again.\n\nSatoshi\n\n\n\n Bitcoin continues to run without failures since I stopped scheduled\n Eraser operations.\n\n If you can tell me which temporary folders Bitcoin uses, I could try and\n replicate the fault by trying one-off operations.\n\n (It would also be useful to know which files or folders I need to back\n up in order to preserve my accumulated hoard of bitcoins.)\n\n\n\n\n\n\nRegards,\n\nNicholas\n--"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/14%20s20090130-Re_Bitcoin%20Problems-93522.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/14%20s20090130-Re_Bitcoin%20Problems-93522.pdf","sj":"Re: Bitcoin Problems","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"30/01/2009, 18:20 (UK time)"},{"f":"Nicholas Bohm","d":1233343020,"b":[["t","Satoshi Nakamoto wrote:"],["q","That would be great.\n\nThe directory is \"%appdata%\\Bitcoin\"\nIt has spaces in it so you need the quotes\ncd \"%appdata%\\bitcoin\"\n\nOn XP it would typically be:\nC:\\Documents and Settings\\[username]\\Application Data\\Bitcoin\n\nBackup that whole directory. All data files are in that\ndirectory. There are no temporary files.\n\nIt looks to me like other than unused space, Eraser only erases a\nfew specific directories that it knows. Whatever \"Windows\nTemporary Files\" is and internet cookies. It would be strange for\nit to scan the disk guessing at files to delete."],["t","I have scheduled Eraser to clear a list of specified directories (aimed\nat cookies, history, etc), but the only one under Application Data is\nC:\\Documents and Settings\\NB\\Application Data\\#ISW.FS#\\Normal\\, which is\nclearly nothing to do with Bitcoin.\n\n\n I think I know what happened. It probably fills up the disk with\n a giant random data file to overwrite all the deleted space, and\n Bitcoin ran out of disk space.\n\n Disk full checking is coming in the next release. It's already in\n the bitcoin-0.1.4-debug.rar I sent you. You should definitely\n switch to that. If you run Eraser and Bitcoin gives you a disk\n full warning dialog, that would confirm what happened.\n\n\nUnfortunately this hasn't reached me (and I can't find it in the\nquarantined spam either) - may I trouble you to send it again? I'll\nthen switch and run successive operations on the various directories to\nsee if I can find which one or more causes the problem.\n\n\n Certainly backup the %appdata%\\Bitcoin directory before running\n Eraser again.\n\n\nMost helpful, thank you.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/15%2020090130-Re_Bitcoin%20Problems-96667.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/15%2020090130-Re_Bitcoin%20Problems-96667.pdf","sj":"Re: Bitcoin Problems","to":"satoshi@vistomail.com","fe":"","od":"30/01/2009, 19:17 (UK time)"},{"f":"Satoshi Nakamoto","d":1233345960,"b":[["q","Unfortunately this hasn't reached me (and I can't find it in the\nquarantined spam either) - may I trouble you to send it again? I'll\nthen switch and run successive operations on the various directories to\nsee if I can find which one or more causes the problem."],["t","I sent it from satoshin@gmx.com because it's a lot easier to send\nattachments from there. I'm resending it from there again.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/16%20s20090130-Re_Bitcoin%20Problems-99388.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/16%20s20090130-Re_Bitcoin%20Problems-99388.pdf","sj":"Re: Bitcoin Problems","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"30/01/2009, 20:06 (UK time)"}],"id":"x108"},{"k":"x","s":"nicholas-bohm","t":"Resent","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Satoshi Nakamoto","d":1233346860,"b":[["t","I resent the 0.1.4 file in the previous e-mail. It also contained a bugfix for a bug that was dormant\nbut I thought by process of elimination might have been what you had, but after you told me about\nEraser I think it's more likely to have been Eraser/disk space related.\n\nI guess we are simultaneously trying to debug my e-mail.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/17%20s20090130-Resent-101188.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/17%20s20090130-Resent-101188.pdf","sj":"Resent","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"30/01/2009, 20:21 (UK time)"},{"f":"Nicholas Bohm","d":1233352440,"b":[["t","Satoshi Nakamoto wrote:"],["q","I resent the 0.1.4 file in the previous e-mail. It also contained a\nbugfix for a bug that was dormant but I thought by process of\nelimination might have been what you had, but after you told me about\nEraser I think it's more likely to have been Eraser/disk space related.\n\nI guess we are simultaneously trying to debug my e-mail."],["t","We seem to be, as I can only find two messages from you, the one above\nand the one from vistomail, and neither has any attachments. (I have\nalso again checked the spam quarantine.)\n\nSo something odd is happening.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/18%2020090130-Re_Resent-102984.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/18%2020090130-Re_Resent-102984.pdf","sj":"Re: Resent","to":"satoshin@gmx.com","fe":"","od":"30/01/2009, 21:54 (UK time)"},{"f":"Satoshi Nakamoto","d":1233355860,"b":[["t","Nicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nI resent the 0.1.4 file in the previous e-mail. It also contained a\nbugfix for a bug that was dormant but I thought by process of\nelimination might have been what you had, but after you told me about\nEraser I think it's more likely to have been Eraser/disk space related.\n\nI guess we are simultaneously trying to debug my e-mail.\n\n\nWe seem to be, as I can only find two messages from you, the one above\nand the one from vistomail, and neither has any attachments. (I have\nalso again checked the spam quarantine.)\n\nSo something odd is happening.\n\nRegards,\n\nNicholas"],["t","Clearly one side or the other is stopping the ones with attachments. I sent you the same file\nattachment from vistomail about 15 minutes after I sent it from gmx (about 2 hours ago). I've\nsuccessfully sent similar attachments to other people from vistomail many times before.\n\nAfter this e-mail, which I'm sending without an attachment to make sure it gets through, I'll try\nagain with a different variation:\n1) stripped debug info, reduces rar filesize from 7.8MB to 1.6MB.\n2) renamed to bc014.rar, in case long filename or periods are the problem.\n3) no gdb.exe.\n\nAfter that I'll send bc014a.rar, with bitcoin.exe renamed to bitcoin.dat in case it doesn't like exe\nfiles.\n\nAnd then I'll send bc014.rar from vistomail.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/19%20s20090130-Re_Resent-104523.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/19%20s20090130-Re_Resent-104523.pdf","sj":"Re: Resent","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"30/01/2009, 22:51 (UK time)"}],"id":"x109"},{"k":"x","s":"nicholas-bohm","t":"bc014.rar attached","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Satoshi Nakamoto","d":1233356640,"b":[["t","I sent bc014.rar and bc014a.rar through gmx, now here's bc014.rar\nattached from vistomail."]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/20%20s20090130-bc014.rar%20attached-107499.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/20%20s20090130-bc014.rar%20attached-107499.pdf","sj":"bc014.rar attached","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"30/01/2009, 23:04 (UK time)"}],"id":"x110"},{"k":"x","s":"nicholas-bohm","t":"Attachment troubles - bc014.rar","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Satoshi Nakamoto","d":1233357180,"b":[["t","I sent bc014.rar and bc014a.rar through gmx and bc014.rar through vistomail. Did you get any of\nthem?\n\nIn case all those failed (let me know), I also uploaded it to:\nhttp://www.upload.ae/file/14497/bc014-rar.html\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/21%20s20090130-Re_Attachment%20troubles%20-%20bc014.rar-108980.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/21%20s20090130-Re_Attachment%20troubles%20-%20bc014.rar-108980.pdf","sj":"Re: Attachment troubles - bc014.rar","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"30/01/2009, 23:13 (UK time)"}],"id":"x111"},{"k":"x","s":"nicholas-bohm","t":"Reporting","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1233404580,"b":[["t","1 Attachments problem\n\nAlthough I successfully downloaded and ran bc014, I thought I had better\nreport on the attachments.\n\nI received the following messages from you yesterday 30th January, and\nonly those messages, none of them with any attachments:\n\nAt 22.51 GMT\n\nNicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nI resent the 0.1.4 file in the previous e-mail. It also contained a\nbugfix for a bug that was dormant but I thought by process of\nelimination might have been what you had, but after you told me about\nEraser I think it's more likely to have been Eraser/disk space related.\n\nI guess we are simultaneously trying to debug my e-mail.\n\n\nWe seem to be, as I can only find two messages from you, the one above\nand the one from vistomail, and neither has any attachments. (I have\nalso again checked the spam quarantine.)\n\nSo something odd is happening.\n\nRegards,\n\nNicholas"],["t","Clearly one side or the other is stopping the ones with attachments. I\nsent you the same file attachment from vistomail about 15 minutes after\nI sent it from gmx (about 2 hours ago). I've successfully sent similar\nattachments to other people from vistomail many times before.\n\nAfter this e-mail, which I'm sending without an attachment to make sure\nit gets through, I'll try again with a different variation:\n1) stripped debug info, reduces rar filesize from 7.8MB to 1.6MB.\n2) renamed to bc014.rar, in case long filename or periods are the problem.\n3) no gdb.exe.\n\nAfter that I'll send bc014a.rar, with bitcoin.exe renamed to bitcoin.dat\nin case it doesn't like exe files.\n\nAnd then I'll send bc014.rar from vistomail.\n\nSatoshi\n\nAt 23.04\n\n\n\n\n\n\n\nI sent bc014.rar and bc014a.rar through gmx, now here's bc014.rar\nattached from vistomail.\n\nAt 23.13\n\nI sent bc014.rar and bc014a.rar through gmx and bc014.rar through\nvistomail. Did you get any of them?\n\nIn case all those failed (let me know), I also uploaded it to:\nhttp://www.upload.ae/file/14497/bc014-rar.html\n\nSatoshi\n\n.........................................\n\nThis is very odd. I am successfully receiving email from others with\nattachments, and neither size nor filename seem to matter. NOD32 is no\nlonger detecting Bitcoin as a virus (I assume as a result of an update\nto NOD32, of which I get one or two most days). Your mail is not in my\nanti-spam quarantine (though I have now whitelisted both addresses\nanyway). I'm baffled.\n\n2 Bitcoin 014\n\nThe download was successful, and I simply replaced the old executable\nwith the new. It runs without any problems.\n\n3 Eraser\n\nI ran all my normal Eraser tasks, and provoked no problem with Bitcoin.\n\nEraser might fill the disk in an operation to wipe free space, but this\nis very slow with two 150GB drives, and I don't do it routinely. The\nwiping operations take less than 2 minutes, and I doubt if they use up\nall the disk space.\n\nThe only recent change to my system has been to rectify an apparent\nfailure of the swapfile, whioch did not seem to be recognised by the\nsystem, but is now. With 2GB of RAM, though, would that have been a\nproblem?\n\n..........................................\n\nIt seems we have to wait for further errors to accumulate!\n\nThanks for all your responses meanwhile. Do let me know if there are\nfurther tests you would like me to try.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/22%2020090131-Reporting-110689.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/22%2020090131-Reporting-110689.pdf","sj":"Reporting","to":"satoshi@vistomail.com","fe":"","od":"31/01/2009, 12:23 (UK time)"}],"id":"x112"},{"k":"x","s":"nicholas-bohm","t":"Another crash","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1233417840,"b":[["t","Time:             15:56:28\nUser:             N/A\nComputer:         [computer name removed]\nDescription:\nFaulting application bitcoin.exe, version 0.0.0.0, faulting module\nbitcoin.exe, version 0.0.0.0, fault address 0x000be368.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 41 70 70 6c 69 63 61 74 Applicat\n0008: 69 6f 6e 20 46 61 69 6c ion Fail\n0010: 75 72 65 20 20 62 69 74 ure bit\n0018: 63 6f 69 6e 2e 65 78 65 coin.exe\n0020: 20 30 2e 30 2e 30 2e 30 0.0.0.0\n0028: 20 69 6e 20 62 69 74 63 in bitc\n0030: 6f 69 6e 2e 65 78 65 20 oin.exe\n0038: 30 2e 30 2e 30 2e 30 20 0.0.0.0\n0040: 61 74 20 6f 66 66 73 65 at offse\n0048: 74 20 30 30 30 62 65 33 t 000be3\n0050: 36 38 0d 0a            68..\n\nRegards,\n\nNicholas"],["f","Attachments (not included in the exhibit): debug.rar"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/23%2020090131-Another%20crash-120326.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/23%2020090131-Another%20crash-120326.pdf","sj":"Another crash","to":"satoshi@vistomail.com","fe":"","od":"31/01/2009, 16:04 (UK time)"},{"f":"Satoshi Nakamoto","d":1233432240,"b":[["t","- Is there anything in db.log?\n- What operating system are you using?\n- When it crashes, does it put up any other message boxes that say anything else?\n- What does it do when it crashes? Is the UI hung or is it still usable?\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/24%20s20090131-Re_Another%20crash-122907.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/24%20s20090131-Re_Another%20crash-122907.pdf","sj":"RE: Another crash","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"31/01/2009, 20:04 (UK time)"},{"f":"Satoshi Nakamoto","d":1233441360,"b":[["t","I guess I'd better send this from here also in case there's\nmore e-mail problems.\n\nGood news! I pinpointed the bug. The bug could occur if your\ncomputer had trouble doing a DNS lookup.\n\nThe fix is at:\nhttp://www.upload.ae/file/14540/bc015-rar.html\n\nThanks for all your help and patience with this.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/26%20s20090131-Re_Another%20crash-126195.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/26%20s20090131-Re_Another%20crash-126195.pdf","sj":"Re: Another crash","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"31/01/2009, 22:36 (UK time)"},{"f":"Nicholas Bohm","d":1233489120,"b":[["t","Time:           10:30:12\nUser:           N/A\nComputer:       [computer name removed]\nDescription:\nFault bucket 1123899417.\n\nFor more information, see Help and Support Center at\nhttp://go.microsoft.com/fwlink/events.asp.\nData:\n0000: 42 75 63 6b 65 74 3a 20 Bucket:\n0008: 31 31 32 33 38 39 39 34 11238994\n0010: 31 37 0d 0a            17..\n\n\n - What does it do when it crashes? Is the UI hung or is it still usable?\n\n\nSee the first screenshot: the UI is still visible, and doesn't close\nuntil the error report is sent. I'm not sure whether it's usable, as I\nhadn't thought to try.\n\n\n\n\n\n\nI'll let you know of course if I have anything further to report.\n\nRegards,\n\nNicholas"],["f","Attachments (not included in the exhibit): Bitcoin error.png, Bitcoin error2.png"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/27%2020090201-Re_Another%20crash-114913.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/27%2020090201-Re_Another%20crash-114913.pdf","sj":"Re: Another crash","to":"satoshi@vistomail.com","fe":"","od":"01/02/2009, 11:52 (UK time)"},{"f":"Satoshi Nakamoto","d":1233502380,"b":[["q","I haven't got the file mentioned\nthere, e02_appcompat.txt - it is deleted by sending the error report,\nwhich I did before thinking to make a copy. However, I sent you the\ncorresponding file for an earlier crash attached to my message of 25th\nJanuary."],["t","No worries, that only tells what program it was. There's another\nuseful dump report, but they keep the file locked so you can't get it.\n\nI eventually figured it out from 0x000be368 (fault address).\n\n\n See the first screenshot: the UI is still visible, and doesn't close\n until the error report is sent. I'm not sure whether it's usable, as I\n hadn't thought to try.\n\n\nIt's probably still fully functional, in which case you could push\nthe crash message off the screen and ignore it. The thread that\ncrashed already did the main part of its job. You were still\nfully operational on the network and generating during the times\nyou were crashed.\n\n\n I'll let you know of course if I have anything further to report.\n\n\nThanks.\n\nBTW, I sent a transfer to your Bitcoin address in case you're\ncurious what that looks like. (It can only get \"from\" and\ncomment info if you can receive incoming connections)\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/28%20s20090201-Re_Another%20crash-127904.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/28%20s20090201-Re_Another%20crash-127904.pdf","sj":"Re: Another crash","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"01/02/2009, 15:33 (UK time)"},{"f":"Nicholas Bohm","d":1233528720,"b":[["t","Satoshi Nakamoto wrote:\n...\n\n\n BTW, I sent a transfer to your Bitcoin address in case you're\n curious what that looks like. (It can only get \"from\" and\n comment info if you can receive incoming connections)\n\n\nThank you! I now see:\n\n35 blocks 01/02/2009 16:25 Received with: !Me\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00\n\nIt slowly begins to feel a little more real.\n\n(And no further crashes yet.)\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/29%2020090201-Re_Another%20crash-130495.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/29%2020090201-Re_Another%20crash-130495.pdf","sj":"Re: Another crash","to":"satoshi@vistomail.com","fe":"","od":"01/02/2009, 22:52 (UK time)"}],"id":"x113"},{"k":"x","s":"nicholas-bohm","t":"Bugfix","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Satoshi Nakamoto","d":1233436380,"b":[["t","Good news! I pinpointed the bug. The bug could occur if a DNS lookup failed.\n\nThe fix is at:\nhttp://www.upload.ae/file/14540/bc015-rar.html\n\nThanks for all your help and patience with this!\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/25%20s20090131-Bugfix-124536.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/25%20s20090131-Bugfix-124536.pdf","sj":"Bugfix","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"31/01/2009, 21:13 (UK time)"}],"id":"x114"},{"k":"x","s":"nicholas-bohm","t":"All's well","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1233574020,"b":[["t","No further trouble; but whereas the UI at first showed your transfer as:\n\n35 blocks 01/02/2009 16:25 Received with: !Me\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00\n\nit now (the morning after) shows:\n\n98 blocks 01/02/2009 16:25 Received with: Satoshi Nakamoto\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6                     +100.00\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/30%2020090202-All%27s%20well-131923.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/30%2020090202-All%27s%20well-131923.pdf","sj":"All's well","to":"satoshi@vistomail.com","fe":"","od":"02/02/2009, 11:27 (UK time)"},{"f":"Satoshi Nakamoto","d":1233598500,"b":[["q","No further trouble; but whereas the UI at first showed your transfer as:\n\n35 blocks 01/02/2009 16:25 Received with: !Me\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00\n\nit now (the morning after) shows:\n\n98 blocks 01/02/2009 16:25 Received with: Satoshi Nakamoto\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00"],["t","Everyone promptly presses \"Change...\" and labels their\nown address with my name.\n\nI need to figure out some way to convey that it's showing the\naddress you received it with, in just one or two words\n\nMaybe:\n\"Receiving address: \"\n\"Incoming address: \"\n\nOr the way e-mail programs do it:\n\"To: \"\n\"Recipient: \"\n\nWhich one do you think would work best, or is it just too much\nto overcome the predisposition to expect it to say who it's from\nno matter what it's labelled?\n\nThis would probably work best:\n\"From: unknown, To: Your Address 1cc....\"\nor\n\"From: anonymous, To: Your Address 1cc....\"\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/31%20s20090202-Re_All%27s%20well-133273.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/31%20s20090202-Re_All%27s%20well-133273.pdf","sj":"Re: All's well","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"02/02/2009, 18:15 (UK time)"},{"f":"Nicholas Bohm","d":1233662100,"b":[["t","Satoshi Nakamoto wrote:"],["q","No further trouble; but whereas the UI at first showed your transfer as:\n\n35 blocks 01/02/2009 16:25 Received with: !Me\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00\n\nit now (the morning after) shows:\n\n98 blocks 01/02/2009 16:25 Received with: Satoshi Nakamoto\n1CHE5JRfc5mr8ZtVUP7nnsS5HC4bWcXoc6 +100.00\n\n\nEveryone promptly presses \"Change...\" and labels their\nown address with my name."],["t","I hadn't touched \"Change\" in case of bungling something. When I did, it\nshowed your name against what I took to be my address - some sort of\ndefault?\n\nBy playing I see that I can have multiple addresses with different\nnames; and if the idea is to use them to distinguish the origin of\npayments, I could of course name each with the name of the person I\nintend to give it to for payment purposes.\n\nThis seems a bit uncertain, though - presumably if I give person A my\naddress for payments, nothing stops them giving it to Person B; and then\nI'll think payments from Person B are from Person A. Or have I missed\nsomething?\n\n\n I need to figure out some way to convey that it's showing the\n address you received it with, in just one or two words\n\n Maybe:\n \"Receiving address: \"\n \"Incoming address: \"\n\n Or the way e-mail programs do it:\n \"To: \"\n \"Recipient: \"\n\n Which one do you think would work best, or is it just too much\n to overcome the predisposition to expect it to say who it's from\n no matter what it's labelled?\n\n This would probably work best:\n \"From: unknown, To: Your Address 1cc....\"\n or\n \"From: anonymous, To: Your Address 1cc....\"\n\n\n\n\n\n\n\nPlease treat my comments with caution, as my grasp of Bitcoin is pretty\nsuperficial, to put it mildly; but I hope naive comments may still be\nuseful.\n\nMy preference is \"From: unknown, to: your address 1cc....\"\n\nI prefer \"unknown\" because I assume the system truly does not know the\nsource; \"anonymous\" suggests that it was the choice of the sender to\nconceal their name.\n\nI would see some merit in keeping the record of well understood\noperations like receipts and payments on a separate page from the record\nof generation and maturity, which are operations quite different from\nthose of ordinary bank accounts. (There could be separate tabs in the\none pane, for example. Receipts and payments could have separate\ncolumns for the amount, like many conventional bank statements.)\n\nIs it useful to keep forever lines such as:\n\n0/unconfirmed      02/02/2009 04:21       Generated (not accepted)        0.00 ?\n\nAnd I was initially baffled by legends like:\n\n97 blocks       02/02/2009 19:23       Generated (50.00 matures in 23\nblocks)\n\nbecause I thought that if it required 23 blocks to mature and I already\nhad 97, it ought surely to be mature already. (I worked it out in due\ncourse; but I would have understood at once if it had said \"matures in\n23 more blocks\".)\n\nNo doubt in due course a User Guide and FAQ will tackle a lot of things\nlike this.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/32%2020090203-Re_All%27s%20well-135610.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/32%2020090203-Re_All%27s%20well-135610.pdf","sj":"Re: All's well","to":"satoshi@vistomail.com","fe":"","od":"03/02/2009, 11:55 (UK time)"},{"f":"Satoshi Nakamoto","d":1233679320,"b":[["q","I hadn't touched \"Change\" in case of bungling something. When I did, it\nshowed your name against what I took to be my address - some sort of\ndefault?"],["t","You're the second person to tell me they don't remember labelling their address with my name.\nSurely you must have entered \"!Me\" at some point and then later replaced it with my name. The\nsoftware doesn't have my name coded into it anywhere and has no way to get it other than from\nthe user.\n\nI think I know what happened: if you copied the address, thinking it was my address, and entered\nit into your address book, it would have changed the label for your address. The entry would have\nfailed to show up in the address book. I need to make it check the address when you enter a new\naddress in the address book and if it's yours, give an error explaining it's one of yours.\n\nThe address labelling feature is inherently confusing. I've only stuck with it because it would be a\nnecessity in advanced scenarios, but as an advanced feature it isn't really needed until much later.\nI'm thinking I'll hide it, at least for now. Let it be simple for as long as possible.\n\nI'm still wavering between:\n\"Received with address 18cc...\"\nand\n\"From: unknown, To: 18cc...\"\n\nBut if \"Received with: (something) 18cc...\" left 2 out of 2 people thinking the address was the\nsender's address, then \"Received with address 18cc...\" might not be different enough to overpower\nthe natural expectation to see the sender's address there. What do you think? From/To still better?"],["q","This seems a bit uncertain, though - presumably if I give person A my\naddress for payments, nothing stops them giving it to Person B; and then\nI'll think payments from Person B are from Person A. Or have I missed\nsomething?"],["t","True for e-mail, maybe less so when paying a bill. For instance, \"send 9.95 to 18cc... to activate\nyour account\" or \"please make payment for this invoice to 18cc...\"."],["q","Please treat my comments with caution, as my grasp of Bitcoin is pretty\nsuperficial, to put it mildly; but I hope naive comments may still be\nuseful."],["t","No, that's exactly what I need, it's very helpful. I don't know how someone who doesn't already\nknow all about Bitcoin will interpret things. You only get once chance to see how something looks\nfor the first time, and I already spent all of mine.\n\nBTW, did you figure out that you could doubleclick on a transaction to open a details window?"],["q","but I would have understood at once if it had said \"matures in\n23 more blocks\".)"],["t","Good idea, definitely an improvement.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/33%20s20090203-Re_All%27s%20well-139657.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/33%20s20090203-Re_All%27s%20well-139657.pdf","sj":"Re: All's well","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"03/02/2009, 16:42 (UK time)"},{"f":"Nicholas Bohm","d":1233688440,"b":[["t","Satoshi Nakamoto wrote:"],["q","I hadn't touched \"Change\" in case of bungling something. When I did, it\nshowed your name against what I took to be my address - some sort of\ndefault?\n\n\nYou're the second person to tell me they don't remember labelling their\naddress with my name. Surely you must have entered \"!Me\" at some point\nand then later replaced it with my name. The software doesn't have my\nname coded into it anywhere and has no way to get it other than from the\nuser."],["t","No, I truly hadn't clicked the \"Change\" button until after I got your\npayment and read your remarks. As you know, I first found it reading\n\"!Me\"; I then clicked \"Change\" and found your name against my address; I\nthen went back to the main screen, and found your name instead of \"!Me\".\n So something odd is happening.\n\n\n I think I know what happened: if you copied the address, thinking it was\n my address, and entered it into your address book, it would have changed\n the label for your address. The entry would have failed to show up in\n the address book. I need to make it check the address when you enter a\n new address in the address book and if it's yours, give an error\n explaining it's one of yours.\n\n\nNo, I'm sure that isn't what I did.\n\n\n The address labelling feature is inherently confusing. I've only stuck\n with it because it would be a necessity in advanced scenarios, but as an\n advanced feature it isn't really needed until much later. I'm thinking\n I'll hide it, at least for now. Let it be simple for as long as possible.\n\n\nYes, I agree - keep it simple and see what enhancements are demanded.\n\n\n I'm still wavering between:\n \"Received with address 18cc...\"\n and\n \"From: unknown, To: 18cc...\"\n\n But if \"Received with: (something) 18cc...\" left 2 out of 2 people\n thinking the address was the sender's address, then \"Received with\n address 18cc...\" might not be different enough to overpower the natural\n expectation to see the sender's address there. What do you think?\n From/To still better?\n\n\nTo me it does, yes.\n\n\n\n\n\n\n\n\n   This seems a bit uncertain, though - presumably if I give person A my\n   address for payments, nothing stops them giving it to Person B; and then\n   I'll think payments from Person B are from Person A. Or have I missed\n   something?\n\n\n True for e-mail, maybe less so when paying a bill. For instance, \"send\n 9.95 to 18cc... to activate your account\" or \"please make payment for\n this invoice to 18cc...\".\n\n\nYes, I can see the tracking works well there. Perhaps a Bitcoin\nnetiquette will develop in which you treat a payment address I give you\nas setting up your account with me, which you don't want other people\npaying into (though perhaps the incentive is the other way, as you\npotentially benefit if they do).\n\n\n   Please treat my comments with caution, as my grasp of Bitcoin is pretty\n   superficial, to put it mildly; but I hope naive comments may still be\n   useful.\n\n\n No, that's exactly what I need, it's very helpful. I don't know how\n someone who doesn't already know all about Bitcoin will interpret\n things. You only get once chance to see how something looks for the\n first time, and I already spent all of mine.\n\n\nTrue; and I think I can remain clueless for quite a while.\n\n\n BTW, did you figure out that you could doubleclick on a transaction to\n open a details window?\n\n\nNo, a nice touch, especially if in due course the details become\ncontext-sensitive. I did try right-clicking, to see if that would get\nme a chance to delete the failed items, which I find mildly irritating.\n\n\n   but I would have understood at once if it had said \"matures in\n   23 more blocks\".)\n\n\n Good idea, definitely an improvement.\n\n\nPerhaps we should try a payment by me to you, if you would let me have\nan address. I would be interested to see how it works if the payment is\nnot bc50 or a multiple, for example.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/34%2020090203-Re_All%27s%20well-143760.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/34%2020090203-Re_All%27s%20well-143760.pdf","sj":"Re: All's well","to":"satoshin@gmx.com","fe":"","od":"03/02/2009, 19:14 (UK time)"},{"f":"Satoshi Nakamoto","d":1233700140,"b":[["t","Nicholas Bohm wrote:"],["q","No, I'm sure that isn't what I did."],["t","Do you remember ever entering \"!Me\" or my name into the program at any time?\n\n\n   BTW, did you figure out that you could doubleclick on a transaction to\n   open a details window?\n\n\n No, a nice touch, especially if in due course the details become\n context-sensitive. I did try right-clicking, to see if that would get\n me a chance to delete the failed items, which I find mildly irritating.\n\n\nDespite the similarities to an e-mail program, it's not obvious to doubleclick on transactions.\nThere's no critical info in there so it's fine for now. I hadn't thought of the context menu, I'll plan\nto use that in the future.\n\n\n Perhaps we should try a payment by me to you, if you would let me have\n an address. I would be interested to see how it works if the payment is\n not bc50 or a multiple, for example.\n\n\nSure, it's 1GtkM4wviwohP192tec9g83hd9X5qtbk9j\n\nI'll send back +0.01 as a confirmation.\n\nIt looks just the same with any amount. If you want to see more details of what's going on\ninternally, run it as bitcoin -debug and it'll show a debug print with the transaction details. It\nbasically selects the closest combination of coins to the amount and writes a transaction with the\nchange going back to yourself.\n\nI uploaded bc015a.rar with the changes we've been discussing to:\nhttp://www.upload.ae/file/14702/bc015a-rar.html\n\nI'm going to release 0.1.5 soon.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/35%20s20090203-Re_All%27s%20well-148664.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/35%20s20090203-Re_All%27s%20well-148664.pdf","sj":"Re: All's well","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"03/02/2009, 22:29 (UK time)"},{"f":"Nicholas Bohm","d":1233701040,"b":[["t","Satoshi Nakamoto wrote:"],["q","Nicholas Bohm wrote:\nNo, I'm sure that isn't what I did.\n\n\nDo you remember ever entering \"!Me\" or my name into the program at any\ntime?"],["t","No, I'm sure I didn't.\n\n\n\n    BTW, did you figure out that you could doubleclick on a transaction to\n    open a details window?\n\n\n   No, a nice touch, especially if in due course the details become\n   context-sensitive. I did try right-clicking, to see if that would get\n   me a chance to delete the failed items, which I find mildly irritating.\n\n\n Despite the similarities to an e-mail program, it's not obvious to\n doubleclick on transactions. There's no critical info in there so it's\n fine for now. I hadn't thought of the context menu, I'll plan to use\n that in the future.\n\n\n   Perhaps we should try a payment by me to you, if you would let me have\n   an address. I would be interested to see how it works if the payment is\n   not bc50 or a multiple, for example.\n\n\n Sure, it's 1GtkM4wviwohP192tec9g83hd9X5qtbk9j\n\n I'll send back +0.01 as a confirmation.\n\n\nFine, I'll give it a try.\n\n\n It looks just the same with any amount. If you want to see more details\n of what's going on internally, run it as bitcoin -debug and it'll show a\n debug print with the transaction details. It basically selects the\n closest combination of coins to the amount and writes a transaction with\n the change going back to yourself.\n\n I uploaded bc015a.rar with the changes we've been discussing to:\n http://www.upload.ae/file/14702/bc015a-rar.html\n\n I'm going to release 0.1.5 soon.\n\n\nI'll look out for it.\n\n\n\n\n\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/36%2020090203-Re_All%27s%20well-151710.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/36%2020090203-Re_All%27s%20well-151710.pdf","sj":"Re: All's well","to":"satoshin@gmx.com","fe":"","od":"03/02/2009, 22:44 (UK time)"},{"f":"Nicholas Bohm","d":1233701460,"b":[["t","Just to say the sending seemed very straightforward, as was the\nresulting entry.\n\nAnd when you get used to the double-click, it's actually simpler than a\nright-click and selecting from a menu. So perhaps it's just a matter of\nuser guidance.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/37%2020090203-Re_All%27s%20well-154345.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/37%2020090203-Re_All%27s%20well-154345.pdf","sj":"Re: All's well","to":"satoshin@gmx.com","fe":"","od":"03/02/2009, 22:51 (UK time)"}],"id":"x115"},{"k":"x","s":"nicholas-bohm","t":"Bitcoin","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1233702240,"b":[["t","The bc19.01 came back pretty swiftly! It hadn't in fact occurred to me\nthat you could use hundredths, though it's true that that is fairly\nconventional for currencies.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/38%2020090203-Bitcoin-155600.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/38%2020090203-Bitcoin-155600.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"03/02/2009, 23:04 (UK time)"},{"f":"Nicholas Bohm","d":1234284300,"b":[["t","Just to let you know that Bitcoin has generated no new packets today,\nalthough it typically generates 8 to 10 packets each day (although\nsometimes fewer), and the option to generate is ticked. Existing\npackets are proceedings towards maturity, or have matured, at about the\nusual rate. Progress to maturity takes around 21 to 23 hours.\n\nI thought this was an anomaly that might be of interest.\n\nregards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/40%2020090210-Bitcoin-161821.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/40%2020090210-Bitcoin-161821.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"10/02/2009, 16:45 (UK time)"},{"f":"Nicholas Bohm","d":1234287900,"b":[["t","A follow-up to my earlier message: today's first packet has now been\ngenerated, at 16:54, and had accumulated 7 blocks within its first hour.\n Previous first packets of the day have usually been around 03:00.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/41%2020090210-Bitcoin-163070.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/41%2020090210-Bitcoin-163070.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"10/02/2009, 17:45 (UK time)"},{"f":"Satoshi Nakamoto","d":1234370940,"b":[["t","Could be something else is taking CPU. Run Task Manager (taskmgr) and check if bitcoin.exe is\ngetting >90 CPU. If not, see what is. Sometimes a page will have a broken javascript that makes\nyour browser waste most of the CPU.\n\nIf it already went back to normal, could be a fluke. Randomness bunches up sometimes.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/42%20s20090211-Re_Bitcoin-164129.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/42%20s20090211-Re_Bitcoin-164129.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"11/02/2009, 16:49 (UK time)"},{"f":"Nicholas Bohm","d":1234374900,"b":[["t","Satoshi Nakamoto wrote:"],["q","Could be something else is taking CPU. Run Task Manager (taskmgr) and\ncheck if bitcoin.exe is getting >90 CPU. If not, see what is. Sometimes\na page will have a broken javascript that makes your browser waste most\nof the CPU."],["t","I've looked from time to time, and Bitcoin invariably gets exactly 50%\nof CPU, even when System Idle Process is getting the other 50%. I\nassumed this was set, and had it in mind to ask you whether the setting\ncould be changed so that Bitcoin could be given its head (e.g. overnight).\n\n\n If it already went back to normal, could be a fluke. Randomness bunches\n up sometimes.\n\n\nYes, one mustn't read too much into it. There were 11 packets of 50 on\nthe 8th, 8 on the 9th, 2 on the 10th and 4 down to 18.00 today. 2 seems\nquite a long way out of line, but it's still the short run, no doubt.\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/43%2020090211-Re_Bitcoin-165922.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/43%2020090211-Re_Bitcoin-165922.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"11/02/2009, 17:55 (UK time)"},{"f":"Satoshi Nakamoto","d":1234378680,"b":[["t","Nicholas Bohm wrote:"],["q","I've looked from time to time, and Bitcoin invariably gets exactly 50%\nof CPU, even when System Idle Process is getting the other 50%. I\nassumed this was set, and had it in mind to ask you whether the setting\ncould be changed so that Bitcoin could be given its head (e.g. overnight)."],["t","Do you have a dual core system, such as a Core 2 Duo? Bitcoin currently only launches one\nprocess to generate coins but it could easily launch one for each processor. It's probably about\ntime I implemented that.\n\nSatoshi"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/44%20s20090211-Re_Bitcoin-167726.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/44%20s20090211-Re_Bitcoin-167726.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"11/02/2009, 18:58 (UK time)"},{"f":"Nicholas Bohm","d":1234390740,"b":[["t","Satoshi Nakamoto wrote:"],["q","Nicholas Bohm wrote:\nI've looked from time to time, and Bitcoin invariably gets exactly 50%\nof CPU, even when System Idle Process is getting the other 50%. I\nassumed this was set, and had it in mind to ask you whether the setting\ncould be changed so that Bitcoin could be given its head (e.g.\novernight).\n\n\nDo you have a dual core system, such as a Core 2 Duo? Bitcoin currently\nonly launches one process to generate coins but it could easily launch\none for each processor. It's probably about time I implemented that."],["t","I have a Hewlett-Packard HP Compaq dc5750 Microtower with an\nAMD Athlon(tm) 64 X2 Dual Core Processor 4200+ 2.19 GHz, 1.87 GB of RAM\n\nSo it looks as though I could run more processes; and it may be that\nBitcoin is getting 100% of half the available CPU.\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/45%2020090211-Re_Bitcoin-169866.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/45%2020090211-Re_Bitcoin-169866.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"11/02/2009, 22:19 (UK time)"}],"id":"x116"},{"k":"x","s":"nicholas-bohm","t":"Bitcoin UI question","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1234461120,"b":[["t","The bottom of the UI shows:\n\nGenerating      4 connections    4024 blocks    164 transactions\n\nI understand \"generating\"; I assume I am connected to 4 other nodes; and\nI know I have recorded 164 transactions (including failed generation\nattempts). I'm not clear what the \"blocks\" figure describes. It's much\nsmaller than the total of all the blocks shown against all my transactions.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/46%2020090212-Bitcoin%20UI%20question-171698.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/46%2020090212-Bitcoin%20UI%20question-171698.pdf","sj":"Bitcoin UI question","to":"satoshin@gmx.com","fe":"","od":"12/02/2009, 17:52 (UK time)"},{"f":"Satoshi Nakamoto","d":1234537740,"b":[["t","It's the total number of blocks in the block chain, meaning the network's block chain, which\neveryone has a copy of. Every Bitcoin node displays the same number and it goes up about every\n10 minutes whenever someone generates a block. When you haven't had it running for a while,\nonce you're connected it spins up rapidly as it downloads what was generated while you were gone\nto catch up. I'm not sure exactly how to describe it (that would fit on the status bar in 1 word,\nmaybe 2 words max), any ideas?\n\nThe blocks number in the status column next to your transactions is the number of blocks that\nhave come after that transaction. Your transaction is essentially \"in\" that many blocks.\n\nSatoshi\n\nNicholas Bohm wrote:"],["q","The bottom of the UI shows:\n\nGenerating      4 connections    4024 blocks    164 transactions\n\nI understand \"generating\"; I assume I am connected to 4 other nodes; and\nI know I have recorded 164 transactions (including failed generation\nattempts). I'm not clear what the \"blocks\" figure describes. It's much\nsmaller than the total of all the blocks shown against all my transactions.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/47%20s20090213-Re_Bitcoin%20UI%20question-172968.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/47%20s20090213-Re_Bitcoin%20UI%20question-172968.pdf","sj":"Re: Bitcoin UI question","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"13/02/2009, 15:09 (UK time)"},{"f":"Nicholas Bohm","d":1234539420,"b":[["t","Satoshi Nakamoto wrote:"],["q","It's the total number of blocks in the block chain, meaning the\nnetwork's block chain, which everyone has a copy of. Every Bitcoin node\ndisplays the same number and it goes up about every 10 minutes whenever\nsomeone generates a block. When you haven't had it running for a while,\nonce you're connected it spins up rapidly as it downloads what was\ngenerated while you were gone to catch up. I'm not sure exactly how to\ndescribe it (that would fit on the status bar in 1 word, maybe 2 words\nmax), any ideas?"],["t","In one or two words I can't think how to do it, I admit. Must it be\nthat short? There seems to be a fair asmount of room in the status bar\n(especially if the window is sized so that the descriptive text for\npayment and receipt transactions isn't truncated). How to say it best\nprobably depends on the (future) user guide and FAQs, as it needs to\nlink in sensibly with what they say. It sounds as though it should say\n\"**** blocks in network chain\".\n\n\n The blocks number in the status column next to your transactions is the\n number of blocks that have come after that transaction. Your\n transaction is essentially \"in\" that many blocks.\n\n\nI follow that.\n\nThanks,\n\nNicholas\nSatoshi\n\n Nicholas Bohm wrote:"],["q","The bottom of the UI shows:\n\nGenerating      4 connections    4024 blocks    164 transactions\n\nI understand \"generating\"; I assume I am connected to 4 other nodes; and\nI know I have recorded 164 transactions (including failed generation\nattempts). I'm not clear what the \"blocks\" figure describes. It's much\nsmaller than the total of all the blocks shown against all my\n\n\n\n\n\ntransactions.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/48%2020090213-Re_Bitcoin%20UI%20question-175703.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/48%2020090213-Re_Bitcoin%20UI%20question-175703.pdf","sj":"Re: Bitcoin UI question","to":"satoshin@gmx.com","fe":"","od":"13/02/2009, 15:37 (UK time)"}],"id":"x117"},{"k":"x","s":"nicholas-bohm","t":"[bitcoin-list] Bitcoin v0.1.5 released","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Hal Finney","d":1235764800,"b":[["t","On Sun, Feb 22, 2009 at 9:35 AM, Satoshi Nakamoto <satoshi@vistomail.com> wrote:"],["q","What's next?\n\n\nThe next thing for v0.1.6 is to take advantage of multiple\nprocessors to generate blocks. Currently it only starts one\nthread. If you have a multi-core processor like a Core Duo or\nQuad this will double or quadruple your production."],["t","That sounds good. I'd also like to be able to run multiple coin/block\ngenerators on multiple machines, all behind a single NAT address. I\nhaven't tried this yet so I don't know if it works on the current\nsoftware.\n\nBTW I don't remember if we talked about this, but the other day some\npeople were mentioning secure timestamping. You want to be able to\nprove that a certain document existed at a certain time in the past.\nSeems to me that bitcoin's stack of blocks would be perfect for this.\n\n\n Later I want to add interfaces to make it really easy to integrate\n into websites from any server side language.\n\n\nRight, and I'd like to see more of a library interface that could be\ncalled from programming or scripting languages, on the client side as\nwell.\n\nHal\n\n------------------------------------------------------------------------------\nOpen Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA\n-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise\n-Strategies to boost innovation and cut costs with open source participation\n-Receive a $600 discount off the registration fee with the source code: SFAD\nhttp://p.sf.net/sfu/XcvMzF8H\n_______________________________________________\nbitcoin-list mailing list\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/51%2020090227-Re_%5Bbitcoin-list%5D%20Bitcoin%20v0.1.5%20released-181564.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/51%2020090227-Re_%5Bbitcoin-list%5D%20Bitcoin%20v0.1.5%20released-181564.pdf","sj":"Re: [bitcoin-list] Bitcoin v0.1.5 released","to":"satoshi@vistomail.com","fe":"","od":"27/02/2009, 20:00 (UK time)"},{"f":"Satoshi Nakamoto","d":1236184020,"b":[["t","Hal Finney wrote:"],["q","That sounds good. I'd also like to be able to run multiple coin/block\ngenerators on multiple machines, all behind a single NAT address. I\nhaven't tried this yet so I don't know if it works on the current\nsoftware."],["t","The current version will work fine. They'll each connect over the\nInternet, while incoming connections only come to the host that\nport 8333 is routed to.\n\nAs an optimisation, I'll make a switch \"-connect=[IP address removed]\" to make\nit only connect to a specific address. You could make your extra\nnodes connect to your primary, and only the primary connects over\nthe Internet. It doesn't really matter for now, since the network\nwould have to get huge before the bandwidth is anything more than\ntrivial.\n\n\n\n BTW I don't remember if we talked about this, but the other day some\n people were mentioning secure timestamping. You want to be able to\n prove that a certain document existed at a certain time in the past.\n Seems to me that bitcoin's stack of blocks would be perfect for this.\n\n\nIndeed, Bitcoin is a distributed secure timestamp server for\ntransactions. A few lines of code could create a transaction with\nan extra hash in it of anything that needs to be timestamped.\nI should add a command to timestamp a file that way.\n\n\n\n\n    Later I want to add interfaces to make it really easy to integrate\n    into websites from any server side language.\n\n\n Right, and I'd like to see more of a library interface that could be\n called from programming or scripting languages, on the client side as\n well.\n\n\nExactly.\n\n\nSatoshi Nakamoto\n\nhttp://www.bitcoin.org\n\n\n\n\n\n\n\n------------------------------------------------------------------------------\nOpen Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA\n-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise\n-Strategies to boost innovation and cut costs with open source participation\n-Receive a $600 discount off the registration fee with the source code: SFAD\nhttp://p.sf.net/sfu/XcvMzF8H\n_______________________________________________\nbitcoin-list mailing list\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-list"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/52%20s20090304-Re_%5Bbitcoin-list%5D%20Bitcoin%20v0.1.5%20released-187375.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/52%20s20090304-Re_%5Bbitcoin-list%5D%20Bitcoin%20v0.1.5%20released-187375.pdf","sj":"Re: [bitcoin-list] Bitcoin v0.1.5 released","s":1,"to":"Nicholas Bohm","fe":"satoshi@vistomail.com","od":"04/03/2009, 16:27 (UK time)"}],"id":"x118"},{"k":"x","s":"nicholas-bohm","t":"Generated (not accepted)","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1238758740,"b":[["t","I'm having an unusual run of failures, and thought I'd let you know in\ncase this was of any significance.\n\nRegards,\n\nNicholas"],["f","Attachments (not included in the exhibit): Screenshot.png"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/53%2020090403-Generated%20%28not%20accepted%29-193026.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/53%2020090403-Generated%20%28not%20accepted%29-193026.pdf","sj":"Generated (not accepted)","to":"satoshi@vistomail.com","fe":"","od":"03/04/2009, 12:39 (UK time)"},{"f":"Satoshi Nakamoto","d":1238982840,"b":[["t","What rate of not-accepted did you see? I didn't see anything unusual on my end. If you had more\nthan, say, 4 in a row, that would be abnormal and probably a loss of network communication. If\nit's scattered and less than 25%, just random bad luck. It's normal and harmless to randomly get\nsome per cent of not-accepted, and of course randomness can sometimes bunch up and look like a\npattern.\n\nThe idea of an option to View/Hide unaccepted blocks is a good one, as well as View/Hide all\ngenerated blocks so you can more easily see incoming transactions. Seeing the unaccepted blocks\nis just annoying and frustrating. Everyone faces the same rate of unaccepted, it's just a part of the\nprocess. It would probably be best to default to hide unaccepted blocks, so as not to show giving\nand taking away something that never was, and not show new generated blocks at all until they\nhave at least one confirmation. It would only mean finding out you have a generated block 15\nminutes later than normal, and then you still have 119 blocks to go before it matures anyway. This\nis on the to-do list for v0.1.6.\n\nSatoshi\n\n\n\n\n I'm having an unusual run of failures, and thought I'd let you know in\n case this was of any significance.\n\n Regards,\n\n Nicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/54%20s20090406-Re_Generated%20%28not%20accepted%29-194684.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/54%20s20090406-Re_Generated%20%28not%20accepted%29-194684.pdf","sj":"Re: Generated (not accepted)","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"06/04/2009, 02:54 (UK time)"},{"f":"Nicholas Bohm","d":1239010200,"b":[["t","Satoshi Nakamoto wrote:"],["q","What rate of not-accepted did you see? I didn't see anything unusual on\nmy end. If you had more than, say, 4 in a row, that would be abnormal\nand probably a loss of network communication. If it's scattered and\nless than 25%, just random bad luck. It's normal and harmless to\nrandomly get some per cent of not-accepted, and of course randomness can\nsometimes bunch up and look like a pattern."],["t","This was the odd run (shown in context):\n\n132 blocks      05/04/2009 09:19       Generated\n168 blocks      05/04/2009 03:08       Generated\n191 blocks      04/04/2009 22:08       Generated\n193 blocks      04/04/2009 21:52       Generated\n219 blocks      04/04/2009 16:52       Generated\n230 blocks      04/04/2009 14:52       Generated\n270 blocks      04/04/2009 05:48       Generated\n311 blocks      03/04/2009 20:57       Generated\n324 blocks      03/04/2009 18:01       Generated\n330 blocks      03/04/2009 16:50       Generated\n336 blocks      03/04/2009 15:54       Generated\n0/unconfirmed    03/04/2009 10:10       Generated (not accepted)\n0/unconfirmed    03/04/2009 08:00       Generated (not accepted)\n0/unconfirmed    03/04/2009 04:43       Generated (not accepted)\n0/unconfirmed    02/04/2009 21:43       Generated (not accepted)\n0/unconfirmed    02/04/2009 19:09       Generated (not accepted)\n0/unconfirmed    02/04/2009 16:05       Generated (not accepted)\n452 blocks      02/04/2009 14:46       Generated\n\nIt could be loss of connectivity, though I wasn't aware of it at the time.\n\n\n The idea of an option to View/Hide unaccepted blocks is a good one, as\n well as View/Hide all generated blocks so you can more easily see\n incoming transactions. Seeing the unaccepted blocks is just annoying\n and frustrating. Everyone faces the same rate of unaccepted, it's just\n a part of the process. It would probably be best to default to hide\n unaccepted blocks, so as not to show giving and taking away something\n that never was, and not show new generated blocks at all until they have\n at least one confirmation. It would only mean finding out you have a\n generated block 15 minutes later than normal, and then you still have\n 119 blocks to go before it matures anyway. This is on the to-do list\n for v0.1.6.\n\n\nSounds good to me. I assume you still have plans for multi-processor\nsupport.\n\n\n\n\n\n\n\n\n  I'm having an unusual run of failures, and thought I'd let you know in\n  case this was of any significance.\n\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/55%2020090406-Re_Generated%20%28not%20accepted%29-197607.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/55%2020090406-Re_Generated%20%28not%20accepted%29-197607.pdf","sj":"Re: Generated (not accepted)","to":"satoshin@gmx.com","fe":"","od":"06/04/2009, 10:30 (UK time)"}],"id":"x119"},{"k":"x","s":"nicholas-bohm","t":"Bitcoin","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1242555060,"b":[["t","Bitcoin continues to run smoothly, but I noticed an unusual event:\n\n731 blocks       11/05/2009 15:58     Generated           +50.10\n\nAll prior and subsequent generated packers have been of exactly 50.\n\nJust in case this is of interest!\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/56%2020090517-Bitcoin-201130.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/56%2020090517-Bitcoin-201130.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"17/05/2009, 11:11 (UK time)"},{"f":"Nicholas Bohm","d":1242840180,"b":[["t","I notice a surprising number of \"not accepted\" at the moment:\n\n0/unconfirmed   20/05/2009 15:09   Generated (not accepted)\n29 blocks     20/05/2009 10:54   Generated (50.00 matures in 91\nmore blocks)\n0/unconfirmed   20/05/2009 03:15   Generated (not accepted)\n0/unconfirmed   20/05/2009 03:06   Generated (not accepted)\n0/unconfirmed   19/05/2009 19:11   Generated (not accepted)\n0/unconfirmed   19/05/2009 12:47   Generated (not accepted)\n133 blocks    19/05/2009 06:31   Generated\n134 blocks    19/05/2009 06:31   Generated\n0/unconfirmed   18/05/2009 23:08   Generated (not accepted)\n0/unconfirmed   18/05/2009 19:25   Generated (not accepted)\n0/unconfirmed   18/05/2009 15:18   Generated (not accepted)\n0/unconfirmed   18/05/2009 12:28   Generated (not accepted)\n0/unconfirmed   18/05/2009 11:31   Generated (not accepted)\n257 blocks    18/05/2009 06:29   Generated\n278 blocks    18/05/2009 01:51   Generated\n285 blocks    18/05/2009 00:43   Generated\n305 blocks    17/05/2009 20:53   Generated\n313 blocks    17/05/2009 19:35   Generated\n317 blocks    17/05/2009 18:51   Generated\n326 blocks    17/05/2009 17:32   Generated\n0/unconfirmed   17/05/2009 12:14   Generated (not accepted)\n0/unconfirmed   17/05/2009 08:49   Generated (not accepted)\n395 blocks    17/05/2009 03:51   Generated\n403 blocks    17/05/2009 02:09   Generated\n0/unconfirmed   16/05/2009 21:49   Generated (not accepted)\n431 blocks    16/05/2009 20:44   Generated\n432 blocks    16/05/2009 20:42   Generated\n0/unconfirmed   16/05/2009 20:20   Generated (not accepted)\n0/unconfirmed   16/05/2009 19:58   Generated (not accepted)\n0/unconfirmed   16/05/2009 15:18   Generated (not accepted)\n0/unconfirmed   16/05/2009 15:10   Generated (not accepted)\n503 blocks    16/05/2009 04:51   Generated\n505 blocks    16/05/2009 04:42   Generated\n510 blocks    16/05/2009 03:46   Generated\n523 blocks    16/05/2009 01:50   Generated\n0/unconfirmed   15/05/2009 21:12   Generated (not accepted)\n\nJust in case it's worthy of note.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/57%2020090520-Bitcoin-202224.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/57%2020090520-Bitcoin-202224.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"20/05/2009, 18:23 (UK time)"},{"f":"Satoshi Nakamoto","d":1243197900,"b":[["t","That's the transaction fee feature. If you generate a block containing a transaction that includes a\ntransaction fee, you earn the transaction fee in addition to the 50.00. Someone must have\nincluded a 0.10 fee with one of their transactions. The setting to do that is under options.\nIncluding a fee is completely optional, more of a donation to nodes for helping out.\n\n\n\n Bitcoin continues to run smoothly, but I noticed an unusual event:\n\n 731 blocks       11/05/2009 15:58      Generated           +50.10\n\n All prior and subsequent generated packers have been of exactly 50.\n\n Just in case this is of interest!\n\n Regards,\n\n Nicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/58%20s20090524-Re_Bitcoin-205277.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/58%20s20090524-Re_Bitcoin-205277.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"24/05/2009, 21:45 (UK time)"},{"f":"Nicholas Bohm","d":1243239240,"b":[["t","Satoshi Nakamoto wrote:"],["q","That's the transaction fee feature. If you generate a block containing\na transaction that includes a transaction fee, you earn the transaction\nfee in addition to the 50.00. Someone must have included a 0.10 fee\nwith one of their transactions. The setting to do that is under\noptions. Including a fee is completely optional, more of a donation to\nnodes for helping out.\n\n\n\nBitcoin continues to run smoothly, but I noticed an unusual event:\n\n731 blocks       11/05/2009 15:58     Generated            +50.10\n\nAll prior and subsequent generated packers have been of exactly 50.\n\nJust in case this is of interest!\n\nRegards,\n\nNicholas"],["t","Thanks for the explanation. I've set a transaction fee of 0.07, just to\nsee how it works out. (I feel I can afford it, as my balance is now\nover 35,000!)\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/59%2020090525-Re_Bitcoin-207675.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/59%2020090525-Re_Bitcoin-207675.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"25/05/2009, 09:14 (UK time)"},{"f":"Nicholas Bohm","d":1244107260,"b":[["t","I've installed a new router and cannot get Bitcoin to connect.\n\nI've altered the firewall rule to allow inbound services via SMTP, which\nseems to be the name for port 25. Is that right? Should there be\nanything else I ought to do?\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/61%2020090604-Bitcoin-220712.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/61%2020090604-Bitcoin-220712.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"04/06/2009, 10:21 (UK time)"},{"f":"Nicholas Bohm","d":1244197440,"b":[["t","I've achieved a connection to bitcoin through my new router, so whatever\nI did must have been right. Please disregard my last message.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/62%2020090605-Bitcoin-221796.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/62%2020090605-Bitcoin-221796.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"05/06/2009, 11:24 (UK time)"},{"f":"Satoshi Nakamoto","d":1244234400,"b":[["t","You should set your router to forward port 8333 so you can receive incoming connections. If\nyou're not set up to receive incoming connections and nobody else who's online is, then you can't\nconnect. It would also help solve the \"(not accepted)\" issues.\n\nSatoshi\n\n\n I've achieved a connection to bitcoin through my new router, so whatever\n I did must have been right. Please disregard my last message.\n\n Regards,\n\n Nicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/63%20s20090605-Re_Bitcoin-222782.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/63%20s20090605-Re_Bitcoin-222782.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"05/06/2009, 21:40 (UK time)"}],"id":"x120"},{"k":"x","s":"nicholas-bohm","t":"Many not accepted","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1243954860,"b":[["t","There seems to be a high number of non acceptances recently, so I\nthought it might be helpful to report.\n\n21 blocks      02/06/2009 11:30    Generated (50.00 matures in 99\nmore blocks)                          0.00\n 0/unconfirmed    01/06/2009 22:00    Generated (not accepted)\n                                   0.00\n 0/unconfirmed    01/06/2009 21:54    Generated (not accepted)\n                                   0.00\n 111 blocks     01/06/2009 07:18    Generated (50.00 matures in 9\nmore blocks)                          0.00\n 112 blocks     01/06/2009 07:08    Generated (50.00 matures in 8\nmore blocks)                          0.00\n 127 blocks     01/06/2009 03:59    You're welcome.\n                                 +0.01\n 128 blocks     01/06/2009 03:58    Generated\n                                 +50.00\n 0/unconfirmed    01/06/2009 02:02    Generated (not accepted)\n                                   0.00\n 0/unconfirmed    31/05/2009 22:26    Generated (not accepted)\n                                   0.00\n 0/unconfirmed    31/05/2009 20:02    Generated (not accepted)\n                                   0.00\n 198 blocks     31/05/2009 09:21    Generated\n                                 +50.00\n 213 blocks     31/05/2009 05:50    Generated\n                                 +50.00\n 221 blocks     31/05/2009 04:15    Generated\n                                 +50.00\n 0/unconfirmed    30/05/2009 22:44    Generated (not accepted)\n                                   0.00\n 296 blocks     30/05/2009 12:44    Generated\n                                 +50.00\n 0/unconfirmed    30/05/2009 09:33    Generated (not accepted)\n                                   0.00\n 0/unconfirmed    30/05/2009 09:17    Generated (not accepted)\n                                   0.00\n 351 blocks     29/05/2009 22:43    Generated\n                                 +50.00\n 0/unconfirmed    29/05/2009 19:08    Generated (not accepted)\n                                   0.00\n 378 blocks     29/05/2009 17:01    Generated\n                                 +50.00\n 380 blocks     29/05/2009 16:42    Generated\n                                 +50.00\n 0/unconfirmed    29/05/2009 16:22    Generated (not accepted)\n                                   0.00\n 0/unconfirmed    29/05/2009 14:08    Generated (not accepted)\n                                   0.00\n 430 blocks     29/05/2009 05:27    Generated\n                                 +50.00\n 0/unconfirmed    29/05/2009 01:12    Generated (not accepted)\n\n\n\n\n\n                                  0.00\n493 blocks      28/05/2009 14:31   Generated\n                                 +50.00\n503 blocks      28/05/2009 12:17   Generated\n                                 +50.00\n0/unconfirmed    28/05/2009 12:03    Generated (not accepted)\n                                  0.00\n0/unconfirmed    28/05/2009 00:38    Generated (not accepted)\n                                  0.00\n583 blocks      27/05/2009 17:19   Generated\n                                 +50.00\n607 blocks      27/05/2009 12:33   Generated\n                                 +50.00\n639 blocks      27/05/2009 06:09   Generated\n                                 +50.00\n653 blocks      27/05/2009 03:13   Generated\n                                 +50.00\n658 blocks      27/05/2009 01:38   Generated\n                                 +50.00\n662 blocks      27/05/2009 01:12   Generated\n                                 +50.00\n0/unconfirmed    26/05/2009 13:34    Generated (not accepted)\n                                  0.00\n756 blocks      26/05/2009 07:57   Generated\n                                 +50.00\n785 blocks      26/05/2009 01:14   Generated\n                                 +50.00\n818 blocks      25/05/2009 18:53   Generated\n                                 +50.00\n0/unconfirmed    25/05/2009 16:12    Generated (not accepted)\n                                  0.00\n0/unconfirmed    25/05/2009 15:50    Generated (not accepted)\n                                  0.00\n0/unconfirmed    25/05/2009 11:02    Generated (not accepted)\n                                  0.00\n0/unconfirmed    25/05/2009 10:44    Generated (not accepted)\n                                  0.00\n875 blocks      25/05/2009 07:16   Generated\n                                 +50.00\n890 blocks      25/05/2009 02:57   Generated\n                                 +50.00\n913 blocks      24/05/2009 21:55   Generated\n                                 +50.00\n928 blocks      24/05/2009 19:02   Generated\n                                 +50.00\n929 blocks      24/05/2009 18:47   Generated\n                                 +50.00\n946 blocks      24/05/2009 10:39   Generated\n                                 +50.00\n975 blocks      24/05/2009 05:22   Generated\n                                 +50.00\n976 blocks      24/05/2009 05:08   Generated\n                                 +50.00\n0/unconfirmed    24/05/2009 00:18    Generated (not accepted)\n                                  0.00\n0/unconfirmed    22/05/2009 14:59    Generated (not accepted)\n                                  0.00\n\n\n\n\n\n\n1034 blocks     22/05/2009 13:31    Generated\n                                +50.00\n1078 blocks     22/05/2009 03:30    Generated\n                                +50.00\n1084 blocks     22/05/2009 01:56    Generated\n                                +50.00\n1105 blocks     21/05/2009 21:28    Generated\n                                +50.00\n1142 blocks     21/05/2009 06:46    Generated\n                                +50.00\n1162 blocks     21/05/2009 02:48    Generated\n                                +50.00\n1168 blocks     21/05/2009 01:52    Generated\n                                +50.00\n1177 blocks     21/05/2009 00:01    Generated\n                                +50.00\n1189 blocks     20/05/2009 21:40    Generated\n                                +50.00\n0/unconfirmed    20/05/2009 21:09    Generated (not accepted)\n                                  0.00\n0/unconfirmed    20/05/2009 18:22    Generated (not accepted)\n                                  0.00\n1219 blocks     20/05/2009 16:26    Generated\n                                +50.00\n0/unconfirmed    20/05/2009 15:09    Generated (not accepted)\n                                  0.00\n1243 blocks     20/05/2009 10:54    Generated\n                                +50.00\n0/unconfirmed    20/05/2009 03:15    Generated (not accepted)\n                                  0.00\n0/unconfirmed    20/05/2009 03:06    Generated (not accepted)\n                                  0.00\n0/unconfirmed    19/05/2009 19:11    Generated (not accepted)\n                                  0.00\n0/unconfirmed    19/05/2009 12:47    Generated (not accepted)\n                                  0.00\n1347 blocks     19/05/2009 06:31    Generated\n                                +50.00\n1348 blocks     19/05/2009 06:31    Generated\n                                +50.00\n0/unconfirmed    18/05/2009 23:08    Generated (not accepted)\n                                  0.00\n0/unconfirmed    18/05/2009 19:25    Generated (not accepted)\n                                  0.00\n0/unconfirmed    18/05/2009 15:18    Generated (not accepted)\n                                  0.00\n0/unconfirmed    18/05/2009 12:28    Generated (not accepted)\n                                  0.00\n0/unconfirmed    18/05/2009 11:31    Generated (not accepted)\n                                  0.00\n1471 blocks     18/05/2009 06:29    Generated\n                                +50.00\n1492 blocks     18/05/2009 01:51    Generated\n                                +50.00\n1499 blocks     18/05/2009 00:43    Generated\n                                +50.00\n1519 blocks     17/05/2009 20:53    Generated\n\n\n\n\n\n\n                                +50.00\n1527 blocks     17/05/2009 19:35    Generated\n                                +50.00\n1531 blocks     17/05/2009 18:51    Generated\n                                +50.00\n1540 blocks     17/05/2009 17:32    Generated\n                                +50.00\n0/unconfirmed    17/05/2009 12:14    Generated (not accepted)\n                                  0.00\n0/unconfirmed    17/05/2009 08:49    Generated (not accepted)\n                                  0.00\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/60%2020090602-Many%20not%20accepted-209554.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/60%2020090602-Many%20not%20accepted-209554.pdf","sj":"Many not accepted","to":"satoshi@vistomail.com","fe":"","od":"02/06/2009, 16:01 (UK time)"}],"id":"x121"},{"k":"x","s":"nicholas-bohm","t":"Bitcoin","u":"https://github.com/NicholasBohm/emails","su":"https://github.com/NicholasBohm/emails","m":[{"f":"Nicholas Bohm","d":1247907540,"b":[["t","Bitcoin has failed to establish any connections for the last day or so,\ndespite restarts. I'm not aware of having made any changes to my\nsystem, so this is puzzling. Can you suggest what I might check?\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/65%2020090718-Bitcoin-230287.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/65%2020090718-Bitcoin-230287.pdf","sj":"Bitcoin","to":"satoshi@vistomail.com","fe":"","od":"18/07/2009, 09:59 (UK time)"},{"f":"Satoshi Nakamoto","d":1247972820,"b":[["t","Did your IP address change? And if so, what's the new address? I run a node but I can't accept\nincoming connections and if your IP address changed then I would have lost contact with you.\n\nThere may just not be anybody else running it right now. How many connections did you usually\nhave before? If you keep your server running, if new users come along at least they'll have\nsomeone to connect to, rather than get no connections and give up.\n\n(btw, it's better if you use my satoshin@gmx.com e-mail address)\n\nSatoshi\n\n\n Bitcoin has failed to establish any connections for the last day or so,\n despite restarts. I'm not aware of having made any changes to my\n system, so this is puzzling. Can you suggest what I might check?\n\n Regards,\n\n Nicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/66%20s20090719-Re_Bitcoin-231340.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/66%20s20090719-Re_Bitcoin-231340.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"19/07/2009, 04:07 (UK time)"},{"f":"Nicholas Bohm","d":1247995380,"b":[["t","Satoshi Nakamoto wrote:"],["q","Did your IP address change? And if so, what's the new address? I run a\nnode but I can't accept incoming connections and if your IP address\nchanged then I would have lost contact with you."],["t","My IP address is [IP address removed], and hasn't changed for quite a time as\nfar as I know.\n\n\n There may just not be anybody else running it right now. How many\n connections did you usually have before?\n\n\nIt varied from 3 to 5 mostly.\n\n\n If you keep your server\n running, if new users come along at least they'll have someone to\n connect to, rather than get no connections and give up.\n\n\nI'll leave it running. No blocks of coins have matured since 15th July.\n\n\n (btw, it's better if you use my satoshin@gmx.com e-mail address)\n\n\nOK\n\nRegards,\n\nNicholas\nBitcoin has failed to establish any connections for the last day or so,\n     despite restarts. I'm not aware of having made any changes to my\n     system, so this is puzzling. Can you suggest what I might check?\n\n     Regards,\n\n     Nicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/67%2020090719-Re_Bitcoin-233770.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/67%2020090719-Re_Bitcoin-233770.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"19/07/2009, 10:23 (UK time)"},{"f":"Satoshi Nakamoto","d":1248102300,"b":[["t","I guess something must be preventing you from receiving incoming connections. Mine has been\ntrying to connect to your IP without success. I'm currently connected to [IP address removed] since\nyesterday. If you're not at least connected to that one, then you can't connect out either.\n\nSatoshi\n\nNicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nDid your IP address change? And if so, what's the new address? I run a\nnode but I can't accept incoming connections and if your IP address\nchanged then I would have lost contact with you.\n\n\nMy IP address is [IP address removed], and hasn't changed for quite a time as\nfar as I know.\n\n\nThere may just not be anybody else running it right now. How many\nconnections did you usually have before?\n\n\nIt varied from 3 to 5 mostly.\n\n\nIf you keep your server\nrunning, if new users come along at least they'll have someone to\nconnect to, rather than get no connections and give up.\n\n\nI'll leave it running. No blocks of coins have matured since 15th July.\n\n\n(btw, it's better if you use my satoshin@gmx.com e-mail address)\n\n\nOK\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/68%20s20090720-Re_Bitcoin-235816.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/68%20s20090720-Re_Bitcoin-235816.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"20/07/2009, 16:05 (UK time)"},{"f":"Nicholas Bohm","d":1248103860,"b":[["t","Satoshi Nakamoto wrote:"],["q","I guess something must be preventing you from receiving incoming\nconnections. Mine has been trying to connect to your IP without\nsuccess. I'm currently connected to [IP address removed] since yesterday. If\nyou're not at least connected to that one, then you can't connect out\neither."],["t","I still had no connections, and couldn't see why not; but I stopped and\nrestarted bitcoin, and now have two connections. Although this is fewer\nthan for some weeks, and I have a clutch of \"not confirmed\" blocks when\nfor some weeks I had had none, at least it's up and running again.\nPrevious restarts made no difference, though.\n\nIncidentally, I set the optional transaction fee at 0.07. I expected\nthis to be visible as an outgoing (or as a deduction from blocks\ncreated), but so far I've seen nothing. Perhaps I've had no takers.\n\nRegards,\n\nNicholas\nNicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nDid your IP address change? And if so, what's the new address? I run a\nnode but I can't accept incoming connections and if your IP address\nchanged then I would have lost contact with you.\n\n\nMy IP address is [IP address removed], and hasn't changed for quite a time as\nfar as I know.\n\n\nThere may just not be anybody else running it right now. How many\nconnections did you usually have before?\n\n\nIt varied from 3 to 5 mostly.\n\n\nIf you keep your server\n\n\n\n\n\nrunning, if new users come along at least they'll have someone to\nconnect to, rather than get no connections and give up.\n\n\nI'll leave it running. No blocks of coins have matured since 15th July.\n\n\n(btw, it's better if you use my satoshin@gmx.com e-mail address)\n\n\nOK\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/69%2020090720-Re_Bitcoin-238645.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/69%2020090720-Re_Bitcoin-238645.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"20/07/2009, 16:31 (UK time)"},{"f":"Satoshi Nakamoto","d":1248140220,"b":[["t","The transaction fee setting refers to the amount you give when you make a transaction, not the\namount you demand from transactions you process. We're a long way from the point where nodes\nwill need to require a fee, but that can easily be implemented when needed.\n\nNicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nI guess something must be preventing you from receiving incoming\nconnections. Mine has been trying to connect to your IP without\nsuccess. I'm currently connected to [IP address removed] since yesterday. If\nyou're not at least connected to that one, then you can't connect out\neither.\n\n\nI still had no connections, and couldn't see why not; but I stopped and\nrestarted bitcoin, and now have two connections. Although this is fewer\nthan for some weeks, and I have a clutch of \"not confirmed\" blocks when\nfor some weeks I had had none, at least it's up and running again.\nPrevious restarts made no difference, though.\n\nIncidentally, I set the optional transaction fee at 0.07. I expected\nthis to be visible as an outgoing (or as a deduction from blocks\ncreated), but so far I've seen nothing. Perhaps I've had no takers.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/70%20s20090721-Re_Bitcoin-241473.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/70%20s20090721-Re_Bitcoin-241473.pdf","sj":"Re: Bitcoin","s":1,"to":"Nicholas Bohm","fe":"satoshin@gmx.com","od":"21/07/2009, 02:37 (UK time)"},{"f":"Nicholas Bohm","d":1248167400,"b":[["t","Satoshi Nakamoto wrote:"],["q","The transaction fee setting refers to the amount you give when you make\na transaction, not the amount you demand from transactions you process.\nWe're a long way from the point where nodes will need to require a fee,\nbut that can easily be implemented when needed."],["t","Thanks.\n\nI hope my misunderstandings prove a useful contribution to the eventual\n\"Bitcoin for Dummies\".\n\nRegards,\n\nNicholas\nNicholas Bohm wrote:"],["q","Satoshi Nakamoto wrote:\nI guess something must be preventing you from receiving incoming\nconnections. Mine has been trying to connect to your IP without\nsuccess. I'm currently connected to [IP address removed] since yesterday. If\nyou're not at least connected to that one, then you can't connect out\neither.\n\n\nI still had no connections, and couldn't see why not; but I stopped and\nrestarted bitcoin, and now have two connections. Although this is fewer\nthan for some weeks, and I have a clutch of \"not confirmed\" blocks when\nfor some weeks I had had none, at least it's up and running again.\nPrevious restarts made no difference, though.\n\nIncidentally, I set the optional transaction fee at 0.07. I expected\nthis to be visible as an outgoing (or as a deduction from blocks\ncreated), but so far I've seen nothing. Perhaps I've had no takers.\n\nRegards,\n\nNicholas"]],"u":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/71%2020090721-Re_Bitcoin-244408.pdf","su":"https://github.com/NicholasBohm/emails/blob/63fd31ced3cea6f4c8e262d3438d79d3e0480746/71%2020090721-Re_Bitcoin-244408.pdf","sj":"Re: Bitcoin","to":"satoshin@gmx.com","fe":"","od":"21/07/2009, 10:10 (UK time)"}],"id":"x122"},{"k":"p","s":"forum-staff","u":"https://bitcointalk.org/first_topics/1.pdf","su":"https://bitcointalk.org/first_topics/1.pdf","m":[{"f":"Simple Machines","d":1258481528,"b":[["t","Welcome to Simple Machines Forum!\nWe hope you enjoy using your forum. If you have any problems, please feel free to\nThanks!\nSimple Machines"]],"u":"https://bitcointalk.org/first_topics/1.pdf","sj":"Welcome to SMF!"},{"f":"admin","d":1258570272,"b":[["t","Test message"]],"u":"https://bitcointalk.org/first_topics/1.pdf","sj":"Re: Welcome to SMF!"},{"f":"satoshi","d":1258640586,"b":[["t","Another test message"]],"u":"https://bitcointalk.org/first_topics/1.pdf","sj":"Re: Welcome to SMF!","s":1}],"t":"Welcome to SMF!","id":"p261"},{"k":"p","s":"forum-staff","u":"https://bitcointalk.org/first_topics/2.pdf","su":"https://bitcointalk.org/first_topics/2.pdf","m":[{"f":"admin","d":1258574667,"b":[["t","Drupal & Simple Machines Forum"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Testing the new site platform"},{"f":"admin","d":1258588280,"b":[["t","Another test reply"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform"},{"f":"admin","d":1258588728,"b":[["t","now a longer post\naaaaaaaaaa aaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbb\nbbbbbbbbbbbbbbbbbbbbbbbbbbb\ncccccccccccc ccccccccccccc ccccccccccc dddddddddddddddddd eeeeeeeeeee\neeeeeeeeeeeeeeeeeeeeeeeeeeee fffffffffff fffffffff gggggggggggggg hhhhhhhhhhhh\nhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh iiiiiiiiiiiii jjjjjjjjjjjjjjjjjjj kkkkkkkkkkkkkkkk"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform"},{"f":"admin","d":1258588814,"b":[["t","Quote from: admin on November 18, 2009, 11:58:48 PM\nnow a longer post\naaaaaaaaaa aaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbb\ncccccccccccc ccccccccccccc ccccccccccc dddddddddddddddddd eeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeeeee\nfffffffffff fffffffff gggggggggggggg hhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh iiiiiiiiiiiii jjjjjjjjjjjjjjjjjjj\nkkkkkkkkkkkkkkkk\nSo there's what a quote box looks like"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform"},{"f":"admin","d":1258591304,"b":[["t","Quote from: admin on November 19, 2009, 12:00:14 AM\nQuote from: admin on November 18, 2009, 11:58:48 PM\nnow a longer post\naaaaaaaaaa aaaaaaaaaaaaaa bbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbb\ncccccccccccc ccccccccccccc ccccccccccc dddddddddddddddddd eeeeeeeeeee eeeeeeeeeeeeeeeeeeeeeeeeeeee\nfffffffffff fffffffff gggggggggggggg hhhhhhhhhhhh hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh iiiiiiiiiiiii jjjjjjjjjjjjjjjjjjj\nkkkkkkkkkkkkkkkk\nSo there's what a quote box looks like\nand quoting a quote..."]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform"},{"f":"admin","d":1258591651,"b":[["t","1: testing what a code block looks like\n2: line 2\n3: indented\n4: indented\n5: aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaa\naaaaaaaaa\nafter teletype block\nbefore code block\nCode:\n1: testing what a code block looks like\n2: line 2\n3: indented\n4: indented\n5: aaaaaaaaaaa aaaaaaaaaaa aaaaaaaaaaaaaa aaaaaaaaaaaaa aaaaaaaaaaaaaa aaaaaaaaa\nafter code block\nline of text before code block\nCode:\n0: line zero\n1: line 1\n2: and end\nline of text after code block\nEdit: Checking what an edited post looks like"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform"},{"f":"satoshi","d":1258807243,"b":[["t","I have to get the number of posts up over 20 so the topic will have multiple pages,\nso here goes with a bunch of blank posts."]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807380,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807426,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807493,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807532,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807572,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807602,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807641,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807776,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807796,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807868,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258807933,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258808046,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258808232,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1258808291,"b":[["t","blank"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1},{"f":"satoshi","d":1259155429,"b":[["t","Test"]],"u":"https://bitcointalk.org/first_topics/2.pdf","sj":"Re: Testing the new site platform","s":1}],"t":"Testing the new site platform","id":"p262"},{"k":"p","s":"forum-staff","u":"https://bitcointalk.org/first_topics/4.pdf","su":"https://bitcointalk.org/first_topics/4.pdf","m":[{"f":"satoshi","d":1258677444,"b":[["t","I left the admin account set to the original SMF theme so if I somehow completely\nwedge the custom theme I can still get in to fix it.\nI've got a neat little 12x12 coin image to replace those pip stars with. Should look\nnice. Also some nice button images to try.\nThe registration page has \"hide your e-mail address\" unchecked by default. I must\nfix that in php before we can open up.\nThe Announcements forum is currently moderator access only."]],"u":"https://bitcointalk.org/first_topics/4.pdf","sj":"SMF Config Notes","s":1},{"f":"satoshi","d":1258767763,"b":[["t","12x12 coin for pip stars done.\nRegistration page \"hide your e-mail address\" checked by default done, haven't tested\nit yet."]],"u":"https://bitcointalk.org/first_topics/4.pdf","sj":"Re: SMF Config Notes","s":1},{"f":"sirius","d":1261549628,"b":[["t","Changed the registration to require e-mail confirmation. The confirmation mail\ncontains the user-given password, this might need fixing."]],"u":"https://bitcointalk.org/first_topics/4.pdf","sj":"Re: SMF Config Notes"},{"f":"satoshi","d":1263483396,"b":[["t","Is there any reason to have e-mail confirmation?\nIf you're doing that out of spam concerns, I've already got that covered. I made\nsome customizations to the registration HTML so any spambots designed for SMF\nwon't be able to figure it out. The CAPTCHA image URL requires an extra parameter,\nand there are 3 different CAPTCHA images, but only one shows because the others\nhave stuff like width=0 height=0."]],"u":"https://bitcointalk.org/first_topics/4.pdf","sj":"Re: SMF Config Notes","s":1},{"f":"sirius","d":1263517147,"b":[["t","Yes, spam prevention was the purpose, but if there's no spam problem with\nimmediate registration, I'll turn the e-mail activation off."]],"u":"https://bitcointalk.org/first_topics/4.pdf","sj":"Re: SMF Config Notes"}],"t":"SMF Config Notes","id":"p263"}],"clips":[{"t":"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.","d":"2010-12-11","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/542/","st":"Re: PC World Article on Bitcoin"},{"t":"The project needs to grow gradually so the software can be strengthened along the way. I make this appeal to WikiLeaks not to try to use Bitcoin.  Bitcoin is a small beta community in its infancy.","d":"2010-12-05","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/523/","st":"Re: Wikileaks contact info?"},{"t":"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. It'll be a lot simpler if authors could make their graphics public domain.","d":"2010-11-13","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/500/","st":"Re: New icon/logo"},{"t":"I 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: \"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.","d":"2010-09-30","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/467/","st":"Re: BitCoin Wikipedia page DELETED!!!"},{"t":"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.","d":"2010-09-30","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/464/","st":"Re: I broke my wallet, sends never confirm now."},{"t":"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.","d":"2010-09-23","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/460/","st":"Re: Porn"},{"t":"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. We'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. I 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.","d":"2010-09-19","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/454/","st":"Re: Bug?  /usr/bin/bitcoind \"\""},{"t":"The 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.","d":"2010-09-08","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/441/","st":"Re: Always pay transaction fee?"},{"t":"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.","d":"2010-09-08","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/441/","st":"Re: Always pay transaction fee?"},{"t":"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. The threshold should probably be lower than it currently is. I don't think the threshold should ever be 0.  We should always allow at least some free transactions.","d":"2010-09-07","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/439/","st":"Re: Always pay transaction fee?"},{"t":"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\n\nand one special, magical property:\n- can be transported over a communications channel\n\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.\n\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.\n\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\n(I'm using the word scarce here to only mean limited potential supply)","d":"2010-08-27","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/428/","st":"Re: Bitcoin does NOT violate Mises' Regression Theorem"},{"t":"Bitcoins have no dividend or potential future dividend, therefore not like a stock.\n\nMore like a collectible or commodity.","d":"2010-08-27","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/427/","st":"Re: Bitcoins are most like shares of common stock"},{"t":"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.","d":"2010-08-16","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/394/","st":"Re: checkpointing the block chain"},{"t":"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\n\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.","d":"2010-08-15","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/364/","st":"Re: Potential disaster scenario"},{"t":"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.","d":"2010-08-11","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/340/","st":"Re: Escrow"},{"t":"It's hard to think of how to apply zero-knowledge-proofs in this case.","d":"2010-08-11","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/339/","st":"Re: Not a suggestion"},{"t":"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.","d":"2010-08-09","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/337/","st":"Re: Bitcoin minting is thermodynamically perverse"},{"t":"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.","d":"2010-08-07","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/327/","st":"Re: Bitcoin minting is thermodynamically perverse"},{"t":"Proof-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.","d":"2010-08-07","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/327/","st":"Re: Bitcoin minting is thermodynamically perverse"},{"t":"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.","d":"2010-08-05","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/318/","st":"Re: Flood attack 0.00000001 BC"},{"t":"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.","d":"2010-08-04","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/317/","st":"Re: Flood attack 0.00000001 BC"},{"t":"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.","d":"2010-07-29","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/294/","st":"Re: Implementation bug prior to 0.3.6"},{"t":"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.","d":"2010-07-29","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/287/","st":"Re: Scalability and transaction rate"},{"t":"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. http://www.bitcoin.org/Satoshi_Nakamoto.asc","d":"2010-07-25","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/276/","st":"Re: md5?"},{"t":"By making some adjustments to the database settings, I was able to make the initial block download about 5 times faster.  It downloads in about 30 minutes. \n \nThe database default had it writing each block to disk synchronously, which is not necessary.  I changed the settings to let it cache the changes in memory and write them out in a batch.  Blocks are still written transactionally, so either the complete change occurs or none of it does, in either case the data is left in a valid state. \n \nI only enabled this change during the initial block download.  When you come within 2000 blocks of the latest block, these changes turn off and it slows down to the old way.","d":"2010-07-23","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/258/","st":"Faster initial block download (5x faster)"},{"t":"The 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.","d":"2010-07-10","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/249/","st":"Re: They want to delete the Wikipedia article"},{"t":"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.","d":"2010-07-16","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/225/","st":"Re: Proof-of-work difficulty increasing"},{"t":"Difficulty just increased by 4 times, so now your cost is US$0.02/BTC.","d":"2010-07-16","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/223/","st":"Re: The dollar cost of bitmining energy"},{"t":"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.","d":"2010-07-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/","st":"Re: Scalability"},{"t":"I 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.","d":"2010-07-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/","st":"Re: Scalability"},{"t":"At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.","d":"2010-07-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/","st":"Re: Scalability"},{"t":"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.","d":"2010-07-09","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/174/","st":"Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)"},{"t":"Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server.  Escape the arbitrary inflation risk of centrally managed currencies!  Bitcoin's total circulation is limited to 21 million coins.  The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time.","d":"2010-07-06","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/168/","st":"Bitcoin 0.3 released!"},{"t":"Writing a description for this thing for general audiences is bloody hard.  There's nothing to relate it to.","d":"2010-07-05","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/167/","st":"Re: Slashdot Submission for 1.0"},{"t":"Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone.","d":"2010-06-21","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/131/","st":"Re: Dying bitcoins"},{"t":"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.\n\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.","d":"2010-06-18","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/129/","st":"Re: Get 5 free bitcoins from freebitcoins.appspot.com"},{"t":"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.\n\nFortunately, so far all the issues raised have been things I previously considered and planned for.","d":"2010-06-18","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/127/","st":"Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG"},{"t":"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.","d":"2010-06-17","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/","st":"Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG"},{"t":"The 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.","d":"2010-06-17","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/126/","st":"Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG"},{"t":"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.","d":"2010-06-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/119/","st":"Re: Dealing with SHA-256 Collisions"},{"t":"If 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.","d":"2010-06-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/119/","st":"Re: Dealing with SHA-256 Collisions"},{"t":"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.","d":"2010-05-26","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/111/","st":"Re: Website translations"},{"t":"Simplified 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.","d":"2010-05-18","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/105/","st":"Re: Ummmm... where did my bitcoins go?"},{"t":"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.","d":"2010-05-16","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/102/","st":"Re: removing bitcoin addresses"},{"t":"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.","d":"2010-05-16","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/98/","st":"Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add"},{"t":"The 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.","d":"2010-03-23","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/94/","st":"Re: who is bitcoin.com"},{"t":"How does everyone feel about the B symbol with the two lines through the outside?  Can we live with that as our logo?","d":"2010-02-26","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/83/","st":"Re: New icon/logo"},{"t":"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.","d":"2010-02-24","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/73/","st":"Re: URI-scheme for bitcoin"},{"t":"A 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.","d":"2010-02-21","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/65/","st":"Re: Current Bitcoin economic model is unsustainable"},{"t":"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.","d":"2010-02-21","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/65/","st":"Re: Current Bitcoin economic model is unsustainable"},{"t":"At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production.","d":"2010-02-21","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/65/","st":"Re: Current Bitcoin economic model is unsustainable"},{"t":"I'm sure that in 20 years there will either be very large transaction volume or no volume.","d":"2010-02-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/57/","st":"Re: What's with this odd generation?"},{"t":"In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes.","d":"2010-02-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/57/","st":"Re: What's with this odd generation?"},{"t":"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.","d":"2010-02-14","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/56/","st":"Re: What's with this odd generation?"},{"t":"Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge.\n\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.","d":"2010-02-06","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/46/","st":"Re: How divisible are bitcoins and other market/economic questions"},{"t":"If 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.","d":"2010-02-06","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/46/","st":"Re: How divisible are bitcoins and other market/economic questions"},{"t":"Bitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution.","d":"2010-02-06","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/45/","st":"Re: Repost: Request: Make this anonymous?"},{"t":"You could use TOR if you don't want anyone to know you're even using Bitcoin.","d":"2010-02-06","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/45/","st":"Re: Repost: Request: Make this anonymous?"},{"t":"I 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.","d":"2010-01-28","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/33/","st":"Re: A newb's test - anyone want to buy a picture for $1?"},{"t":"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.","d":"2009-12-12","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/20/","st":"Re: A few suggestions"},{"t":"We 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.","d":"2009-12-12","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/20/","st":"Re: A few suggestions"},{"t":"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.","d":"2009-12-10","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/17/","st":"Re: Questions about Bitcoin"},{"t":"Being 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.","d":"2009-12-10","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/17/","st":"Re: Questions about Bitcoin"},{"t":"For greater privacy, it's best to use bitcoin addresses only once.","d":"2009-11-25","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/11/","st":"Re: Repost: How anonymous are bitcoins?"},{"t":"Think 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.","d":"2009-11-22","u":"https://satoshi.nakamotoinstitute.org/posts/bitcointalk/8/","st":"Re: Repost: Bitcoin Maturation"},{"t":"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\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","d":"2009-02-18","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/3/","st":"Bitcoin open source implementation of P2P currency"},{"t":"You could say coins are issued by the majority. They are issued in a limited, predetermined amount.","d":"2009-02-18","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/3/","st":"Bitcoin open source implementation of P2P currency"},{"t":"To 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.","d":"2009-02-18","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/3/","st":"Bitcoin open source implementation of P2P currency"},{"t":"In 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.","d":"2009-02-18","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/3/","st":"Bitcoin open source implementation of P2P currency"},{"t":"A 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.","d":"2009-02-15","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/2/","st":"Bitcoin open source implementation of P2P currency"},{"t":"I've developed a new open source P2P e-cash system called Bitcoin. It's completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust. Give it a try, or take a look at the screenshots and design paper: \n\nDownload Bitcoin v0.1 at http://www.bitcoin.org","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"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, but the history of fiat currencies is full of breaches of that trust.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"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. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"A generation ago, multi-user time-sharing computer systems had a similar problem. 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 weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"With e-currency based on cryptographic proof, without the need to trust a third party middleman, money can be secure and transactions effortless.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"A digital coin contains the public key of its owner. To transfer it, the owner signs the coin together with the public key of the next owner. Anyone can check the signatures to verify the chain of ownership.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"Any owner could try to re-spend an already spent coin by signing it again to another owner. 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, and the fees needed to support the company make micropayments impractical. \nBitcoin's solution is to use a peer-to-peer network to check for double-spending. In a nutshell, 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.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"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.","d":"2009-02-11","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/1/","st":"Bitcoin open source implementation of P2P currency"},{"t":"I am not Dorian Nakamoto.","d":"2014-03-07","u":"https://satoshi.nakamotoinstitute.org/posts/p2pfoundation/4/","st":"Bitcoin open source implementation of P2P currency"},{"t":"I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.","d":"2008-11-01","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/1/","st":"Bitcoin P2P e-cash paper"},{"t":"The main properties: \n Double-spending is prevented with a peer-to-peer network.\n No mint or other trusted parties.\n Participants can be anonymous.\n New coins are made from Hashcash style proof-of-work.\n The proof-of-work for new coin generation also powers the network to prevent double-spending.","d":"2008-11-01","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/1/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-02","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/2/","st":"Bitcoin P2P e-cash paper"},{"t":"Only people trying to create new coins would need to run network nodes.","d":"2008-11-02","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/2/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-02","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/2/","st":"Bitcoin P2P e-cash paper"},{"t":"The requirement is that the good guys collectively have more CPU power than any single attacker.","d":"2008-11-03","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/3/","st":"Bitcoin P2P e-cash paper"},{"t":"There 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.","d":"2008-11-03","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/3/","st":"Bitcoin P2P e-cash paper"},{"t":"Even 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.","d":"2008-11-03","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/3/","st":"Bitcoin P2P e-cash paper"},{"t":"The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.","d":"2008-11-03","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/3/","st":"Bitcoin P2P e-cash paper"},{"t":"Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.","d":"2008-11-07","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/4/","st":"Bitcoin P2P e-cash paper"},{"t":"Governments 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.","d":"2008-11-07","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/4/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-08","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/5/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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. Coins have to get initially distributed somehow, and a constant rate seems like the best formula.","d":"2008-11-08","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/5/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"Receivers 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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"It 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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/6/","st":"Bitcoin P2P e-cash paper"},{"t":"It's not a problem if transactions have to wait one or a few extra cycles to get into a block.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/7/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/8/","st":"Bitcoin P2P e-cash paper"},{"t":"A 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. If 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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/8/","st":"Bitcoin P2P e-cash paper"},{"t":"When 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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/8/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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.","d":"2008-11-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/8/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-10","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/9/","st":"Bitcoin P2P e-cash paper"},{"t":"When there are multiple double-spent versions of the same transaction, one and only one will become valid.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"The target time between blocks will probably be 10 minutes. Every 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.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.","d":"2008-11-11","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/10/","st":"Bitcoin P2P e-cash paper"},{"t":"The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.\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 They 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. They 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 After 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 The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.","d":"2008-11-13","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/11/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-14","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/12/","st":"Bitcoin P2P e-cash paper"},{"t":"It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.","d":"2008-11-13","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/12/","st":"Bitcoin P2P e-cash paper"},{"t":"I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"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 Same 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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"We'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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"There 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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/13/","st":"Bitcoin P2P e-cash paper"},{"t":"The credential that establishes someone as real is the ability to supply CPU power.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/14/","st":"Bitcoin P2P e-cash paper"},{"t":"The 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. During 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 If 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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/14/","st":"Bitcoin P2P e-cash paper"},{"t":"If 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.","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/14/","st":"Bitcoin P2P e-cash paper"},{"t":"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. The functional details are not covered in the paper, but the sourcecode is coming soon. I sent you the main files. (available by request at the moment, full release soon)","d":"2008-11-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/15/","st":"Bitcoin P2P e-cash paper"},{"t":"Announcing the first release of Bitcoin, a new electronic cash system that uses a peer-to-peer network to prevent double-spending. It's completely decentralized with no server or central authority.","d":"2009-01-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","st":"Bitcoin v0.1 released"},{"t":"If you can keep a node running that accepts incoming connections, you'll really be helping the network a lot. Port 8333 on your firewall needs to be open to receive incoming connections.","d":"2009-01-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","st":"Bitcoin v0.1 released"},{"t":"You can get coins by getting someone to send you some, or turn on Options->Generate Coins to run a node and generate blocks. I made the proof-of-work difficulty ridiculously easy to start with, so for a little while in the beginning a typical PC will be able to generate coins in just a few hours. It'll get a lot harder when competition makes the automatic adjustment drive up the difficulty. Generated coins must wait 120 blocks to mature before they can be spent.","d":"2009-01-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","st":"Bitcoin v0.1 released"},{"t":"There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections.","d":"2009-01-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","st":"Bitcoin v0.1 released"},{"t":"Total circulation will be 21,000,000 coins. It'll be distributed to network nodes when they make blocks, with the amount cut in half every 4 years.\n\nfirst 4 years: 10,500,000 coins\nnext 4 years: 5,250,000 coins\nnext 4 years: 2,625,000 coins\nnext 4 years: 1,312,500 coins\netc...\n\nWhen that runs out, the system can support transaction fees if needed. It's based on open market competition, and there will probably always be nodes willing to process transactions for free.","d":"2009-01-09","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/16/","st":"Bitcoin v0.1 released"},{"t":"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.","d":"2009-01-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/17/","st":"Bitcoin v0.1 released"},{"t":"It 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. It'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.\"","d":"2009-01-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/17/","st":"Bitcoin v0.1 released"},{"t":"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.","d":"2009-01-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/17/","st":"Bitcoin v0.1 released"},{"t":"It 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.","d":"2009-01-17","u":"https://satoshi.nakamotoinstitute.org/emails/cryptography/17/","st":"Bitcoin v0.1 released"},{"t":"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"We propose a solution to the double-spending problem using a peer-to-peer network. 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. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services. With the possibility of reversal, the need for trust spreads.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash, rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"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.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The steps to run the network are as follows:\n\n1. New transactions are broadcast to all nodes.\n2. Each node collects new transactions into a block.\n3. Each node works on finding a difficult proof-of-work for its block.\n4. When a node finds a proof-of-work, it broadcasts the block to all nodes.\n5. Nodes accept the block only if all transactions in it are valid and not already spent.\n6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree, with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. \nAs such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the \"tape\", is made public, but without telling who the parties were.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"},{"t":"The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.","d":"2008-10-31","u":"https://nakamotoinstitute.org/library/bitcoin/","st":"Bitcoin whitepaper"}],"meta":{"commit":"35fca11","commitDate":"2026-10-13","words":76422,"coreCommit":"06edf05","coreDate":"2026-10-20"},"cats":[{"slug":"bitcoin-design","name":"Bitcoin Design","n":27},{"slug":"nodes","name":"Nodes","n":21},{"slug":"bitcoin-economics","name":"Bitcoin Economics","n":20},{"slug":"mining","name":"Mining","n":19},{"slug":"transactions","name":"Transactions","n":19},{"slug":"proof-of-work","name":"Proof-of-Work","n":18},{"slug":"double-spending","name":"Double Spending","n":12},{"slug":"general","name":"General","n":9},{"slug":"privacy","name":"Privacy","n":7},{"slug":"cryptocurrency","name":"Cryptocurrency","n":6},{"slug":"economics","name":"Economics","n":6},{"slug":"fees","name":"Fees","n":6},{"slug":"micropayments","name":"Micropayments","n":6},{"slug":"releases","name":"Releases","n":6},{"slug":"trusted-third-parties","name":"Trusted Third Parties","n":6},{"slug":"difficulty","name":"Difficulty","n":5},{"slug":"encryption","name":"Encryption","n":3},{"slug":"scalability","name":"Scalability","n":3},{"slug":"motives","name":"Motives","n":2},{"slug":"addresses","name":"Addresses","n":1},{"slug":"banks","name":"Banks","n":1},{"slug":"government","name":"Government","n":1},{"slug":"identity","name":"Identity","n":1},{"slug":"p2p-networks","name":"P2P Networks","n":1},{"slug":"zero-knowledge","name":"Zero-Knowledge Proofs","n":1}],"commits":[{"id":"c99cef996c7","sha":"99cef996c788755af95a0a614d7154a30928d4b9","d":1256087285,"s":"flush wallet.dat, multi-proc, reorg options, revert to startup folder shortcut","r":15,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":20,"ins":1968,"del":1373,"u":"https://github.com/bitcoin/bitcoin/commit/99cef996c788755af95a0a614d7154a30928d4b9","f":[["build.txt",87,0,null,0,0],["db.cpp",45,12,null,0,0],["db.h",2,1,null,0,0],["headers.h",4,2,null,0,0],["irc.cpp",6,8,null,0,0],["key.h",12,0,null,0,0],["main.cpp",113,39,null,35,0],["main.h",10,4,null,0,0],["makefile",2,2,null,0,0],["makefile.vc",2,2,null,0,0],["net.cpp",57,54,null,0,0],["net.h",8,9,null,0,0],["readme.txt",0,76,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",390,273,null,682,0],["ui.h",54,54,null,21,0],["uibase.cpp",141,92,null,298,0],["uibase.h",87,106,null,244,0],["uiproject.fbp",945,636,null,1682,0],["util.cpp",2,2,null,18,0]]},{"id":"cfa2a0338d3","sha":"fa2a0338d3f8b1c3a1d75bff39ff42e436cee0dc","d":1256445301,"s":"fix display of new generated coins, fix assertion in bitcoinminer","r":17,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":75,"del":28,"u":"https://github.com/bitcoin/bitcoin/commit/fa2a0338d3f8b1c3a1d75bff39ff42e436cee0dc","f":[["main.cpp",22,23,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",51,4,null,0,0],["ui.h",1,0,null,0,0]]},{"id":"cdd519206a6","sha":"dd519206a684c772a4a06ceecc87c665ad09d8be","d":1256784768,"s":"addr relaying fixes, proxy option and privacy patches, detect connect to self, non-final tx locktime changes, fix hide unconfirmed generated","r":18,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":19,"ins":1209,"del":339,"u":"https://github.com/bitcoin/bitcoin/commit/dd519206a684c772a4a06ceecc87c665ad09d8be","f":[["build.txt",6,6,null,0,0],["db.cpp",13,6,null,0,0],["headers.h",2,0,null,0,0],["irc.cpp",7,3,null,0,0],["key.h",1,1,null,0,0],["main.cpp",57,14,null,0,0],["main.h",12,4,null,0,0],["makefile",2,2,null,0,0],["net.cpp",102,71,null,101,0],["net.h",125,6,null,0,0],["serialize.h",1,1,null,0,0],["strlcpy.h",84,0,null,0,0],["ui.cpp",176,47,null,168,0],["ui.h",6,2,null,0,0],["uibase.cpp",45,6,null,0,0],["uibase.h",54,44,null,93,0],["uiproject.fbp",302,6,null,357,0],["util.cpp",119,51,null,229,0],["util.h",95,69,null,208,0]]},{"id":"cdc73b326f9","sha":"dc73b326f97f2ed7ec7b7e8485ebc9eb46e05ddb","d":1256795756,"s":"CCriticalSection using wxWidgets instead of Windows OS calls","r":19,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":35,"del":22,"u":"https://github.com/bitcoin/bitcoin/commit/dc73b326f97f2ed7ec7b7e8485ebc9eb46e05ddb","f":[["net.h",3,3,null,0,0],["util.cpp",12,8,null,0,0],["util.h",20,11,null,0,0]]},{"id":"ce8474beb6f","sha":"e8474beb6f2c5e2654f8ebc671b3dbf5fae78563","d":1256847046,"s":"better wallet.dat flush, consolidated QueryPerformanceCounter, PRI64d printf portability","r":20,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":10,"ins":121,"del":75,"u":"https://github.com/bitcoin/bitcoin/commit/e8474beb6f2c5e2654f8ebc671b3dbf5fae78563","f":[["build.txt",2,1,null,0,0],["db.cpp",53,23,null,0,0],["db.h",11,1,null,0,0],["main.cpp",2,4,null,0,0],["main.h",1,1,null,0,0],["makefile.vc",2,2,null,0,0],["net.h",1,1,null,0,0],["ui.cpp",13,13,null,0,0],["util.cpp",10,12,null,0,0],["util.h",26,17,null,0,0]]},{"id":"c32d490313b","sha":"32d490313b21d5cea64f99ca9db4388591bb3ab9","d":1256864225,"s":"make CheckDiskSpace portable","r":22,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":4,"del":10,"u":"https://github.com/bitcoin/bitcoin/commit/32d490313b21d5cea64f99ca9db4388591bb3ab9","f":[["main.cpp",4,10,null,0,0]]},{"id":"c4ac57f013e","sha":"4ac57f013e20da2d0f87fff69625cbd4419089f3","d":1257038211,"s":"move debug.log and db.log to data dir, portable GetDataDir, optimize GetBalance, fix repaint bogdown, -addnode and -? switches","r":25,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":12,"ins":416,"del":382,"u":"https://github.com/bitcoin/bitcoin/commit/4ac57f013e20da2d0f87fff69625cbd4419089f3","f":[["build.txt",1,1,null,0,0],["db.cpp",11,8,null,0,0],["irc.cpp",4,3,null,0,0],["irc.h",0,5,null,0,0],["main.cpp",7,43,null,0,0],["main.h",14,6,null,0,0],["net.cpp",27,7,null,0,0],["net.h",47,31,null,0,0],["ui.cpp",201,256,null,371,0],["ui.h",2,3,null,0,0],["util.cpp",73,9,null,0,0],["util.h",29,10,null,0,0]]},{"id":"cb7362c07ae","sha":"b7362c07ae42ac4282361ee95b82424d502f1b82","d":1257310726,"s":"renamed build.txt to build-msw.txt","r":28,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":91,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/b7362c07ae42ac4282361ee95b82424d502f1b82","f":[["build-msw.txt",91,0,null,0,0]]},{"id":"ce4c05d3177","sha":"e4c05d31778a85014b2a52e2f20753b38dfbf950","d":1257396096,"s":"unix build merged in, bitmap resources from xpm instead of rc, better addr relay, better selection of addrs by time last seen for faster connect","r":32,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":23,"ins":2184,"del":301,"u":"https://github.com/bitcoin/bitcoin/commit/e4c05d31778a85014b2a52e2f20753b38dfbf950","f":[["build-unix.txt",73,0,null,0,0],["build.txt",0,88,null,0,0],["db.cpp",3,7,null,0,0],["headers.h",27,11,null,0,0],["irc.cpp",2,14,null,0,0],["irc.h",1,3,null,0,0],["main.cpp",44,24,null,0,0],["main.h",8,0,null,0,0],["makefile.unix",86,0,null,0,0],["net.cpp",89,88,null,28,0],["net.h",2,1,null,0,0],["ui.cpp",58,45,null,0,0],["uibase.cpp",7,3,null,0,0],["uiproject.fbp",5,5,null,0,0],["util.cpp",7,1,null,0,0],["util.h",29,11,null,0,0],["xpm/addressbook16.xpm",278,0,null,92,0],["xpm/addressbook20.xpm",282,0,null,283,0],["xpm/bitcoin.xpm",304,0,null,305,0],["xpm/check.xpm",41,0,null,42,0],["xpm/send16.xpm",278,0,null,279,0],["xpm/send16noshadow.xpm",278,0,null,279,0],["xpm/send20.xpm",282,0,null,283,0]]},{"id":"c300d4608f2","sha":"300d4608f2504e3e4a02a13b6c6000b52c436975","d":1257486605,"s":"got rid of CheckForShutdown, replaced some thread-unsafe wxWidgets calls, Linux fixes, socket send MSG_NOSIGNAL, bind INADDR_ANY, works reliably on Linux now except if wxMessageBox is used in a thread other than the GUI thread","r":33,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":12,"ins":260,"del":235,"u":"https://github.com/bitcoin/bitcoin/commit/300d4608f2504e3e4a02a13b6c6000b52c436975","f":[["db.cpp",1,1,null,0,0],["irc.cpp",6,3,null,0,0],["main.cpp",40,27,null,0,0],["main.h",1,1,null,0,0],["net.cpp",102,91,null,86,0],["net.h",1,1,null,0,0],["ui.cpp",51,12,null,0,0],["ui.h",2,1,null,0,0],["uibase.cpp",5,55,null,0,0],["uiproject.fbp",34,34,null,6,0],["util.cpp",4,8,null,0,0],["util.h",13,1,null,0,0]]},{"id":"c8acda009d9","sha":"8acda009d921a65dab87bd0a40f63981a1586561","d":1257533606,"s":"UIThreadCall, ThreadSafeMessageBox","r":34,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":7,"ins":44,"del":1284,"u":"https://github.com/bitcoin/bitcoin/commit/8acda009d921a65dab87bd0a40f63981a1586561","f":[["headers.h",2,0,null,0,0],["main.cpp",1,1,null,0,0],["ui.cpp",36,32,null,0,0],["ui.h",4,18,null,0,0],["uibase.cpp",0,160,null,0,0],["uibase.h",1,81,null,0,0],["uiproject.fbp",0,992,null,699,0]]},{"id":"c8b4cefd324","sha":"8b4cefd3245c349cad14baaf2ba42380dcc88112","d":1257570303,"s":"UI tweaks, use BindListenPort to detect instance already running, setsockopt(SO_REUSEADDR) so can bind during TIME_WAIT after exit and restart","r":35,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":11,"ins":346,"del":284,"u":"https://github.com/bitcoin/bitcoin/commit/8b4cefd3245c349cad14baaf2ba42380dcc88112","f":[["db.cpp",1,1,null,0,0],["main.cpp",4,4,null,0,0],["main.h",0,1,null,0,0],["net.cpp",51,47,null,0,0],["net.h",4,2,null,0,0],["ui.cpp",76,46,null,0,0],["ui.h",1,1,null,0,0],["uibase.cpp",48,43,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",149,138,null,272,0],["util.cpp",11,0,null,0,0]]},{"id":"cb4e235f9f2","sha":"b4e235f9f23b492539eeeddbbd1e7a7ef1b6793e","d":1257619901,"s":"ui tweaks, multiple xpm icon sizes","r":36,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":948,"del":313,"u":"https://github.com/bitcoin/bitcoin/commit/b4e235f9f23b492539eeeddbbd1e7a7ef1b6793e","f":[["headers.h",4,1,null,0,0],["net.cpp",2,2,null,0,0],["ui.cpp",12,6,null,0,0],["xpm/bitcoin.xpm",0,304,null,5,0],["xpm/bitcoin16.xpm",203,0,null,0,0],["xpm/bitcoin20.xpm",226,0,null,0,0],["xpm/bitcoin32.xpm",223,0,null,0,0],["xpm/bitcoin48.xpm",278,0,null,0,0]]},{"id":"c956468c29a","sha":"956468c29adcbff83ab7c2e52d91f8e87b704853","d":1257654292,"s":"Get local host IP on Linux, Shutdown() a little cleaner -- linux-0.1.6-test1 waypoint","r":37,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":78,"del":22,"u":"https://github.com/bitcoin/bitcoin/commit/956468c29adcbff83ab7c2e52d91f8e87b704853","f":[["headers.h",2,0,null,0,0],["main.cpp",2,2,null,0,0],["makefile.unix",13,10,null,0,0],["net.cpp",49,9,null,0,0],["ui.cpp",12,1,null,0,0]]},{"id":"c70e79525c9","sha":"70e79525c97c33a5fca8674d47d86cc2b7ae197a","d":1258075388,"s":"monitor ThreadSocketHandler and terminate and restart if hung, convert _beginthread to CreateThread wrapper, disconnect inactive connections, ping, break up long messages to speed up initial download, better priorities for initiating connections, track how many nodes have requested our blocks and transactions, status #/offline and warning message on unsent blocks, minimize on close as separate option -- linux-test5","r":38,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":16,"ins":684,"del":391,"u":"https://github.com/bitcoin/bitcoin/commit/70e79525c97c33a5fca8674d47d86cc2b7ae197a","f":[["build-msw.txt",1,1,null,0,0],["build-unix.txt",1,0,null,0,0],["db.cpp",8,1,null,0,0],["headers.h",0,1,null,0,0],["irc.cpp",3,2,null,0,0],["main.cpp",120,24,null,48,0],["main.h",14,11,null,0,0],["net.cpp",220,122,null,304,0],["net.h",15,10,null,0,0],["ui.cpp",90,47,null,21,0],["ui.h",1,1,null,0,0],["uibase.cpp",4,12,null,0,0],["uibase.h",46,46,null,0,0],["uiproject.fbp",50,71,null,0,0],["util.cpp",23,25,null,27,0],["util.h",88,17,null,137,0]]},{"id":"cb349e3dca8","sha":"b349e3dca89dfff5fe70669f9fd3f3a1ec60a498","d":1258221848,"s":"misc compile error","r":39,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/b349e3dca89dfff5fe70669f9fd3f3a1ec60a498","f":[["net.h",1,1,null,0,0]]},{"id":"cc5c7911dab","sha":"c5c7911dab8732861affbe66849a100da62f7464","d":1258571981,"s":"bugfix Db::open/close and zombie sockets bugs fix double-close of socket handle, keep databases open, close db cursors, initial block download in batches of 500 blocks, fix misc warnings, subver linux-test8","r":40,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":23,"ins":304,"del":184,"u":"https://github.com/bitcoin/bitcoin/commit/c5c7911dab8732861affbe66849a100da62f7464","f":[["build-unix.txt",5,11,null,0,0],["db.cpp",89,41,null,0,0],["db.h",11,6,null,0,0],["irc.cpp",9,5,null,0,0],["main.cpp",56,31,null,0,0],["main.h",5,5,null,0,0],["makefile.unix",2,5,null,0,0],["net.cpp",64,46,null,0,0],["net.h",11,5,null,0,0],["serialize.h",1,0,null,0,0],["ui.cpp",14,13,null,0,0],["util.cpp",6,4,null,0,0],["util.h",21,2,null,0,0],["xpm/addressbook16.xpm",1,1,null,0,0],["xpm/addressbook20.xpm",1,1,null,0,0],["xpm/bitcoin16.xpm",1,1,null,0,0],["xpm/bitcoin20.xpm",1,1,null,0,0],["xpm/bitcoin32.xpm",1,1,null,0,0],["xpm/bitcoin48.xpm",1,1,null,0,0],["xpm/check.xpm",1,1,null,0,0],["xpm/send16.xpm",1,1,null,0,0],["xpm/send16noshadow.xpm",1,1,null,0,0],["xpm/send20.xpm",1,1,null,0,0]]},{"id":"c52f4cb4859","sha":"52f4cb48590a706caf7a492e8d94b85620d5cd33","d":1259096690,"s":"minor fix to batched initial download in case requester has more than 500 block non-main branch","r":41,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":24,"del":3,"u":"https://github.com/bitcoin/bitcoin/commit/52f4cb48590a706caf7a492e8d94b85620d5cd33","f":[["main.cpp",2,2,null,0,0],["main.h",21,0,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c107d9e288d","sha":"107d9e288df8207e83f4273a8dcd631412f89889","d":1260059349,"s":"fix transaction fee bug in CreateTransaction, higher size cutoff for free transactions in GetMinFee","r":42,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":17,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/107d9e288df8207e83f4273a8dcd631412f89889","f":[["main.cpp",8,10,null,0,0],["main.h",8,3,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cb075bbf986","sha":"b075bbf9862df41cdf5265026ba787b7d0fecb07","d":1260059891,"s":"misc","r":43,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":5,"del":9,"u":"https://github.com/bitcoin/bitcoin/commit/b075bbf9862df41cdf5265026ba787b7d0fecb07","f":[["main.cpp",5,9,null,0,0]]},{"id":"c4ea3f3da1a","sha":"4ea3f3da1a0c00ea74e85c31a22ea94d18bbdf06","d":1260550161,"s":"retry IRC if name in use, resize to fit ubuntu's giant default font, scroll debug.log, pause gen during initial block download","r":44,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":13,"ins":187,"del":89,"u":"https://github.com/bitcoin/bitcoin/commit/4ea3f3da1a0c00ea74e85c31a22ea94d18bbdf06","f":[["build-msw.txt",3,3,null,0,0],["build-unix.txt",6,7,null,0,0],["db.cpp",18,3,null,0,0],["irc.cpp",16,7,null,0,0],["main.cpp",17,4,null,0,0],["makefile",12,14,null,0,0],["makefile.unix",19,16,null,0,0],["net.cpp",24,1,null,0,0],["net.h",0,1,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",37,9,null,0,0],["util.cpp",32,23,null,0,0],["util.h",2,0,null,0,0]]},{"id":"c651d335569","sha":"651d33556982d038d39f04373b9f63913bf03187","d":1260551991,"s":"misc","r":45,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/651d33556982d038d39f04373b9f63913bf03187","f":[["db.cpp",1,0,null,0,0]]},{"id":"ce39bc50eb4","sha":"e39bc50eb4dd4f0a34ee4c264af83043f13543dd","d":1260663196,"s":"misc exit code, updated setup.nsi","r":46,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":43,"del":15,"u":"https://github.com/bitcoin/bitcoin/commit/e39bc50eb4dd4f0a34ee4c264af83043f13543dd","f":[["db.cpp",1,0,null,0,0],["net.cpp",8,3,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",16,8,null,0,0],["ui.cpp",16,2,null,0,0]]},{"id":"ce899779450","sha":"e899779450bcd940dcdb0108d27c35eae92cc1e1","d":1260670423,"s":"restrict file permissions on linux to the user only","r":47,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":2,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/e899779450bcd940dcdb0108d27c35eae92cc1e1","f":[["db.cpp",1,1,null,0,0],["ui.cpp",1,0,null,0,0]]},{"id":"cadb50ffe32","sha":"adb50ffe32c5c37c84ff35d94bb486004e14a7cc","d":1260671685,"s":"misc","r":48,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":4,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/adb50ffe32c5c37c84ff35d94bb486004e14a7cc","f":[["util.h",4,0,null,0,0]]},{"id":"ce2c2648c14","sha":"e2c2648c14f4b87d331dbc30f0f2bd4aab9ce7e6","d":1260756721,"s":"filter out duplicate getblocks and don't relay inv messages during initial block download -- 0.2 rc2","r":49,"rel":"v0.2.0","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":38,"del":19,"u":"https://github.com/bitcoin/bitcoin/commit/e2c2648c14f4b87d331dbc30f0f2bd4aab9ce7e6","f":[["main.cpp",10,15,null,0,0],["net.cpp",19,2,null,0,0],["net.h",7,0,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",1,1,null,0,0]]},{"id":"c312c2c42b6","sha":"312c2c42b6d38dc7bfeef849722c8e231c38e8e4","d":1261073750,"s":"a few header changes for freebsd from madhatter","r":51,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":5,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/312c2c42b6d38dc7bfeef849722c8e231c38e8e4","f":[["headers.h",5,2,null,0,0]]},{"id":"c9a36562347","sha":"9a36562347122482fd1e6e77c74df66ad8cf2c3f","d":1261091787,"s":"command line switch -noui","r":52,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":15,"del":19,"u":"https://github.com/bitcoin/bitcoin/commit/9a36562347122482fd1e6e77c74df66ad8cf2c3f","f":[["ui.cpp",15,19,null,0,0]]},{"id":"ccb0f89646f","sha":"cb0f89646f065800d38d7cfc10ba1e855563296a","d":1264638660,"s":"simplify AddAddress, readcompactsize limit, fixed a 64-bit compile error in serialize.h, change status \"# blocks\" to \"# confirmations\" and widen the column.","r":53,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":11,"ins":129,"del":117,"u":"https://github.com/bitcoin/bitcoin/commit/cb0f89646f065800d38d7cfc10ba1e855563296a","f":[["db.cpp",1,3,null,0,0],["irc.cpp",1,2,null,0,0],["main.cpp",6,2,null,0,0],["net.cpp",5,5,null,0,0],["net.h",2,2,null,0,0],["serialize.h",10,6,null,0,0],["ui.cpp",13,4,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",2,2,null,0,0],["util.cpp",76,1,null,0,0],["util.h",12,89,null,0,0]]},{"id":"c8be979d9ae","sha":"8be979d9aef606f2a196a2addcf80473d571185b","d":1264715360,"s":"now compiles on 64-bit Ubuntu Karmic with wxWidgets-2.9.0, fixes for wxWidgets-2.9.0, added superfluous GetEventHandler()'s, there's still a bug on wx2.9.0 that the status number is mashed up for some reason otherwise seems to run fine","r":54,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":242,"del":130,"u":"https://github.com/bitcoin/bitcoin/commit/8be979d9aef606f2a196a2addcf80473d571185b","f":[["build-unix.txt",16,9,null,0,0],["makefile.unix",0,89,null,0,0],["makefile.unix.wx2.8",89,0,null,0,0],["makefile.unix.wx2.9",89,0,null,0,0],["ui.cpp",31,23,null,0,0],["uibase.cpp",5,1,null,0,0],["uibase.h",5,1,null,0,0],["uiproject.fbp",7,7,null,0,0]]},{"id":"c53d508072b","sha":"53d508072b02d522371bde148dcc3e925f472be7","d":1265237920,"s":"update fSpent flag on wallet transactions if they're seen spent in case copy of wallet.dat was used elsewhere or restored from backup, better error dialog box if try to spend already spent coins, got rid of unused notebook with only one tab on main dialog, nicer looking About dialog, resize About dialog better on linux","r":55,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":12,"ins":1275,"del":1163,"u":"https://github.com/bitcoin/bitcoin/commit/53d508072b02d522371bde148dcc3e925f472be7","f":[["db.cpp",8,5,null,0,0],["headers.h",2,1,null,0,0],["main.cpp",60,7,null,0,0],["main.h",27,1,null,0,0],["script.cpp",10,2,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",25,21,null,0,0],["ui.h",2,2,null,0,0],["uibase.cpp",25,99,null,0,0],["uibase.h",4,19,null,0,0],["uiproject.fbp",445,1004,null,1436,0],["xpm/about.xpm",665,0,null,366,0]]},{"id":"cc41226d847","sha":"c41226d847c7d32ade7f02c0d53c85b0800fc71b","d":1265830384,"s":"revert revision 56, going in different direction with boost::asio and JSON-RPC","r":57,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":7,"ins":8,"del":101,"u":"https://github.com/bitcoin/bitcoin/commit/c41226d847c7d32ade7f02c0d53c85b0800fc71b","f":[["headers.h",0,3,null,0,0],["ipc.cpp",0,33,null,0,0],["ipc.h",0,28,null,0,0],["makefile",1,3,null,0,0],["makefile.unix.wx2.8",2,3,null,0,0],["makefile.unix.wx2.9",3,4,null,0,0],["ui.cpp",2,27,null,0,0]]},{"id":"c75990a46a7","sha":"75990a46a7e4999729ff67c4268c2241c98e486f","d":1265830882,"s":"JSON Spirit library from http://www.codeproject.com/KB/recipes/JSON_Spirit.aspx, MIT license","r":58,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":13,"ins":1968,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/75990a46a7e4999729ff67c4268c2241c98e486f","f":[["json/LICENSE.txt",24,0,null,0,0],["json/json_spirit.h",18,0,null,0,0],["json/json_spirit_error_position.h",54,0,null,0,0],["json/json_spirit_reader.cpp",137,0,null,0,0],["json/json_spirit_reader.h",62,0,null,0,0],["json/json_spirit_reader_template.h",612,0,null,313,0],["json/json_spirit_stream_reader.h",70,0,null,0,0],["json/json_spirit_utils.h",61,0,null,0,0],["json/json_spirit_value.cpp",8,0,null,0,0],["json/json_spirit_value.h",532,0,null,233,0],["json/json_spirit_writer.cpp",95,0,null,0,0],["json/json_spirit_writer.h",50,0,null,0,0],["json/json_spirit_writer_template.h",245,0,null,0,0]]},{"id":"cfa9dbd6b62","sha":"fa9dbd6b62ab161c29c9b8cf97b9c8da8ef4346e","d":1265831164,"s":"better error message in check_type(), tell the types by name instead of by number","r":59,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":3,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/fa9dbd6b62ab161c29c9b8cf97b9c8da8ef4346e","f":[["json/json_spirit_value.h",3,1,null,0,0]]},{"id":"c98500d70a8","sha":"98500d70a8cf25af4bab80526fd128ccdc36ceeb","d":1266007124,"s":"command line and JSON-RPC first draft, requires Boost 1.35 or higher for boost::asio, added SetBitcoinAddress and GetBitcoinAddress methods on CScript, critsect interlocks around mapAddressBook, added some random delays in tx broadcast to improve privacy, now compiles with MSVC 8.0","r":60,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":23,"ins":1186,"del":332,"u":"https://github.com/bitcoin/bitcoin/commit/98500d70a8cf25af4bab80526fd128ccdc36ceeb","f":[["bignum.h",32,1,null,0,0],["build-msw.txt",22,5,null,0,0],["db.h",6,4,null,0,0],["headers.h",5,4,null,0,0],["irc.cpp",1,1,null,0,0],["irc.h",3,3,null,0,0],["license.txt",1,1,null,0,0],["main.cpp",105,46,null,23,0],["main.h",6,3,null,0,0],["makefile",15,10,null,0,0],["makefile.unix.wx2.8",11,9,null,0,0],["makefile.unix.wx2.9",11,9,null,0,0],["makefile.vc",15,10,null,0,0],["net.cpp",5,10,null,0,0],["net.h",2,1,null,0,0],["rpc.cpp",641,0,null,342,0],["rpc.h",6,0,null,0,0],["script.cpp",4,5,null,0,0],["script.h",42,2,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",233,203,null,435,0],["util.cpp",2,1,null,14,0],["util.h",16,2,null,58,0]]},{"id":"cc85dfb148a","sha":"c85dfb148a1e3d75773bc5f6b7cad14363fd666b","d":1266026947,"s":"updated build-unix.txt","r":61,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":6,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/c85dfb148a1e3d75773bc5f6b7cad14363fd666b","f":[["build-unix.txt",6,2,null,0,0]]},{"id":"cc4319e678f","sha":"c4319e678f693d5fbc49bd357ded1c8f951476e9","d":1266106107,"s":"Workaround for bug on wxWidgets 2.9.0 Ubuntu 9.10 64-bit where first character of the hidden columns were displayed so status column had three numbers overprinted.  Fixed by adding a leading space to the hidden columns.  64-bit compile with wxWidgets 2.9.0 seems to be fully working normally now.","r":62,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":30,"del":47,"u":"https://github.com/bitcoin/bitcoin/commit/c4319e678f693d5fbc49bd357ded1c8f951476e9","f":[["bignum.h",2,6,null,0,0],["main.cpp",5,6,null,0,0],["net.cpp",1,1,null,0,0],["rpc.cpp",1,1,null,0,0],["ui.cpp",12,28,null,0,0],["uint256.h",9,5,null,0,0]]},{"id":"c64a474a49b","sha":"64a474a49b20a66453fbcd2382e4b042427b0a0f","d":1266186433,"s":"renamed a few rpc methods","r":63,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":16,"del":19,"u":"https://github.com/bitcoin/bitcoin/commit/64a474a49b20a66453fbcd2382e4b042427b0a0f","f":[["makefile.vc",1,1,null,0,0],["net.cpp",0,4,null,0,0],["rpc.cpp",13,13,null,0,0],["serialize.h",1,1,null,0,0],["util.h",1,0,null,0,0]]},{"id":"c5253d1ab77","sha":"5253d1ab77fab1995ede03fb934edd67f1359ba8","d":1266206587,"s":"strip out unfinished product, review and market stuff, enable _() instead of wxT() in uiproject.fbp so it uses wxGetTranslation for the wxFormBuilder generated part of the UI","r":64,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":127,"del":8464,"u":"https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934edd67f1359ba8","f":[["db.cpp",0,21,null,0,0],["db.h",0,39,null,0,0],["headers.h",0,1,null,0,0],["main.cpp",2,22,null,0,0],["makefile",2,5,null,0,0],["makefile.unix.wx2.8",2,5,null,0,0],["makefile.unix.wx2.9",2,5,null,0,0],["makefile.vc",2,5,null,0,0],["market.cpp",0,264,null,0,0],["market.h",0,182,null,0,0],["net.cpp",0,9,null,0,0],["net.h",0,6,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",10,920,null,681,0],["ui.h",3,139,null,0,0],["uibase.cpp",72,779,null,899,0],["uibase.h",15,272,null,391,0],["uiproject.fbp",16,5789,null,5874,0]]},{"id":"c2b63e68bbf","sha":"2b63e68bbfebc370aa6f2d542419a6e5680f33c5","d":1266266215,"s":"fix mingw makefile to use correct wxWidgets include, this is the last version of makefile and makefile.vc for wxWidgets-2.8","r":65,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/2b63e68bbfebc370aa6f2d542419a6e5680f33c5","f":[["makefile",1,1,null,0,0]]},{"id":"ce480659765","sha":"e4806597650d8a17f1da7a5b5501eb367ea786fc","d":1266427321,"s":"all builds are now with wxWidgets-2.9.0, we are now using UTF-8, added support for language translation file locale/<lang>/LC_MESSAGES/bitcoin.mo -- version 0.2.2","r":66,"rel":"v0.2.2","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":428,"del":609,"u":"https://github.com/bitcoin/bitcoin/commit/e4806597650d8a17f1da7a5b5501eb367ea786fc","f":[["build-msw.txt",16,8,null,0,0],["build-unix.txt",10,12,null,0,0],["locale/readme.txt",5,0,null,0,0],["main.cpp",8,22,null,0,0],["makefile",0,83,null,0,0],["makefile.mingw",86,0,null,0,0],["makefile.unix",78,0,null,0,0],["makefile.unix.wx2.8",0,88,null,0,0],["makefile.unix.wx2.9",0,88,null,0,0],["makefile.vc",20,15,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",183,154,null,592,0],["ui.h",6,6,null,0,0],["uibase.cpp",3,14,null,0,0],["uibase.h",0,5,null,0,0],["uiproject.fbp",3,105,null,0,0],["util.cpp",3,3,null,0,0],["util.h",5,4,null,0,0]]},{"id":"cc6ab3cf6d9","sha":"c6ab3cf6d9cf5f5ade3b8fc48590e1bc4794cb43","d":1266450943,"s":"safer wxGetTranslation wrapper","r":67,"rel":"v0.2.4","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":34,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/c6ab3cf6d9cf5f5ade3b8fc48590e1bc4794cb43","f":[["serialize.h",1,1,null,0,0],["util.cpp",29,0,null,0,0],["util.h",4,5,null,0,0]]},{"id":"c75199de534","sha":"75199de534a590329a3b636d63fade2e4544ce97","d":1266703199,"s":"Address Book with tabs instead of separate Your Address book, with live update of default address in main window, New... button on main window for creating new receiving address, made receiving address labels more visible, ask user before paying transaction fee, when sending to bitcoin address also use a bitcoin address for the change, added some event.Skip() to fix UI glitches -- version 0.2.4","r":68,"rel":"v0.2.4","cn":"s_nakamoto","who":"s_nakamoto","fc":10,"ins":941,"del":549,"u":"https://github.com/bitcoin/bitcoin/commit/75199de534a590329a3b636d63fade2e4544ce97","f":[["main.cpp",57,55,null,0,0],["main.h",4,3,null,0,0],["script.h",5,0,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",280,300,null,665,0],["ui.h",27,35,null,0,0],["uibase.cpp",71,29,null,0,0],["uibase.h",25,11,null,0,0],["uiproject.fbp",466,114,null,451,0],["util.cpp",5,1,null,0,0]]},{"id":"c0184604aaf","sha":"0184604aaf21f8279df9ecbee7be4fbf0bbf99c1","d":1266788521,"s":"transaction filter tabs instead of view->show generated -- version 0.2.5","r":69,"rel":"v0.2.5","cn":"s_nakamoto","who":"s_nakamoto","fc":9,"ins":693,"del":132,"u":"https://github.com/bitcoin/bitcoin/commit/0184604aaf21f8279df9ecbee7be4fbf0bbf99c1","f":[["build-unix.txt",1,1,null,0,0],["db.cpp",0,2,null,0,0],["main.cpp",3,1,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",62,25,null,0,0],["ui.h",13,3,null,0,0],["uibase.cpp",73,19,null,0,0],["uibase.h",36,31,null,0,0],["uiproject.fbp",504,49,null,321,0]]},{"id":"ccb420a1dfc","sha":"cb420a1dfc23d3c11c5281ed8f7ae003c2f61594","d":1266962499,"s":"run as daemon without GUI, hooked wxApp::Initialize to ignore gtk-init-check failure if no GUI, fork to daemonize, rpc getinfo, getconnectioncount, getbalance, getgenerate, setgenerate, -- version 0.2.6","r":70,"rel":"v0.2.6","cn":"s_nakamoto","who":"s_nakamoto","fc":7,"ins":207,"del":47,"u":"https://github.com/bitcoin/bitcoin/commit/cb420a1dfc23d3c11c5281ed8f7ae003c2f61594","f":[["main.cpp",7,8,null,0,0],["main.h",4,0,null,0,0],["rpc.cpp",113,21,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",78,16,null,0,0],["util.cpp",3,1,null,0,0],["util.h",1,0,null,0,0]]},{"id":"cc2430126d7","sha":"c2430126d75318508836a24f90d3524320190465","d":1267134927,"s":"GUI-less build target bitcoind that links to wxBase and shouldn't need GTK, split init and shutdown from ui.cpp into init.cpp, support wxUSE_GUI=0 -- version 0.2.7","r":71,"rel":"v0.2.7","cn":"s_nakamoto","who":"s_nakamoto","fc":13,"ins":817,"del":773,"u":"https://github.com/bitcoin/bitcoin/commit/c2430126d75318508836a24f90d3524320190465","f":[["headers.h",6,1,null,0,0],["init.cpp",625,0,null,326,0],["init.h",7,0,null,0,0],["main.cpp",3,1,null,0,0],["main.h",2,0,null,0,0],["makefile.mingw",26,36,null,0,0],["makefile.unix",28,33,null,0,0],["makefile.vc",55,32,null,0,0],["rpc.cpp",5,5,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",13,656,null,435,0],["ui.h",43,6,null,0,0],["util.cpp",3,2,null,0,0]]},{"id":"c6557910ccf","sha":"6557910ccf36e098b1a0de4841be7c04c4ffd58a","d":1267200583,"s":"wx/utils.h and wx/clipbrd.h not needed on bitcoind wxbase build","r":72,"rel":"v0.2.8","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":3,"del":3,"u":"https://github.com/bitcoin/bitcoin/commit/6557910ccf36e098b1a0de4841be7c04c4ffd58a","f":[["headers.h",3,3,null,0,0]]},{"id":"cd7d80a74d5","sha":"d7d80a74d58152453cfb0c71a08f6b424d2493c9","d":1267369232,"s":"fix unsafe string handling in wxGetTranslation","r":73,"rel":"v0.2.8","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":14,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/d7d80a74d58152453cfb0c71a08f6b424d2493c9","f":[["makefile.vc",9,9,null,0,0],["serialize.h",1,1,null,0,0],["util.cpp",4,4,null,0,0]]},{"id":"c2cffa7ce31","sha":"2cffa7ce315d9b98d35192d16927b44d21b9e1a7","d":1267751607,"s":"fixed runaway memory alloc bug on 64-bit in ParseString found by sirius-m","r":74,"rel":"v0.2.8","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":10,"del":4,"u":"https://github.com/bitcoin/bitcoin/commit/2cffa7ce315d9b98d35192d16927b44d21b9e1a7","f":[["util.cpp",10,4,null,0,0]]},{"id":"c966cca4bd4","sha":"966cca4bd4a6d869583fb47f5f66ed4672c007ff","d":1267757709,"s":"misc","r":75,"rel":"v0.2.8","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":4,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/966cca4bd4a6d869583fb47f5f66ed4672c007ff","f":[["irc.cpp",4,1,null,0,0]]},{"id":"c2d98de1b3a","sha":"2d98de1b3ae2ade8b1e5493bc63c0c1d776deeb1","d":1274228816,"s":"Mac OS build fixes by laszlo -- version 0.2.8","r":76,"rel":"v0.2.8","cn":"s_nakamoto","who":"s_nakamoto","fc":12,"ins":109,"del":74,"u":"https://github.com/bitcoin/bitcoin/commit/2d98de1b3ae2ade8b1e5493bc63c0c1d776deeb1","f":[["init.cpp",7,1,null,0,0],["main.cpp",3,3,null,0,0],["net.cpp",1,3,null,0,0],["net.h",27,16,null,0,0],["rpc.cpp",14,9,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",12,3,null,0,0],["uibase.cpp",7,7,null,0,0],["uibase.h",22,23,null,0,0],["uiproject.fbp",7,7,null,0,0],["util.cpp",6,0,null,0,0],["util.h",1,0,null,0,0]]},{"id":"c124baa4ccb","sha":"124baa4ccbf3ecb78eab7ecdd40105fb54ee0369","d":1274831907,"s":"build-osx.txt build instructions and makefile.osx from Laszlo","r":77,"rel":"v0.2.9","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":274,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/124baa4ccbf3ecb78eab7ecdd40105fb54ee0369","f":[["build-osx.txt",209,0,null,0,0],["makefile.osx",65,0,null,0,0]]},{"id":"c42605ce8bc","sha":"42605ce8bcc9bd01b86491c74fee14de77960868","d":1274832326,"s":"better prevention of inventory relaying during initial download, message checksum between nodes with 0.2.9 or higher, optimization level up from -O0 to -O2, rpc functions: setlabel, getlabel, getaddressesbylabel, getreceivedbyaddress, getreceivedbylabel, listreceivedbyaddress, listreceivedbylabel  -- version 0.2.9","r":78,"rel":"v0.2.9","cn":"s_nakamoto","who":"s_nakamoto","fc":13,"ins":364,"del":101,"u":"https://github.com/bitcoin/bitcoin/commit/42605ce8bcc9bd01b86491c74fee14de77960868","f":[["db.h",2,0,null,0,0],["init.cpp",3,4,null,0,0],["main.cpp",50,26,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.unix",1,1,null,0,0],["net.h",24,6,null,0,0],["rpc.cpp",251,54,null,98,0],["serialize.h",13,1,null,0,0],["ui.cpp",8,1,null,0,0],["ui.h",9,0,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",1,1,null,0,0],["util.cpp",0,5,null,0,0]]},{"id":"c1da44d2e96","sha":"1da44d2e96cd2461eb25ffd17c417cf2e5aef9de","d":1274969463,"s":"Italian translation by Joozero","r":79,"rel":"v0.2.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":806,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/1da44d2e96cd2461eb25ffd17c417cf2e5aef9de","f":[["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",806,0,null,507,0]]},{"id":"c2ca1758832","sha":"2ca17588327858947590fda78d68cfad79e633bc","d":1275516606,"s":"Dutch translation by Xunie (93% complete)","r":80,"rel":"v0.2.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":808,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/2ca17588327858947590fda78d68cfad79e633bc","f":[["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",808,0,null,509,0]]},{"id":"cf93d5f9ffe","sha":"f93d5f9ffe1e12079e560a735111735924726a06","d":1276211430,"s":"automatically change displayed address whenever it receives anything, added help and -? for daemon command line rpc commands, only relay addr messages to 5 random nodes to save bandwidth, started setting wtx.fFromMe flag, trickle out tx inventory messages to protect privacy  -- version 0.2.10","r":81,"rel":"v0.2.10","cn":"s_nakamoto","who":"s_nakamoto","fc":16,"ins":267,"del":142,"u":"https://github.com/bitcoin/bitcoin/commit/f93d5f9ffe1e12079e560a735111735924726a06","f":[["db.cpp",4,5,null,0,0],["db.h",4,1,null,0,0],["init.cpp",18,13,null,0,0],["irc.cpp",0,1,null,0,0],["main.cpp",77,32,null,0,0],["main.h",2,1,null,0,0],["net.cpp",7,2,null,0,0],["net.h",7,3,null,0,0],["rpc.cpp",123,74,null,82,0],["serialize.h",1,1,null,0,0],["ui.cpp",8,1,null,0,0],["uibase.cpp",1,1,null,0,0],["uibase.h",1,1,null,0,0],["uint256.h",4,1,null,0,0],["uiproject.fbp",3,3,null,0,0],["util.h",7,2,null,0,0]]},{"id":"cbed005b639","sha":"bed005b639a0db8c8d98022609fe03e0ec55e18a","d":1276554873,"s":"revert makefile.unix from -02 back to -00 to fix compile on linux, -02 doesn't really help on linux anyway","r":82,"rel":"v0.2.11","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/bed005b639a0db8c8d98022609fe03e0ec55e18a","f":[["makefile.unix",1,1,null,0,0]]},{"id":"ce5681bb121","sha":"e5681bb12154bae75977d091190e924d8e6984cd","d":1276626392,"s":"more addr message error checking -- version 0.2.11","r":83,"rel":"v0.2.11","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":23,"del":12,"u":"https://github.com/bitcoin/bitcoin/commit/e5681bb12154bae75977d091190e924d8e6984cd","f":[["main.cpp",4,1,null,0,0],["net.cpp",3,3,null,0,0],["net.h",15,7,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c6a4a35549b","sha":"6a4a35549bde3cd8cc4143d10356a8ec83255395","d":1276706134,"s":"German translation by DataWraith","r":84,"rel":"v0.2.12","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":810,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/6a4a35549bde3cd8cc4143d10356a8ec83255395","f":[["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",810,0,null,511,0]]},{"id":"c24ba1b64e9","sha":"24ba1b64e93baafba2657ba7d8b63c759c3439ce","d":1276830864,"s":"use seed nodes as fallback if IRC fails or with TOR -- version 0.2.12","r":85,"rel":"v0.2.12","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":95,"del":19,"u":"https://github.com/bitcoin/bitcoin/commit/24ba1b64e93baafba2657ba7d8b63c759c3439ce","f":[["main.cpp",19,11,null,0,0],["net.cpp",73,5,null,0,0],["net.h",1,1,null,0,0],["serialize.h",2,2,null,0,0]]},{"id":"c68b973a913","sha":"68b973a913fd1569d3a9a444d4233b15f7866e3e","d":1277084024,"s":"fixed colors on ubuntu lucid, enabled -O2 in makefile.unix, boost removed -mt from their library names in 1.40, updated bitcoin icon, hashmeter, generated and hashmeter log entries -- version 0.2.13","r":86,"rel":"v0.2.13","cn":"s_nakamoto","who":"s_nakamoto","fc":23,"ins":1046,"del":1122,"u":"https://github.com/bitcoin/bitcoin/commit/68b973a913fd1569d3a9a444d4233b15f7866e3e","f":[["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",0,5,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",5,8,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",4,8,null,0,0],["main.cpp",30,1,null,0,0],["makefile.unix",4,4,null,0,0],["net.cpp",1,1,null,0,0],["net.h",1,1,null,0,0],["rc/bitcoin-bc.ico",null,null,null,1,1],["rc/bitcoin.ico",null,null,null,1,1],["rc/favicon.ico",null,null,null,1,1],["serialize.h",1,1,null,0,0],["ui.cpp",6,5,null,0,0],["uibase.cpp",7,13,null,0,0],["uibase.h",2,3,null,0,0],["uiproject.fbp",111,154,null,24,0],["util.cpp",1,3,null,0,0],["xpm/bitcoin16.xpm",214,198,null,118,0],["xpm/bitcoin20.xpm",155,221,null,82,0],["xpm/bitcoin32.xpm",227,218,null,173,0],["xpm/bitcoin48.xpm",277,278,null,556,0]]},{"id":"c161c38ba60","sha":"161c38ba6025fba019e84dd4b799addc544ea1b3","d":1277140286,"s":"80x80 xpm icon for ubuntu, alignment tweaked to scale nicely to 20x20 and 16x16","r":87,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":295,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/161c38ba6025fba019e84dd4b799addc544ea1b3","f":[["headers.h",1,0,null,0,0],["ui.cpp",2,2,null,0,0],["xpm/bitcoin80.xpm",292,0,null,0,0]]},{"id":"c36bb88e1b9","sha":"36bb88e1b9825f84c49c04643461dce823f70455","d":1277145694,"s":"fix system tray icon on windows","r":88,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":4,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/36bb88e1b9825f84c49c04643461dce823f70455","f":[["ui.cpp",3,1,null,0,0],["ui.rc",1,0,null,0,0]]},{"id":"c8efd8f7f47","sha":"8efd8f7f47bb84e3bfca07e64693514a8f90240b","d":1277178337,"s":"re-enable hiding taskbar button on minimize on linux, though it doesn't work cleanly","r":89,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":5,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/8efd8f7f47bb84e3bfca07e64693514a8f90240b","f":[["main.cpp",1,1,null,0,0],["ui.cpp",4,4,null,0,0]]},{"id":"c445520bf38","sha":"445520bf38670bbf2be5d1560db409082e71cb1a","d":1277224095,"s":"added new files to setup.nsi, updated version numbers","r":90,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":7,"ins":20,"del":10,"u":"https://github.com/bitcoin/bitcoin/commit/445520bf38670bbf2be5d1560db409082e71cb1a","f":[["base58.h",1,1,null,0,0],["build-msw.txt",0,2,null,0,0],["build-osx.txt",8,0,null,0,0],["build-unix.txt",0,2,null,0,0],["key.h",1,1,null,0,0],["setup.nsi",9,3,null,0,0],["uint256.h",1,1,null,0,0]]},{"id":"c6344edc36f","sha":"6344edc36f885ba1c2003ebe2c43feeafc0b13d2","d":1277229540,"s":"version 0.3 rc1","r":91,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/6344edc36f885ba1c2003ebe2c43feeafc0b13d2","f":[["serialize.h",2,2,null,0,0]]},{"id":"c3c3fc50c79","sha":"3c3fc50c79cbbc2f1da042bf48b34b5900428db6","d":1277333491,"s":"added instructions to build-unix.txt for building wxBase, which is needed to compile bitcoind","r":92,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":9,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/3c3fc50c79cbbc2f1da042bf48b34b5900428db6","f":[["build-unix.txt",9,0,null,0,0]]},{"id":"c340120853f","sha":"340120853fdf41597a3b7de21bae70f716728d5b","d":1277395671,"s":"updated build-unix.txt instructions: sudo apt-get install libboost-all-dev","r":93,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/340120853fdf41597a3b7de21bae70f716728d5b","f":[["build-unix.txt",1,1,null,0,0]]},{"id":"c8700fae12a","sha":"8700fae12ada51f131e783ad65c196a16d70d347","d":1277511796,"s":"build-unix.txt: updated a few version numbers","r":94,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":3,"del":3,"u":"https://github.com/bitcoin/bitcoin/commit/8700fae12ada51f131e783ad65c196a16d70d347","f":[["build-unix.txt",3,3,null,0,0]]},{"id":"c06c4716396","sha":"06c47163962ce418569d9386770001c7a79c026e","d":1277567265,"s":"version 0.3 rc2","r":95,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":6,"del":4,"u":"https://github.com/bitcoin/bitcoin/commit/06c47163962ce418569d9386770001c7a79c026e","f":[["irc.cpp",4,2,null,0,0],["main.cpp",1,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cf077bc0f48","sha":"f077bc0f48bf0853cbe5d01b0e10df93c04917ab","d":1278114209,"s":"reduced max outbound connections from 15 to 8 --version 0.3 rc4","r":96,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":6,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/f077bc0f48bf0853cbe5d01b0e10df93c04917ab","f":[["init.cpp",1,1,null,0,0],["irc.cpp",0,1,null,0,0],["main.cpp",2,0,null,0,0],["net.cpp",1,1,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"cd77eac25b2","sha":"d77eac25b2ecd8e6ff5619cfa57d0ebc0682ed09","d":1278224106,"s":"version 0.3 release","r":97,"rel":"v0.3.0","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":2,"del":11,"u":"https://github.com/bitcoin/bitcoin/commit/d77eac25b2ecd8e6ff5619cfa57d0ebc0682ed09","f":[["init.cpp",1,1,null,0,0],["ui.cpp",1,10,null,0,0]]},{"id":"cd882773789","sha":"d882773789ea3894de7163f7bb880c5b23072882","d":1278605696,"s":"Laszlo's fix to make generate threads idle priority on Linux, replaced some wxBase dependencies: wxMutex, wxFileExists, wxStandardPaths, wxGetLocalTimeMillis","r":99,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":17,"ins":167,"del":101,"u":"https://github.com/bitcoin/bitcoin/commit/d882773789ea3894de7163f7bb880c5b23072882","f":[["headers.h",4,0,null,0,0],["init.cpp",25,49,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",4,0,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",4,0,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",4,0,null,0,0],["main.cpp",26,16,null,0,0],["makefile.unix",3,3,null,0,0],["rpc.cpp",12,10,null,0,0],["serialize.h",1,1,null,0,0],["uibase.cpp",1,1,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",2,2,null,0,0],["util.cpp",69,11,null,0,0],["util.h",11,7,null,0,0]]},{"id":"c50d49d9c2e","sha":"50d49d9c2ee610785e00181744b7adfae558a6a3","d":1278612434,"s":"Portuguese translation by Tiago Faria","r":100,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":807,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/50d49d9c2ee610785e00181744b7adfae558a6a3","f":[["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",807,0,null,508,0]]},{"id":"c20c6bfad1e","sha":"20c6bfad1e0f5438b6f016f53d0eac9a0415236a","d":1278641510,"s":"Gavin Andresen: implementation of autostart on system startup option on Linux","r":101,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":86,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/20c6bfad1e0f5438b6f016f53d0eac9a0415236a","f":[["headers.h",1,0,null,0,0],["init.cpp",77,0,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",4,2,null,0,0],["util.cpp",3,3,null,0,0]]},{"id":"c6e5d67e827","sha":"6e5d67e827904571658213054fab6f0399b48801","d":1278689388,"s":"switched from wxStandardPaths to GetDefaultDataDir, fixes bug reported by m0mchil when username contains non-lower-ASCII characters -- version 0.3.1","r":102,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":6,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/6e5d67e827904571658213054fab6f0399b48801","f":[["init.cpp",1,11,null,0,0],["serialize.h",2,2,null,0,0],["util.cpp",2,1,null,0,0],["util.h",1,0,null,0,0]]},{"id":"ca30b56ebe7","sha":"a30b56ebe76ffff9f9cc8a6667186179413c6349","d":1279153125,"s":"fix openssl linkage problems, disable minimize to tray on Linux because it has too many problems including a CPU peg bug","r":103,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":7,"ins":26,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349","f":[["db.cpp",2,0,null,0,0],["irc.cpp",4,0,null,0,0],["main.cpp",4,1,null,0,0],["main.h",1,0,null,0,0],["makefile.unix",1,1,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",13,2,null,0,0]]},{"id":"cd01eaf0421","sha":"d01eaf0421b534b9d15b2376573fbc5e36c35928","d":1279212406,"s":"version 0.3.1 rc1","r":104,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":5,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/d01eaf0421b534b9d15b2376573fbc5e36c35928","f":[["main.cpp",1,1,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c0bbc812f48","sha":"0bbc812f4822d90d0cbad3c30d28fe810ea608de","d":1279221111,"s":"Spanish translation by milkiway, French translation by aidos","r":105,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":1687,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/0bbc812f4822d90d0cbad3c30d28fe810ea608de","f":[["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",841,0,null,542,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",846,0,null,547,0]]},{"id":"c673a6d15d9","sha":"673a6d15d9867275e3a4ffb33b14b5fe7112cc42","d":1279321978,"s":"version 0.3.1 release","r":106,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":6,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/673a6d15d9867275e3a4ffb33b14b5fe7112cc42","f":[["ui.cpp",6,0,null,0,0]]},{"id":"cae922a36a4","sha":"ae922a36a4b54a8e78d3a2a2cb2af7f03960fce3","d":1279410676,"s":"security safeguards, limited addr messages -- version 0.3.2","r":107,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":20,"del":7,"u":"https://github.com/bitcoin/bitcoin/commit/ae922a36a4b54a8e78d3a2a2cb2af7f03960fce3","f":[["main.cpp",16,3,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"ce8bff10f07","sha":"e8bff10f07b80d820545661cee9337d8664a64cb","d":1279486049,"s":"minor UI tweaks, removed some outdated txt files, (and json-rpc password -rpcpw= switch, which we're going to revert)","r":108,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":19,"ins":71,"del":46,"u":"https://github.com/bitcoin/bitcoin/commit/e8bff10f07b80d820545661cee9337d8664a64cb","f":[["bugs.txt",0,2,null,0,0],["changelog.txt",0,7,null,0,0],["init.cpp",3,3,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",1,1,null,0,0],["rpc.cpp",57,24,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",2,2,null,0,0],["util.cpp",2,1,null,0,0]]},{"id":"c3b7cd5d89a","sha":"3b7cd5d89a226426df9c723d1f9ddfe08b7d1def","d":1280076321,"s":"Gavin Andresen's JSON-RPC HTTP authentication, faster initial block download -- version 0.3.3","r":109,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":405,"del":137,"u":"https://github.com/bitcoin/bitcoin/commit/3b7cd5d89a226426df9c723d1f9ddfe08b7d1def","f":[["db.cpp",30,6,null,0,0],["db.h",2,2,null,0,0],["headers.h",4,0,null,0,0],["init.cpp",45,40,null,0,0],["main.cpp",34,4,null,0,0],["main.h",15,2,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.osx",1,0,null,0,0],["makefile.unix",1,1,null,0,0],["makefile.vc",1,1,null,0,0],["rpc.cpp",217,67,null,224,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",1,0,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",1,1,null,0,0],["util.cpp",36,5,null,0,0],["util.h",10,1,null,0,0]]},{"id":"c7d46f9250c","sha":"7d46f9250cef06d248617085a7439e8ef8841cd7","d":1280093347,"s":"Lachesis: remove newlines every 64 characters in EncodeBase64","r":110,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":4,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/7d46f9250cef06d248617085a7439e8ef8841cd7","f":[["rpc.cpp",4,0,null,0,0]]},{"id":"c6966768a55","sha":"6966768a554575ca329fbcd4aad0d4f21c702f9a","d":1280094561,"s":"Gavin: BIO_FLAGS_BASE64_NO_NL","r":111,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/6966768a554575ca329fbcd4aad0d4f21c702f9a","f":[["rpc.cpp",2,5,null,0,0]]},{"id":"c793200e5e9","sha":"793200e5e918a6e993ddf701967a8b6535a6828f","d":1280164518,"s":"bitcoind now compiles without wxWidgets or wxBase","r":112,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":539,"del":483,"u":"https://github.com/bitcoin/bitcoin/commit/793200e5e918a6e993ddf701967a8b6535a6828f","f":[["build-unix.txt",2,14,null,0,0],["db.cpp",1,1,null,0,0],["headers.h",14,3,null,0,0],["init.cpp",48,340,null,191,0],["init.h",2,2,null,0,0],["main.cpp",3,2,null,0,0],["makefile.mingw",12,14,null,0,0],["makefile.osx",7,6,null,0,0],["makefile.unix",11,9,null,0,0],["makefile.vc",18,16,null,0,0],["net.cpp",2,2,null,0,0],["noui.h",34,0,null,0,0],["rpc.cpp",3,3,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",342,8,null,96,0],["ui.h",15,48,null,0,0],["util.cpp",12,9,null,0,0],["util.h",11,4,null,0,0]]},{"id":"c40cd036941","sha":"40cd0369419323f8d7385950e20342e998c994e1","d":1280166005,"s":"Gavin Andresen's JSON-RPC HTTP authentication, faster initial block download -- version 0.3.3","r":null,"rel":"v0.3.3","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":12,"ins":93,"del":25,"u":"https://github.com/bitcoin/bitcoin/commit/40cd0369419323f8d7385950e20342e998c994e1","f":[["db.cpp",30,6,null,0,0],["db.h",2,2,null,0,0],["main.cpp",34,4,null,0,0],["main.h",15,2,null,0,0],["makefile.unix",1,1,null,0,0],["rpc.cpp",1,1,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",1,0,null,0,0],["uibase.h",1,1,null,0,0],["uiproject.fbp",1,1,null,0,0],["util.cpp",2,2,null,0,0]]},{"id":"cb6dc3b517b","sha":"b6dc3b517b74ef2baa0e707f837a65b4ff5a6f2e","d":1280166291,"s":"bitcoind now compiles without wxWidgets or wxBase","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":17,"ins":537,"del":469,"u":"https://github.com/bitcoin/bitcoin/commit/b6dc3b517b74ef2baa0e707f837a65b4ff5a6f2e","f":[["db.cpp",1,1,null,0,0],["headers.h",14,3,null,0,0],["init.cpp",48,340,null,191,0],["init.h",2,2,null,0,0],["main.cpp",3,2,null,0,0],["makefile.mingw",12,14,null,0,0],["makefile.osx",7,6,null,0,0],["makefile.unix",11,9,null,0,0],["makefile.vc",18,16,null,0,0],["net.cpp",2,2,null,0,0],["noui.h",34,0,null,0,0],["rpc.cpp",3,3,null,0,0],["serialize.h",2,2,null,0,0],["ui.cpp",342,8,null,96,0],["ui.h",15,48,null,0,0],["util.cpp",12,9,null,0,0],["util.h",11,4,null,0,0]]},{"id":"c520f367319","sha":"520f3673196dd6517982e3f662cf62afda368341","d":1280193273,"s":"tcatm's cached SHA256 state idea, about 70% faster generating","r":113,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":129,"del":57,"u":"https://github.com/bitcoin/bitcoin/commit/520f3673196dd6517982e3f662cf62afda368341","f":[["main.cpp",129,57,null,0,0]]},{"id":"c9f35575ca3","sha":"9f35575ca34eb15b20d1d5374b56ac9d4c8cc2bf","d":1280240462,"s":"tcatm's cached SHA256 state idea, about 70% faster generating","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":1,"ins":129,"del":57,"u":"https://github.com/bitcoin/bitcoin/commit/9f35575ca34eb15b20d1d5374b56ac9d4c8cc2bf","f":[["main.cpp",129,57,null,0,0]]},{"id":"c813505cc13","sha":"813505cc1313b7e191b787f93e573acb91fa1464","d":1280254472,"s":"added a subset of Crypto++ 5.6.0 with 48% faster ASM SHA-256, combined speedup 2.5x faster vs 0.3.3, thanks BlackEye for figuring out the alignment problem","r":114,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":23,"ins":6085,"del":893,"u":"https://github.com/bitcoin/bitcoin/commit/813505cc1313b7e191b787f93e573acb91fa1464","f":[["cryptopp/License.txt",67,0,null,0,0],["cryptopp/Readme.txt",429,0,null,130,0],["cryptopp/config.h",455,0,null,156,0],["cryptopp/cpu.cpp",199,0,null,0,0],["cryptopp/cpu.h",263,0,null,0,0],["cryptopp/cryptlib.h",1668,0,null,1369,0],["cryptopp/iterhash.h",29,0,null,0,0],["cryptopp/misc.h",1134,0,null,1097,0],["cryptopp/pch.h",21,0,null,22,0],["cryptopp/secblock.h",500,0,null,501,0],["cryptopp/sha.cpp",899,0,null,900,0],["cryptopp/sha.h",63,0,null,64,0],["cryptopp/simple.h",1,0,null,2,0],["cryptopp/smartptr.h",223,0,null,224,0],["cryptopp/stdcpp.h",27,0,null,28,0],["main.cpp",12,96,null,177,0],["makefile.mingw",18,15,null,61,0],["makefile.osx",16,14,null,51,0],["makefile.unix",17,14,null,57,0],["makefile.vc",30,23,null,89,0],["sha.cpp",0,554,null,555,0],["sha.h",0,177,null,178,0],["util.h",14,0,null,21,0]]},{"id":"cf79751c299","sha":"f79751c2997a72447f46927f200d78a6da50048d","d":1280259784,"s":"better IsInitialBlockDownload","r":115,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":10,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/f79751c2997a72447f46927f200d78a6da50048d","f":[["main.cpp",10,14,null,0,0]]},{"id":"c3dd20ff2f8","sha":"3dd20ff2f87958a440c9dceae8abe3967aa48fcf","d":1280263435,"s":"added a subset of Crypto++ 5.6.0 with 48% faster ASM SHA-256, combined speedup 2.5x faster vs 0.3.3, thanks BlackEye for figuring out the alignment problem","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":26,"ins":6091,"del":893,"u":"https://github.com/bitcoin/bitcoin/commit/3dd20ff2f87958a440c9dceae8abe3967aa48fcf","f":[["cryptopp/License.txt",67,0,null,0,0],["cryptopp/Readme.txt",429,0,null,130,0],["cryptopp/config.h",455,0,null,156,0],["cryptopp/cpu.cpp",199,0,null,0,0],["cryptopp/cpu.h",263,0,null,0,0],["cryptopp/cryptlib.h",1668,0,null,1369,0],["cryptopp/iterhash.h",29,0,null,0,0],["cryptopp/misc.h",1134,0,null,1097,0],["cryptopp/obj/.gitignore",2,0,null,3,0],["cryptopp/pch.h",21,0,null,22,0],["cryptopp/secblock.h",500,0,null,501,0],["cryptopp/sha.cpp",899,0,null,900,0],["cryptopp/sha.h",63,0,null,64,0],["cryptopp/simple.h",1,0,null,2,0],["cryptopp/smartptr.h",223,0,null,224,0],["cryptopp/stdcpp.h",27,0,null,28,0],["main.cpp",12,96,null,177,0],["makefile.mingw",18,15,null,61,0],["makefile.osx",16,14,null,51,0],["makefile.unix",17,14,null,57,0],["makefile.vc",30,23,null,89,0],["obj/.gitignore",2,0,null,3,0],["obj/nogui/.gitignore",2,0,null,3,0],["sha.cpp",0,554,null,555,0],["sha.h",0,177,null,178,0],["util.h",14,0,null,21,0]]},{"id":"c2689f4d02b","sha":"2689f4d02b0632926c815e58363e8e7292586242","d":1280263601,"s":"better IsInitialBlockDownload","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":1,"ins":10,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/2689f4d02b0632926c815e58363e8e7292586242","f":[["main.cpp",10,14,null,0,0]]},{"id":"c0bd084011a","sha":"0bd084011a3f95cf3fdc7a20b7017bfe06c7223f","d":1280351469,"s":"fixed makefile.vc","r":116,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/0bd084011a3f95cf3fdc7a20b7017bfe06c7223f","f":[["makefile.vc",2,2,null,0,0]]},{"id":"cf6f8237a74","sha":"f6f8237a748e3627bd4a201ed2e376d8c42c3bac","d":1280351855,"s":"fixed makefile.osx","r":117,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/f6f8237a748e3627bd4a201ed2e376d8c42c3bac","f":[["makefile.osx",1,1,null,0,0]]},{"id":"c17b2740289","sha":"17b2740289268c037c5adb5956989f134982bf80","d":1280417688,"s":"Fredrik Roubert: simplified makefile.unix with wx-config, misc","r":118,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":14,"del":24,"u":"https://github.com/bitcoin/bitcoin/commit/17b2740289268c037c5adb5956989f134982bf80","f":[["main.cpp",6,6,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.unix",6,15,null,0,0],["ui.cpp",1,2,null,0,0]]},{"id":"c757f0769d8","sha":"757f0769d8360ea043f469f3a35f6ec204740446","d":1280435232,"s":"reverted makefile.unix wx-config -- version 0.3.6","r":119,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":718,"del":655,"u":"https://github.com/bitcoin/bitcoin/commit/757f0769d8360ea043f469f3a35f6ec204740446","f":[["bignum.h",2,1,null,0,0],["makefile.unix",14,5,null,0,0],["script.cpp",671,643,null,1131,0],["script.h",26,1,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c872d60f6e4","sha":"872d60f6e4aa599a4821372c30a285f67f9faa77","d":1280511065,"s":"fixed makefile.vc","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/872d60f6e4aa599a4821372c30a285f67f9faa77","f":[["makefile.vc",2,2,null,0,0]]},{"id":"c31ffe954b6","sha":"31ffe954b6f415b724c3214de5bffd7bba5872c0","d":1280511099,"s":"fixed makefile.osx","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/31ffe954b6f415b724c3214de5bffd7bba5872c0","f":[["makefile.osx",1,1,null,0,0]]},{"id":"cec82517c89","sha":"ec82517c8919f9cb7194511dc322a2575745e39e","d":1280511317,"s":"Fredrik Roubert: simplified makefile.unix with wx-config, misc","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":4,"ins":14,"del":24,"u":"https://github.com/bitcoin/bitcoin/commit/ec82517c8919f9cb7194511dc322a2575745e39e","f":[["main.cpp",6,6,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.unix",6,15,null,0,0],["ui.cpp",1,2,null,0,0]]},{"id":"ca75560d828","sha":"a75560d828464c3f1138f52cf247e956fc8f937d","d":1280511366,"s":"reverted makefile.unix wx-config -- version 0.3.6","r":null,"rel":"v0.3.6","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":6,"ins":718,"del":655,"u":"https://github.com/bitcoin/bitcoin/commit/a75560d828464c3f1138f52cf247e956fc8f937d","f":[["bignum.h",2,1,null,0,0],["makefile.unix",14,5,null,0,0],["script.cpp",671,643,null,1131,0],["script.h",26,1,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c01bed1828b","sha":"01bed1828b9ee64b9b38a7d0345c775de40fdd91","d":1280532175,"s":"simplified makefile.unix, updated build-unix.txt instructions to include boost 1.37","r":120,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":13,"del":18,"u":"https://github.com/bitcoin/bitcoin/commit/01bed1828b9ee64b9b38a7d0345c775de40fdd91","f":[["build-unix.txt",9,7,null,0,0],["makefile.unix",4,11,null,0,0]]},{"id":"ce1cb7ce017","sha":"e1cb7ce0177de72b00e06dc4c8fe1d414723a9e7","d":1280585681,"s":"simplified makefile.unix, updated build-unix.txt instructions to include boost 1.37","r":null,"rel":"v0.3.7","cn":"Gavin Andresen","who":"--author=Satoshi Nakamoto","fc":2,"ins":12,"del":29,"u":"https://github.com/bitcoin/bitcoin/commit/e1cb7ce0177de72b00e06dc4c8fe1d414723a9e7","f":[["build-unix.txt",8,18,null,0,0],["makefile.unix",4,11,null,0,0]]},{"id":"c6ff5f718b6","sha":"6ff5f718b6a67797b2b3bab8905d607ad216ee21","d":1280603748,"s":"fixed segfault in bignum.h, additional security limits, refactoring -- version 0.3.7","r":121,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":39,"del":24,"u":"https://github.com/bitcoin/bitcoin/commit/6ff5f718b6a67797b2b3bab8905d607ad216ee21","f":[["bignum.h",12,6,null,0,0],["main.cpp",2,1,null,0,0],["script.cpp",21,11,null,0,0],["script.h",0,2,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c73aa262647","sha":"73aa262647ff9948eaf95e83236ec323347e95d0","d":1280607125,"s":"fixed segfault in bignum.h, additional security limits, refactoring -- version 0.3.7","r":null,"rel":"v0.3.7","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":6,"ins":39,"del":24,"u":"https://github.com/bitcoin/bitcoin/commit/73aa262647ff9948eaf95e83236ec323347e95d0","f":[["bignum.h",12,6,null,0,0],["main.cpp",2,1,null,0,0],["script.cpp",21,11,null,0,0],["script.h",0,2,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c2c06be915d","sha":"2c06be915de967494920bdbb3096bbb455ccf99f","d":1280859905,"s":"new safety feature displays a warning message and locks down RPC if it detects a problem that may require an upgrade -- version 0.3.8","r":122,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":81,"del":34,"u":"https://github.com/bitcoin/bitcoin/commit/2c06be915de967494920bdbb3096bbb455ccf99f","f":[["db.cpp",13,0,null,0,0],["db.h",2,0,null,0,0],["main.cpp",38,22,null,0,0],["main.h",8,5,null,0,0],["rpc.cpp",4,0,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",12,3,null,0,0]]},{"id":"cb34e8c3c36","sha":"b34e8c3c369331189c01bcbb7682af9d7daa42cd","d":1280886694,"s":"new safety feature displays a warning message and locks down RPC if it detects a problem that may require an upgrade -- version 0.3.8","r":null,"rel":"v0.3.8","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":8,"ins":81,"del":34,"u":"https://github.com/bitcoin/bitcoin/commit/b34e8c3c369331189c01bcbb7682af9d7daa42cd","f":[["db.cpp",13,0,null,0,0],["db.h",2,0,null,0,0],["main.cpp",38,22,null,0,0],["main.h",8,5,null,0,0],["rpc.cpp",4,0,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",12,3,null,0,0]]},{"id":"ce6b7ab5749","sha":"e6b7ab57496c9267c5d0bbad2be8e942a01731dc","d":1281383680,"s":"enable SSE2 in all builds to fix crypto++ SHA-256 on 64-bit","r":124,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":14,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/e6b7ab57496c9267c5d0bbad2be8e942a01731dc","f":[["build-unix.txt",10,3,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.osx",1,0,null,0,0],["makefile.unix",1,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c94cfec07fd","sha":"94cfec07fd302c9ff9b6a80c47418d4fe56596ae","d":1281384017,"s":"always make 8 outbound connections even if have inbound, limit one outbound connection per a.b.?.? range, switch -maxconnections=#","r":125,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":25,"del":9,"u":"https://github.com/bitcoin/bitcoin/commit/94cfec07fd302c9ff9b6a80c47418d4fe56596ae","f":[["main.cpp",1,1,null,0,0],["net.cpp",22,6,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"cdd9e71843b","sha":"dd9e71843bc79e8c7e33734cc8b975275992cc05","d":1281455858,"s":"correct typo for mac compile, update makefile to use llvm","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":2,"ins":9,"del":7,"u":"https://github.com/bitcoin/bitcoin/commit/dd9e71843bc79e8c7e33734cc8b975275992cc05","f":[["makefile.osx",8,6,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"c8a38d5663a","sha":"8a38d5663ad6b98983c951b67c58aff2e94ff453","d":1281456083,"s":"enable SSE2 in all builds to fix crypto++ SHA-256 on 64-bit","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":5,"ins":14,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/8a38d5663ad6b98983c951b67c58aff2e94ff453","f":[["build-unix.txt",10,3,null,0,0],["makefile.mingw",1,1,null,0,0],["makefile.osx",1,0,null,0,0],["makefile.unix",1,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cc2fa70ddfd","sha":"c2fa70ddfd7711d514a701b3a7c8adb561acc3ff","d":1281456181,"s":"always make 8 outbound connections even if have inbound, limit one outbound connection per a.b.?.? range, switch -maxconnections=#","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":4,"ins":25,"del":9,"u":"https://github.com/bitcoin/bitcoin/commit/c2fa70ddfd7711d514a701b3a7c8adb561acc3ff","f":[["main.cpp",1,1,null,0,0],["net.cpp",22,6,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"c342e1b7338","sha":"342e1b73385cac5a5b2fc7316d82a2b55b3a85d4","d":1281468077,"s":"json-spirit print reals with 8 decimal places, bitcoind help <command> instead of bitcoind <command> -?","r":126,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":48,"del":56,"u":"https://github.com/bitcoin/bitcoin/commit/342e1b73385cac5a5b2fc7316d82a2b55b3a85d4","f":[["init.cpp",2,2,null,0,0],["json/json_spirit_value.h",1,1,null,0,0],["json/json_spirit_writer_template.h",4,1,null,0,0],["rpc.cpp",41,52,null,0,0]]},{"id":"cfb83d28768","sha":"fb83d28768e62eb46f83d15afaf67bdfb4675d9d","d":1281480923,"s":"gethashespersec and added version and hashespersec to getinfo","r":127,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":41,"del":12,"u":"https://github.com/bitcoin/bitcoin/commit/fb83d28768e62eb46f83d15afaf67bdfb4675d9d","f":[["main.cpp",19,10,null,0,0],["main.h",2,0,null,0,0],["rpc.cpp",19,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c0cff7a8aa7","sha":"0cff7a8aa706d0e8ded5a58e1035f3db8f711c45","d":1281483817,"s":"disable SSE2 on 32-bit","r":128,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":7,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/0cff7a8aa706d0e8ded5a58e1035f3db8f711c45","f":[["cryptopp/config.h",7,0,null,0,0]]},{"id":"c4287732797","sha":"42877327973889c6a99f07025bd1bc72cf6dd2b7","d":1281490704,"s":"fix build, thanks jgarzik","r":129,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/42877327973889c6a99f07025bd1bc72cf6dd2b7","f":[["rpc.cpp",2,2,null,0,0]]},{"id":"c410b618d18","sha":"410b618d18d712db680de8f173a671bb637ff2b0","d":1281619257,"s":"json-spirit print reals with 8 decimal places, bitcoind help <command> instead of bitcoind <command> -?","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":4,"ins":48,"del":56,"u":"https://github.com/bitcoin/bitcoin/commit/410b618d18d712db680de8f173a671bb637ff2b0","f":[["init.cpp",2,2,null,0,0],["json/json_spirit_value.h",1,1,null,0,0],["json/json_spirit_writer_template.h",4,1,null,0,0],["rpc.cpp",41,52,null,0,0]]},{"id":"c9db7bf5f52","sha":"9db7bf5f52194b0018272ce3f719115f8637da5c","d":1281619382,"s":"gethashespersec and added version and hashespersec to getinfo","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":4,"ins":41,"del":12,"u":"https://github.com/bitcoin/bitcoin/commit/9db7bf5f52194b0018272ce3f719115f8637da5c","f":[["main.cpp",19,10,null,0,0],["main.h",2,0,null,0,0],["rpc.cpp",19,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cf5d2bc8a36","sha":"f5d2bc8a36dda0bd80a44afaab5fb3c0323d2da2","d":1281619580,"s":"disable SSE2 on 32-bit","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":7,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/f5d2bc8a36dda0bd80a44afaab5fb3c0323d2da2","f":[["cryptopp/config.h",7,0,null,0,0]]},{"id":"c819adfff6f","sha":"819adfff6fda7ba2ccf5c4b9fb8b5fdc7a1b535c","d":1281619702,"s":"fix build, thanks jgarzik","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/819adfff6fda7ba2ccf5c4b9fb8b5fdc7a1b535c","f":[["rpc.cpp",2,2,null,0,0]]},{"id":"c01cd2fdaf3","sha":"01cd2fdaf3ac6071304ceb80fb7436ac02b1059e","d":1281647623,"s":"fix -datadir=./subdir relative path, autostart off by default except on windows, fix occasional \"vector iterator not dereferencable\" assertion with msvc, fix readlink compile warning on linux build, use sys/param.h and BSD define instead of __BSD__, -paytxfee switch","r":130,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":20,"ins":132,"del":39,"u":"https://github.com/bitcoin/bitcoin/commit/01cd2fdaf3ac6071304ceb80fb7436ac02b1059e","f":[["headers.h",9,7,null,0,0],["init.cpp",14,2,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["main.cpp",1,1,null,0,0],["net.cpp",28,2,null,0,0],["rpc.cpp",2,2,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",8,6,null,0,0],["util.h",9,6,null,0,0]]},{"id":"c7f71fd13ae","sha":"7f71fd13ae5c61bf844591d93e74803e85601931","d":1281666226,"s":"fix -datadir=./subdir relative path, autostart off by default except on windows, fix occasional \"vector iterator not dereferencable\" assertion with msvc, fix readlink compile warning on linux build, use sys/param.h and BSD define instead of __BSD__, -paytxfee switch","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":20,"ins":132,"del":39,"u":"https://github.com/bitcoin/bitcoin/commit/7f71fd13ae5c61bf844591d93e74803e85601931","f":[["headers.h",9,7,null,0,0],["init.cpp",14,2,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",10,2,null,0,0],["main.cpp",1,1,null,0,0],["net.cpp",28,2,null,0,0],["rpc.cpp",2,2,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",8,6,null,0,0],["util.h",9,6,null,0,0]]},{"id":"c4bd188c438","sha":"4bd188c4383d6e614e18f79dc337fbabe8464c82","d":1281906316,"s":"misc changes","r":131,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":538,"del":52,"u":"https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82","f":[["init.cpp",2,0,null,0,0],["main.cpp",51,21,null,0,0],["main.h",2,1,null,0,0],["script.cpp",51,25,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0],["sha256.cpp",419,0,null,120,0],["util.cpp",8,0,null,0,0]]},{"id":"cd4c6b90ca3","sha":"d4c6b90ca3f9b47adb1b2724a0c3514f80635c84","d":1281908124,"s":"fix for block 74638 overflow output transaction","r":132,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":19,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/d4c6b90ca3f9b47adb1b2724a0c3514f80635c84","f":[["main.cpp",8,0,null,0,0],["main.h",10,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c85de7d7c0c","sha":"85de7d7c0cbb1e9aa311606644b697674c84f6f9","d":1281910863,"s":"scanback check to prevent adding to the 74638 overflow chain","r":133,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":11,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/85de7d7c0cbb1e9aa311606644b697674c84f6f9","f":[["main.cpp",10,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c08fee75201","sha":"08fee75201e82f2e34fcc1549ee8edd152f5d040","d":1281912418,"s":"makefile.unix to build with option to enable tcatm's 4-way SSE2 SHA-256 with -4way switch on Linux -- version 0.3.10 release","r":134,"rel":"v0.3.10","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":9,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/08fee75201e82f2e34fcc1549ee8edd152f5d040","f":[["makefile.unix",6,3,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c6ac7f9f144","sha":"6ac7f9f144757f5f1a049c059351b978f83d1476","d":1281913565,"s":"misc changes","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":8,"ins":538,"del":58,"u":"https://github.com/bitcoin/bitcoin/commit/6ac7f9f144757f5f1a049c059351b978f83d1476","f":[["init.cpp",2,0,null,0,0],["main.cpp",51,21,null,0,0],["main.h",2,7,null,0,0],["script.cpp",51,25,null,0,0],["serialize.h",2,2,null,0,0],["setup.nsi",3,3,null,0,0],["sha256.cpp",419,0,null,120,0],["util.cpp",8,0,null,0,0]]},{"id":"c76793dc969","sha":"76793dc969f5ee9feadb6827845c1682b11914a6","d":1281913769,"s":"fix for block 74638 overflow output transaction","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":3,"ins":19,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/76793dc969f5ee9feadb6827845c1682b11914a6","f":[["main.cpp",8,0,null,0,0],["main.h",10,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"ce540144b2e","sha":"e540144b2eeb009db254766f13692ca741257b01","d":1281964292,"s":"added -march=amdfam10 to sha256.cpp in makefile.unix","r":135,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/e540144b2eeb009db254766f13692ca741257b01","f":[["makefile.unix",1,1,null,0,0]]},{"id":"c6da916d4ac","sha":"6da916d4acf0c26be81b4547da0e4160d53aacc8","d":1281965820,"s":"wrap sha256.cpp in FOURWAYSSE2 #ifdef","r":136,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":4,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/6da916d4acf0c26be81b4547da0e4160d53aacc8","f":[["sha256.cpp",4,0,null,0,0]]},{"id":"c15399da9fe","sha":"15399da9fe29336f119121340146d78973b601a5","d":1281978350,"s":"blocks-1, verify block chain on load, so wouldn't have needed to delete blk*.dat, it would have done a reorg automatically","r":137,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":81,"del":48,"u":"https://github.com/bitcoin/bitcoin/commit/15399da9fe29336f119121340146d78973b601a5","f":[["db.cpp",23,0,null,0,0],["main.cpp",53,44,null,0,0],["main.h",1,0,null,0,0],["rpc.cpp",2,2,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"ca01d5876fa","sha":"a01d5876fa6a9a9fe28cff3ad3ed0e91d5612125","d":1281981070,"s":"erase the bad chain after disconnecting it","r":138,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":12,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/a01d5876fa6a9a9fe28cff3ad3ed0e91d5612125","f":[["db.cpp",12,0,null,0,0]]},{"id":"c44a0de1861","sha":"44a0de1861a78a693ad3331f0f7b06003a78a9d7","d":1281984362,"s":"do an extra CheckBlock in ConnectBlock","r":139,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":6,"del":13,"u":"https://github.com/bitcoin/bitcoin/commit/44a0de1861a78a693ad3331f0f7b06003a78a9d7","f":[["db.cpp",1,12,null,0,0],["main.cpp",4,0,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c7d489192fd","sha":"7d489192fd74f9e739d2d95c4e58f26361a30bcc","d":1281991837,"s":"makefile.unix to build with option to enable tcatm's 4-way SSE2 SHA-256 with -4way switch on Linux","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":2,"ins":9,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/7d489192fd74f9e739d2d95c4e58f26361a30bcc","f":[["makefile.unix",6,3,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c019b456605","sha":"019b456605f90f13cdc8ecc02aa8492b4e65846e","d":1281991906,"s":"added -march=amdfam10 to sha256.cpp in makefile.unix","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/019b456605f90f13cdc8ecc02aa8492b4e65846e","f":[["makefile.unix",1,1,null,0,0]]},{"id":"cc923cdbd5b","sha":"c923cdbd5b5d143a77ee5f2c3f0bd72aa4f1716e","d":1281991956,"s":"wrap sha256.cpp in FOURWAYSSE2 #ifdef","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":4,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/c923cdbd5b5d143a77ee5f2c3f0bd72aa4f1716e","f":[["sha256.cpp",4,0,null,0,0]]},{"id":"cbb3fd02930","sha":"bb3fd02930ba5cb8e8a3a92ede9612955edeee05","d":1281992029,"s":"blocks-1, verify block chain on load, so wouldn't have needed to delete blk*.dat, it would have done a reorg automatically","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":6,"ins":91,"del":49,"u":"https://github.com/bitcoin/bitcoin/commit/bb3fd02930ba5cb8e8a3a92ede9612955edeee05","f":[["db.cpp",23,0,null,0,0],["main.cpp",63,45,null,0,0],["main.h",1,0,null,0,0],["rpc.cpp",2,2,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"c21ca2d833b","sha":"21ca2d833b85673c482803b1c382bbe948b2c44a","d":1281992087,"s":"erase the bad chain after disconnecting it","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":12,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/21ca2d833b85673c482803b1c382bbe948b2c44a","f":[["db.cpp",12,0,null,0,0]]},{"id":"c43deefa435","sha":"43deefa4355981e53f4fdfe9aa1c4003941e2a8e","d":1281992154,"s":"do an extra CheckBlock in ConnectBlock","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":3,"ins":6,"del":13,"u":"https://github.com/bitcoin/bitcoin/commit/43deefa4355981e53f4fdfe9aa1c4003941e2a8e","f":[["db.cpp",1,12,null,0,0],["main.cpp",4,0,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c05454818dc","sha":"05454818dc7ed92f577a1a1ef6798049f17a52e7","d":1282257799,"s":"block index checking on load, extra redundant checks, misc refactoring","r":140,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":126,"del":62,"u":"https://github.com/bitcoin/bitcoin/commit/05454818dc7ed92f577a1a1ef6798049f17a52e7","f":[["db.cpp",8,3,null,0,0],["main.cpp",62,36,null,0,0],["main.h",47,21,null,0,0],["net.h",1,1,null,0,0],["serialize.h",8,1,null,0,0]]},{"id":"c2201a0808e","sha":"2201a0808ea240617a66823f98dda3433d2546b0","d":1282323314,"s":"warning message if clock is too far off","r":141,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":64,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/2201a0808ea240617a66823f98dda3433d2546b0","f":[["main.cpp",4,4,null,0,0],["noui.h",31,3,null,0,0],["rpc.cpp",1,0,null,0,0],["serialize.h",1,1,null,0,0],["util.cpp",21,6,null,0,0],["util.h",6,0,null,0,0]]},{"id":"c401926283a","sha":"401926283a200994ecd7df8eae8ced8e0b067c46","d":1282694737,"s":"alert system -- version 0.3.11","r":142,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":409,"del":86,"u":"https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46","f":[["main.cpp",156,44,null,54,0],["main.h",214,4,null,0,0],["net.h",4,1,null,0,0],["rpc.cpp",4,3,null,0,0],["serialize.h",6,3,null,0,0],["ui.cpp",7,6,null,0,0],["util.cpp",13,24,null,0,0],["util.h",5,1,null,0,0]]},{"id":"c7d7797b141","sha":"7d7797b141dbd4ed9db1dda94684beb3395c2534","d":1282745936,"s":"more rpc methods allowed in safe mode","r":143,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":21,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/7d7797b141dbd4ed9db1dda94684beb3395c2534","f":[["rpc.cpp",21,2,null,0,0]]},{"id":"c2ef9cfa5b8","sha":"2ef9cfa5b81877b1023f2fcb82f5a638b1eb013c","d":1282754018,"s":"change switch name to -disablesafemode","r":144,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/2ef9cfa5b81877b1023f2fcb82f5a638b1eb013c","f":[["rpc.cpp",2,2,null,0,0]]},{"id":"c5b721607b1","sha":"5b721607b1057df4dfe97f80d235ed372312f398","d":1282758789,"s":"added -testsafemode switch -- version 0.3.11 release","r":145,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":2,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/5b721607b1057df4dfe97f80d235ed372312f398","f":[["main.cpp",2,0,null,0,0]]},{"id":"c7a37c906a1","sha":"7a37c906a1c712fe1dbfddc0723d132fdb95f75f","d":1282956570,"s":"block index checking on load, extra redundant checks, misc refactoring","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":5,"ins":126,"del":62,"u":"https://github.com/bitcoin/bitcoin/commit/7a37c906a1c712fe1dbfddc0723d132fdb95f75f","f":[["db.cpp",8,3,null,0,0],["main.cpp",62,36,null,0,0],["main.h",47,21,null,0,0],["net.h",1,1,null,0,0],["serialize.h",8,1,null,0,0]]},{"id":"cc545563d46","sha":"c545563d46b965583794e96f63326c54f1cf8d70","d":1282956640,"s":"warning message if clock is too far off","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":6,"ins":64,"del":14,"u":"https://github.com/bitcoin/bitcoin/commit/c545563d46b965583794e96f63326c54f1cf8d70","f":[["main.cpp",4,4,null,0,0],["noui.h",31,3,null,0,0],["rpc.cpp",1,0,null,0,0],["serialize.h",1,1,null,0,0],["util.cpp",21,6,null,0,0],["util.h",6,0,null,0,0]]},{"id":"c522dfe3422","sha":"522dfe3422f562368ebdaeb2b1a13cc9ebafa333","d":1282956712,"s":"alert system -- version 0.3.11","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":8,"ins":409,"del":86,"u":"https://github.com/bitcoin/bitcoin/commit/522dfe3422f562368ebdaeb2b1a13cc9ebafa333","f":[["main.cpp",156,44,null,54,0],["main.h",214,4,null,0,0],["net.h",4,1,null,0,0],["rpc.cpp",4,3,null,0,0],["serialize.h",6,3,null,0,0],["ui.cpp",7,6,null,0,0],["util.cpp",13,24,null,0,0],["util.h",5,1,null,0,0]]},{"id":"c87cfcfd374","sha":"87cfcfd3741e0cd38da671db79b199fe5bfb2949","d":1282956877,"s":"more rpc methods allowed in safe mode","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":21,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/87cfcfd3741e0cd38da671db79b199fe5bfb2949","f":[["rpc.cpp",21,2,null,0,0]]},{"id":"cd3631907d6","sha":"d3631907d62f605b725b4cc433173cec15c9d082","d":1282956919,"s":"change switch name to -disablesafemode","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/d3631907d62f605b725b4cc433173cec15c9d082","f":[["rpc.cpp",2,2,null,0,0]]},{"id":"c343328c6b8","sha":"343328c6b8db85e58a1feea85f0d10e62967fa19","d":1282956950,"s":"added -testsafemode switch -- version 0.3.11 release","r":null,"rel":"v0.3.11_notexact","cn":"Gavin Andresen","who":"Satoshi Nakamoto","fc":1,"ins":2,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/343328c6b8db85e58a1feea85f0d10e62967fa19","f":[["main.cpp",2,0,null,0,0]]},{"id":"c0a61b0df12","sha":"0a61b0df1224a5470bcddab302bc199ca5a9e356","d":1283101095,"s":"propset svn:eol-style native","r":146,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":65,"ins":31004,"del":31004,"u":"https://github.com/bitcoin/bitcoin/commit/0a61b0df1224a5470bcddab302bc199ca5a9e356","f":[["base58.h",201,201,null,103,0],["bignum.h",532,532,null,765,0],["build-msw.txt",114,114,null,0,0],["build-osx.txt",217,217,null,135,0],["build-unix.txt",80,80,null,0,0],["cryptopp/License.txt",67,67,null,0,0],["cryptopp/Readme.txt",429,429,null,784,0],["cryptopp/config.h",462,462,null,925,0],["cryptopp/cpu.cpp",199,199,null,399,0],["cryptopp/cpu.h",263,263,null,527,0],["cryptopp/cryptlib.h",1668,1668,null,3337,0],["cryptopp/iterhash.h",29,29,null,59,0],["cryptopp/misc.h",1134,1134,null,2269,0],["cryptopp/pch.h",21,21,null,43,0],["cryptopp/secblock.h",500,500,null,1001,0],["cryptopp/sha.cpp",899,899,null,1799,0],["cryptopp/sha.h",63,63,null,127,0],["cryptopp/simple.h",1,1,null,3,0],["cryptopp/smartptr.h",223,223,null,447,0],["cryptopp/stdcpp.h",27,27,null,55,0],["db.cpp",805,805,null,1611,0],["db.h",406,406,null,813,0],["headers.h",144,144,null,289,0],["init.cpp",405,405,null,811,0],["init.h",7,7,null,15,0],["irc.cpp",328,328,null,657,0],["irc.h",8,8,null,17,0],["json/LICENSE.txt",24,24,null,49,0],["json/json_spirit.h",18,18,null,37,0],["json/json_spirit_error_position.h",54,54,null,109,0],["json/json_spirit_reader.cpp",137,137,null,275,0],["json/json_spirit_reader.h",62,62,null,125,0],["json/json_spirit_reader_template.h",612,612,null,1225,0],["json/json_spirit_stream_reader.h",70,70,null,141,0],["json/json_spirit_utils.h",61,61,null,123,0],["json/json_spirit_value.cpp",8,8,null,17,0],["json/json_spirit_value.h",534,534,null,1069,0],["json/json_spirit_writer.cpp",95,95,null,191,0],["json/json_spirit_writer.h",50,50,null,101,0],["json/json_spirit_writer_template.h",248,248,null,497,0],["key.h",168,168,null,337,0],["license.txt",19,19,null,39,0],["main.cpp",3381,3381,null,6763,0],["main.h",1689,1689,null,3379,0],["makefile.mingw",77,77,null,155,0],["makefile.osx",72,72,null,145,0],["makefile.unix",74,74,null,149,0],["makefile.vc",116,116,null,233,0],["net.cpp",1466,1466,null,2933,0],["net.h",1055,1055,null,2111,0],["noui.h",62,62,null,125,0],["rpc.cpp",1202,1202,null,2405,0],["rpc.h",6,6,null,13,0],["script.cpp",1198,1198,null,2397,0],["script.h",665,665,null,1331,0],["serialize.h",1185,1185,null,2371,0],["sha256.cpp",423,423,null,847,0],["strlcpy.h",84,84,null,169,0],["ui.cpp",2908,2908,null,5817,0],["ui.h",346,346,null,693,0],["uibase.cpp",1073,1073,null,2147,0],["uibase.h",422,422,null,845,0],["uint256.h",757,757,null,1515,0],["util.cpp",762,762,null,1525,0],["util.h",589,589,null,1179,0]]},{"id":"cd743f03552","sha":"d743f0355269e2e03fe3f982e250d07999d72b98","d":1283806984,"s":"Gavin Andresen: json-rpc return standard error objects with error code numbers, json-rpc command line client return exit code, added rpc backupwallet command","r":147,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":186,"del":83,"u":"https://github.com/bitcoin/bitcoin/commit/d743f0355269e2e03fe3f982e250d07999d72b98","f":[["db.cpp",31,2,null,0,0],["db.h",1,0,null,0,0],["rpc.cpp",151,79,null,89,0],["serialize.h",3,2,null,0,0]]},{"id":"cf1e1fb4bde","sha":"f1e1fb4bdef878c8fc1564fa418d44e7541a7e83","d":1283821973,"s":"cleanup, catch some recoverable exceptions and continue","r":148,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":350,"del":278,"u":"https://github.com/bitcoin/bitcoin/commit/f1e1fb4bdef878c8fc1564fa418d44e7541a7e83","f":[["cryptopp/secblock.h",2,1,null,0,0],["db.cpp",6,1,null,0,0],["init.cpp",2,2,null,0,0],["irc.cpp",20,0,null,0,0],["main.cpp",61,38,null,0,0],["main.h",35,15,null,0,0],["makefile.unix",3,1,null,0,0],["net.cpp",0,53,null,0,0],["net.h",2,3,null,0,0],["script.cpp",55,57,null,35,0],["script.h",102,76,null,49,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["sha256.cpp",2,0,null,0,0],["ui.cpp",0,3,null,0,0],["ui.h",2,2,null,0,0],["util.cpp",30,6,null,0,0],["util.h",24,16,null,0,0]]},{"id":"c8c9479c6bb","sha":"8c9479c6bbbc38b897dc97de9d04e4d5a5a36730","d":1283821973,"s":"cleanup, catch some recoverable exceptions and continue -- version 0.3.12 release","r":148,"rel":"v0.3.12","cn":"s_nakamoto","who":"s_nakamoto","fc":18,"ins":350,"del":278,"u":"https://github.com/bitcoin/bitcoin/commit/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730","f":[["cryptopp/secblock.h",2,1,null,0,0],["db.cpp",6,1,null,0,0],["init.cpp",2,2,null,0,0],["irc.cpp",20,0,null,0,0],["main.cpp",61,38,null,0,0],["main.h",35,15,null,0,0],["makefile.unix",3,1,null,0,0],["net.cpp",0,53,null,0,0],["net.h",2,3,null,0,0],["script.cpp",55,57,null,35,0],["script.h",102,76,null,49,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["sha256.cpp",2,0,null,0,0],["ui.cpp",0,3,null,0,0],["ui.h",2,2,null,0,0],["util.cpp",30,6,null,0,0],["util.h",24,16,null,0,0]]},{"id":"c3f64753779","sha":"3f647537790e02e892701f4bb2586ccd964c2631","d":1283973872,"s":"Gavin Andresen: clean shutdown on SIGTERM","r":149,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":18,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/3f647537790e02e892701f4bb2586ccd964c2631","f":[["headers.h",1,0,null,0,0],["init.cpp",13,1,null,0,0],["net.cpp",2,0,null,0,0],["util.cpp",1,0,null,0,0],["util.h",1,0,null,0,0]]},{"id":"c14002c8eba","sha":"14002c8eba6fe03bec721bcacf4bed0b3cbca6d5","d":1283973872,"s":"Gavin Andresen: clean shutdown on SIGTERM","r":149,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":18,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/14002c8eba6fe03bec721bcacf4bed0b3cbca6d5","f":[["headers.h",1,0,null,0,0],["init.cpp",13,1,null,0,0],["net.cpp",2,0,null,0,0],["util.cpp",1,0,null,0,0],["util.h",1,0,null,0,0]]},{"id":"c7629d36a53","sha":"7629d36a530087806e80ed3c5866e8ec64319828","d":1283994040,"s":"try to auto-detect whether to use 128-bit 4-way SSE2","r":150,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":71,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/7629d36a530087806e80ed3c5866e8ec64319828","f":[["cryptopp/secblock.h",2,2,null,0,0],["main.cpp",65,1,null,0,0],["net.cpp",3,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c8555125a1a","sha":"8555125a1a1af68c9a89b7d4f9447d19ed1736ca","d":1283994040,"s":"try to auto-detect whether to use 128-bit 4-way SSE2","r":150,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":71,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/8555125a1a1af68c9a89b7d4f9447d19ed1736ca","f":[["cryptopp/secblock.h",2,2,null,0,0],["main.cpp",65,1,null,0,0],["net.cpp",3,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c4968232490","sha":"4968232490896f522065b2526ffa8648ce2358cd","d":1284137939,"s":"fix problem sending the last cent with sub-cent fractional change","r":151,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":7,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/4968232490896f522065b2526ffa8648ce2358cd","f":[["main.cpp",5,4,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"c00728c24e7","sha":"00728c24e7866963c78360c1df8c182f3c19c2e0","d":1284137939,"s":"fix problem sending the last cent with sub-cent fractional change","r":151,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":7,"del":6,"u":"https://github.com/bitcoin/bitcoin/commit/00728c24e7866963c78360c1df8c182f3c19c2e0","f":[["main.cpp",5,4,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,1,null,0,0]]},{"id":"cc39b06866e","sha":"c39b06866eea2a17785d18e0c24f915606bd25bc","d":1284142068,"s":"fix build on non-intel architectures, thanks teknohog","r":152,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/c39b06866eea2a17785d18e0c24f915606bd25bc","f":[["main.cpp",1,1,null,0,0]]},{"id":"c2323664a37","sha":"2323664a37f9336380741399b4c731c22478c617","d":1284142068,"s":"fix build on non-intel architectures, thanks teknohog","r":152,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":1,"ins":1,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/2323664a37f9336380741399b4c731c22478c617","f":[["main.cpp",1,1,null,0,0]]},{"id":"cfdbf76d4f4","sha":"fdbf76d4f49c220e2ed4412a3d8d8cd6efd74826","d":1284312615,"s":"dropped DB_PRIVATE from dbenv.open","r":153,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":1,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/fdbf76d4f49c220e2ed4412a3d8d8cd6efd74826","f":[["db.cpp",0,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cc8ad9b8375","sha":"c8ad9b8375f5308bb46a124f096a80926ea42fba","d":1284312615,"s":"dropped DB_PRIVATE from dbenv.open","r":153,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":1,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/c8ad9b8375f5308bb46a124f096a80926ea42fba","f":[["db.cpp",0,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c3df62878c3","sha":"3df62878c3cece15a8921fbbdee7859ee9368768","d":1284416064,"s":"reorganize BitcoinMiner to make it easier to add different SHA256 routines","r":154,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":175,"del":113,"u":"https://github.com/bitcoin/bitcoin/commit/3df62878c3cece15a8921fbbdee7859ee9368768","f":[["main.cpp",121,110,null,13,0],["main.h",2,1,null,0,0],["serialize.h",1,1,null,0,0],["sha256.cpp",51,1,null,0,0]]},{"id":"c71cc095cb2","sha":"71cc095cb26c4967ed9e9ebf89b6eb1e685c3844","d":1284416064,"s":"reorganize BitcoinMiner to make it easier to add different SHA256 routines","r":154,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":175,"del":113,"u":"https://github.com/bitcoin/bitcoin/commit/71cc095cb26c4967ed9e9ebf89b6eb1e685c3844","f":[["main.cpp",121,110,null,13,0],["main.h",2,1,null,0,0],["serialize.h",1,1,null,0,0],["sha256.cpp",51,1,null,0,0]]},{"id":"cefae3da41d","sha":"efae3da41d821b12d1481de8b8e0b2e105d36ae3","d":1284588613,"s":"config option -rpcallowip= to accept json-rpc connections from another machine","r":155,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":76,"del":22,"u":"https://github.com/bitcoin/bitcoin/commit/efae3da41d821b12d1481de8b8e0b2e105d36ae3","f":[["main.cpp",0,5,null,0,0],["rpc.cpp",18,6,null,0,0],["serialize.h",1,1,null,0,0],["util.cpp",39,9,null,0,0],["util.h",18,1,null,0,0]]},{"id":"cfe37c35018","sha":"fe37c350185c946cb735d1415c124657e7839558","d":1284588613,"s":"config option -rpcallowip= to accept json-rpc connections from another machine","r":155,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":76,"del":22,"u":"https://github.com/bitcoin/bitcoin/commit/fe37c350185c946cb735d1415c124657e7839558","f":[["main.cpp",0,5,null,0,0],["rpc.cpp",18,6,null,0,0],["serialize.h",1,1,null,0,0],["util.cpp",39,9,null,0,0],["util.h",18,1,null,0,0]]},{"id":"c172f006020","sha":"172f006020965ae8763a0610845c051ed1e3b522","d":1284931234,"s":"only accept transactions sent by IP address if -allowreceivebyip is specified","r":156,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":30,"del":18,"u":"https://github.com/bitcoin/bitcoin/commit/172f006020965ae8763a0610845c051ed1e3b522","f":[["main.cpp",23,15,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",6,2,null,0,0]]},{"id":"c6aeb45187b","sha":"6aeb45187b9bdc824fa37aee98aa99d472b6f060","d":1284931234,"s":"only accept transactions sent by IP address if -allowreceivebyip is specified","r":156,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":30,"del":18,"u":"https://github.com/bitcoin/bitcoin/commit/6aeb45187b9bdc824fa37aee98aa99d472b6f060","f":[["main.cpp",23,15,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",6,2,null,0,0]]},{"id":"c9b8eb4d690","sha":"9b8eb4d6907502e9b1e74b62a850a11655d50ab5","d":1285257704,"s":"changed free transactions per block threshold","r":157,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":23,"del":16,"u":"https://github.com/bitcoin/bitcoin/commit/9b8eb4d6907502e9b1e74b62a850a11655d50ab5","f":[["main.cpp",2,2,null,0,0],["main.h",20,13,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c8d13ca1f11","sha":"8d13ca1f11c206188e016546e5ebf7c18c884021","d":1285257704,"s":"changed free transactions per block threshold","r":157,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":23,"del":16,"u":"https://github.com/bitcoin/bitcoin/commit/8d13ca1f11c206188e016546e5ebf7c18c884021","f":[["main.cpp",2,2,null,0,0],["main.h",20,13,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"ca790fa46f4","sha":"a790fa46f40d751307f86c37a709eb119768ce5b","d":1285863787,"s":"don't count or spend payments until they have 1 confirmation, misc cleanup, changed internal version number from 312 to 31300 -- version 0.3.13","r":158,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":22,"ins":187,"del":130,"u":"https://github.com/bitcoin/bitcoin/commit/a790fa46f40d751307f86c37a709eb119768ce5b","f":[["db.cpp",1,1,null,0,0],["init.cpp",1,1,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",2,2,null,0,0],["main.cpp",52,11,null,0,0],["main.h",38,62,null,0,0],["script.cpp",8,0,null,0,0],["serialize.h",21,27,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",42,11,null,0,0],["ui.h",1,2,null,0,0],["util.h",8,0,null,0,0]]},{"id":"c178152f604","sha":"178152f604aed37df703336344ff334e6d0fd244","d":1285890855,"s":"fixed linux build, dkaparis: _WIN32_WINNT 0x500 -- version 0.3.13 release","r":159,"rel":"v0.3.13","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":3,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/178152f604aed37df703336344ff334e6d0fd244","f":[["headers.h",1,1,null,0,0],["ui.cpp",2,0,null,0,0]]},{"id":"cdc8adc3b48","sha":"dc8adc3b48bb2201f2bd796a5ffa0733c30aa6e1","d":1286156450,"s":"Russian translation by eurekafag","r":160,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":849,"del":0,"u":"https://github.com/bitcoin/bitcoin/commit/dc8adc3b48bb2201f2bd796a5ffa0733c30aa6e1","f":[["locale/ru/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/ru/LC_MESSAGES/bitcoin.po",845,0,null,546,0],["main.cpp",4,0,null,0,0]]},{"id":"cb22c884231","sha":"b22c88423160d026e93130e606d2e1afc4ca40d5","d":1286331587,"s":"recursive function to determine if own unconfirmed transaction can be spent","r":161,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":4,"ins":83,"del":52,"u":"https://github.com/bitcoin/bitcoin/commit/b22c88423160d026e93130e606d2e1afc4ca40d5","f":[["main.cpp",39,29,null,0,0],["main.h",36,5,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",7,17,null,0,0]]},{"id":"c0a27bd065e","sha":"0a27bd065e4803a35e436c610bedb06fe39123c6","d":1286379784,"s":"updated Russian translation","r":162,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":238,"del":188,"u":"https://github.com/bitcoin/bitcoin/commit/0a27bd065e4803a35e436c610bedb06fe39123c6","f":[["locale/ru/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/ru/LC_MESSAGES/bitcoin.po",238,188,null,565,0]]},{"id":"c103849419a","sha":"103849419a9c014a69c76b6f96e48b66cbc838ca","d":1286652815,"s":"key pool for safer wallet backup","r":163,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":198,"del":57,"u":"https://github.com/bitcoin/bitcoin/commit/103849419a9c014a69c76b6f96e48b66cbc838ca","f":[["db.cpp",65,0,null,0,0],["db.h",81,0,null,0,0],["irc.cpp",4,2,null,0,0],["main.cpp",27,34,null,0,0],["main.h",3,3,null,0,0],["rpc.cpp",1,1,null,0,0],["serialize.h",8,8,null,0,0],["ui.cpp",9,9,null,0,0]]},{"id":"c83082f04a4","sha":"83082f04a47d6540f40dd656d1baed54eb17e76b","d":1286809937,"s":"dkaparis: boost::bind build fix for c++0x","r":164,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":12,"del":7,"u":"https://github.com/bitcoin/bitcoin/commit/83082f04a47d6540f40dd656d1baed54eb17e76b","f":[["main.cpp",10,5,null,0,0],["util.cpp",2,2,null,0,0]]},{"id":"c5cbf75324d","sha":"5cbf75324d1509a1262b65c5073314a4da3f6d77","d":1287508611,"s":"Gavin's TEST network as -testnet switch, misc fixes","r":168,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":14,"ins":155,"del":82,"u":"https://github.com/bitcoin/bitcoin/commit/5cbf75324d1509a1262b65c5073314a4da3f6d77","f":[["base58.h",1,1,null,0,0],["db.cpp",8,1,null,0,0],["db.h",2,1,null,0,0],["init.cpp",22,16,null,0,0],["irc.cpp",2,2,null,0,0],["main.cpp",67,35,null,0,0],["main.h",2,2,null,0,0],["net.cpp",1,1,null,0,0],["net.h",1,4,null,0,0],["script.cpp",4,9,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",1,0,null,0,0],["util.cpp",18,9,null,0,0],["util.h",25,0,null,0,0]]},{"id":"cd9c6b09ac4","sha":"d9c6b09ac42d21abd151a0feaff676b8a8a24bb9","d":1287591143,"s":"Gavin Andresen: multiple instance check, -testnet use port 18333","r":170,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":27,"del":21,"u":"https://github.com/bitcoin/bitcoin/commit/d9c6b09ac42d21abd151a0feaff676b8a8a24bb9","f":[["build-msw.txt",2,6,null,0,0],["headers.h",1,0,null,0,0],["init.cpp",12,4,null,0,0],["net.cpp",7,6,null,0,0],["net.h",5,5,null,0,0]]},{"id":"c2ce73dbe85","sha":"2ce73dbe8546b0bfb5e512a6b11e201871374147","d":1287679636,"s":"-- version 0.3.14 release","r":171,"rel":"v0.3.14","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":5,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/2ce73dbe8546b0bfb5e512a6b11e201871374147","f":[["main.cpp",1,1,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"cc891967b6f","sha":"c891967b6fcab2e8dc4ce0c787312b36c07efa4d","d":1287855833,"s":"bugfixes from Dean Gores, addr system changes, make sure no gen before block 74000","r":173,"rel":"v0.3.15","cn":"s_nakamoto","who":"s_nakamoto","fc":8,"ins":109,"del":63,"u":"https://github.com/bitcoin/bitcoin/commit/c891967b6fcab2e8dc4ce0c787312b36c07efa4d","f":[["db.cpp",5,5,null,0,0],["db.h",1,0,null,0,0],["irc.cpp",24,11,null,0,0],["main.cpp",67,12,null,0,0],["net.cpp",3,21,null,0,0],["net.h",7,13,null,0,0],["rpc.cpp",1,0,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c461764cbbe","sha":"461764cbbea5965ebbd248f221876743d7a9ccd4","d":1289253967,"s":"-paytxfee is now per KB, BitcoinMiner prioritise transactions by how old their dependencies are","r":176,"rel":"v0.3.15","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":119,"del":27,"u":"https://github.com/bitcoin/bitcoin/commit/461764cbbea5965ebbd248f221876743d7a9ccd4","f":[["build-msw.txt",2,3,null,0,0],["init.cpp",2,1,null,0,0],["main.cpp",102,17,null,0,0],["main.h",5,3,null,0,0],["serialize.h",1,1,null,0,0],["ui.cpp",7,2,null,0,0]]},{"id":"ce2a186af10","sha":"e2a186af10d81a0e27b2e7c34783711d65caeae7","d":1289332027,"s":"SelectCoins first pass tries not to use coins with less than 6 confirmations","r":177,"rel":"v0.3.15","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":34,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/e2a186af10d81a0e27b2e7c34783711d65caeae7","f":[["main.cpp",13,1,null,0,0],["main.h",21,1,null,0,0]]},{"id":"c910bd45756","sha":"910bd45756dda126465cfdf13b4833e0356808ff","d":1289693170,"s":"-- version 0.3.15 release","r":179,"rel":"v0.3.15","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":4,"del":4,"u":"https://github.com/bitcoin/bitcoin/commit/910bd45756dda126465cfdf13b4833e0356808ff","f":[["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0]]},{"id":"c683bcb9154","sha":"683bcb9154422011ef01e8c5677bad2c4b323436","d":1290198166,"s":"efficiently sort transaction dependencies in one pass","r":184,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":97,"del":48,"u":"https://github.com/bitcoin/bitcoin/commit/683bcb9154422011ef01e8c5677bad2c4b323436","f":[["main.cpp",85,36,null,0,0],["net.cpp",11,11,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"cf35e21e2e4","sha":"f35e21e2e4fcc0aa52edd9f9b58bd19e347597da","d":1290209825,"s":"require some minimal priority for free transactions to slow down transaction spam","r":185,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":17,"del":12,"u":"https://github.com/bitcoin/bitcoin/commit/f35e21e2e4fcc0aa52edd9f9b58bd19e347597da","f":[["main.cpp",4,2,null,0,0],["main.h",12,9,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c51d9b435cd","sha":"51d9b435cd1fc6efe5fc418e8adb48ef33c9e836","d":1290219123,"s":"small bugfix","r":186,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":2,"del":2,"u":"https://github.com/bitcoin/bitcoin/commit/51d9b435cd1fc6efe5fc418e8adb48ef33c9e836","f":[["main.cpp",1,1,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c298a771494","sha":"298a7714943dc3f1ebc582ed2426d3b71fb68466","d":1290379579,"s":"added transaction fee setting in UI options menu, cut free transaction area from 50KB to 26KB","r":187,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":224,"del":219,"u":"https://github.com/bitcoin/bitcoin/commit/298a7714943dc3f1ebc582ed2426d3b71fb68466","f":[["db.cpp",0,8,null,0,0],["main.h",13,8,null,0,0],["serialize.h",1,1,null,0,0],["uibase.cpp",21,24,null,0,0],["uibase.h",8,7,null,0,0],["uiproject.fbp",181,171,null,87,0]]},{"id":"c776d0f3459","sha":"776d0f34595fd616129d4816a337662ff39de7c6","d":1290539796,"s":"new getwork","r":189,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":10,"ins":469,"del":254,"u":"https://github.com/bitcoin/bitcoin/commit/776d0f34595fd616129d4816a337662ff39de7c6","f":[["coding.txt",41,0,null,0,0],["db.cpp",2,2,null,0,0],["db.h",4,3,null,0,0],["main.cpp",289,239,null,355,0],["main.h",11,0,null,0,0],["rpc.cpp",115,4,null,0,0],["serialize.h",1,1,null,0,0],["sha256.cpp",3,3,null,0,0],["ui.cpp",2,2,null,0,0],["util.cpp",1,0,null,0,0]]},{"id":"cb7ccd48dd8","sha":"b7ccd48dd8dd2fb5c37f81e734673e998fd2d78a","d":1290703225,"s":"still working on account-based commands getbalance, move and sendfrom, they're only for testing for now","r":190,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":3,"del":1,"u":"https://github.com/bitcoin/bitcoin/commit/b7ccd48dd8dd2fb5c37f81e734673e998fd2d78a","f":[["rpc.cpp",2,0,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c24324d83e8","sha":"24324d83e8d9f0b9403ca1c333b594b77eaefb4c","d":1290717717,"s":"-- version 0.3.17 release","r":191,"rel":"v0.3.17","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":13,"del":5,"u":"https://github.com/bitcoin/bitcoin/commit/24324d83e8d9f0b9403ca1c333b594b77eaefb4c","f":[["build-unix.txt",2,1,null,0,0],["rpc.cpp",4,0,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",3,0,null,0,0]]},{"id":"c84d7c981dc","sha":"84d7c981dc52cc738053f9ec48648ab6fbf9311b","d":1290899561,"s":"added boost tuples to serialize.h","r":192,"rel":"v0.3.18","cn":"s_nakamoto","who":"s_nakamoto","fc":2,"ins":81,"del":3,"u":"https://github.com/bitcoin/bitcoin/commit/84d7c981dc52cc738053f9ec48648ab6fbf9311b","f":[["db.cpp",2,2,null,0,0],["serialize.h",79,1,null,0,0]]},{"id":"cf03304a9c7","sha":"f03304a9c79a6cc6096ed501ad38702fd012e7f7","d":1291541370,"s":"preps for future client-only mode, jgarzik's initial download speedup","r":195,"rel":"v0.3.18","cn":"s_nakamoto","who":"s_nakamoto","fc":6,"ins":165,"del":29,"u":"https://github.com/bitcoin/bitcoin/commit/f03304a9c79a6cc6096ed501ad38702fd012e7f7","f":[["db.cpp",2,0,null,0,0],["db.h",1,1,null,0,0],["irc.cpp",76,0,null,0,0],["main.cpp",56,19,null,0,0],["main.h",29,8,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c865c3a2383","sha":"865c3a23832e36d50cb873d38c976032b027b5d3","d":1291651168,"s":"fix wallet.dat compatibility problem if you downgrade from 0.3.17 and then upgrade again","r":196,"rel":"v0.3.18","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":36,"del":15,"u":"https://github.com/bitcoin/bitcoin/commit/865c3a23832e36d50cb873d38c976032b027b5d3","f":[["db.cpp",24,0,null,0,0],["main.h",11,14,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c8220180133","sha":"82201801336f64ee77851b9eaab9383ee4e442f0","d":1291850628,"s":"-- version 0.3.18 release","r":198,"rel":"v0.3.18","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":9,"del":8,"u":"https://github.com/bitcoin/bitcoin/commit/82201801336f64ee77851b9eaab9383ee4e442f0","f":[["script.cpp",1,1,null,0,0],["script.h",2,0,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["util.cpp",2,3,null,0,0]]},{"id":"c97ee01ad89","sha":"97ee01ad898b0699c2319a1283313881ef4ba430","d":1292178036,"s":"added some DoS limits, removed safe mode","r":199,"rel":"v0.3.19","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":37,"del":40,"u":"https://github.com/bitcoin/bitcoin/commit/97ee01ad898b0699c2319a1283313881ef4ba430","f":[["main.cpp",36,9,null,0,0],["rpc.cpp",0,30,null,0,0],["serialize.h",1,1,null,0,0]]},{"id":"c986b5e257e","sha":"986b5e257e2bb9d7aaed5111ca335732f8808b2d","d":1292179082,"s":"correction","r":200,"rel":"v0.3.19","cn":"s_nakamoto","who":"s_nakamoto","fc":3,"ins":34,"del":7,"u":"https://github.com/bitcoin/bitcoin/commit/986b5e257e2bb9d7aaed5111ca335732f8808b2d","f":[["main.cpp",0,1,null,0,0],["main.h",4,6,null,0,0],["rpc.cpp",30,0,null,0,0]]},{"id":"cfc73ad644f","sha":"fc73ad644f0b87b91f49b7f6f6b2348f78bdbbf4","d":1292257574,"s":"-- version 0.3.19 release","r":201,"rel":"v0.3.19","cn":"s_nakamoto","who":"s_nakamoto","fc":22,"ins":38,"del":38,"u":"https://github.com/bitcoin/bitcoin/commit/fc73ad644f0b87b91f49b7f6f6b2348f78bdbbf4","f":[["build-osx.txt",1,1,null,0,0],["license.txt",1,1,null,0,0],["locale/de/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/de/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/es/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/es/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/fr/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/fr/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/it/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/it/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/nl/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/nl/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/pt/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/pt/LC_MESSAGES/bitcoin.po",4,4,null,0,0],["locale/ru/LC_MESSAGES/bitcoin.mo",null,null,null,1,1],["locale/ru/LC_MESSAGES/bitcoin.po",3,3,null,0,0],["makefile.osx",1,1,null,0,0],["serialize.h",1,1,null,0,0],["setup.nsi",3,3,null,0,0],["ui.cpp",1,1,null,0,0],["uibase.cpp",1,1,null,0,0],["uiproject.fbp",2,2,null,0,0]]},{"id":"c629e37dde1","sha":"629e37dde1fa93f6ce31544d1ebb5ee5c19052cb","d":1292453031,"s":"get external ip from irc","r":202,"rel":"v0.3.20","cn":"s_nakamoto","who":"s_nakamoto","fc":5,"ins":48,"del":16,"u":"https://github.com/bitcoin/bitcoin/commit/629e37dde1fa93f6ce31544d1ebb5ee5c19052cb","f":[["irc.cpp",7,3,null,0,0],["irc.h",1,0,null,0,0],["main.h",2,0,null,0,0],["net.cpp",37,12,null,0,0],["serialize.h",1,1,null,0,0]]}]}