_ ___ _ _ _ _ | |/ (_) ___| | _(_)_ __ __ _ | |_| |__ ___ | ' /| |/ __| |/ / | '_ \ / _` | | __| '_ \ / _ \ | . \| | (__| <| | | | | (_| | | |_| | | | __/ |_|\_\_|\___|_|\_\_|_| |_|\__, | \__|_| |_|\___| |___/ _ _ _ _ _ _ | | | | ___ _ __ _ __ ___| |_ ___ | \ | | ___ ___| |_ | |_| |/ _ \| '__| '_ \ / _ \ __/ __| | \| |/ _ \/ __| __| | _ | (_) | | | | | | __/ |_\__ \ | |\ | __/\__ \ |_ |_| |_|\___/|_| |_| |_|\___|\__|___/ |_| \_|\___||___/\__| This file looks best using a monospace font. Kicking the Hornet’s Nest The Complete Writings, Emails, and Forum Posts of Satoshi Nakamoto, the Founder of Bitcoin and Cryptocurrency Third edition MMMMMMMMMMMMMMMMMMMN0O0XWMMMMMMMMMMWXOxOWMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMWMMWX00OO0NMMMMMMN0OO0KNMMWNNMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMNOkKWWWMMN0k0XNXX0k0NMMWWNOdkKWMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMXOxxkXMMMW0odxddokWMMMKdox0WMMMMMMMMMMMWWMMM MNXXKXXXNWWMMMMMMMNkcdXMM0ld0KK0dl0MMNdl0WMMMMMMWNKKKK00O00X X0Okxk0XX0OO0KXWMMMN0ocdOk:;llllcckXOo:kWMMWNKOOkkkO00OO0K0K NK0KKK00KX0xdddkO0XNWW0o;,,,;:;;;;',cdKNN0kxxddOKXNNXK0KXXXW MWXKKNKO0XN0OOOOOxxxkkkko'.,clc:'..,xkxddddkOOO00KKKKKKKXNMM MMMWNXXXKKK000KK0kxkxdloo, .:c:;...:doodxkkkOOkk00Ok0XNWMMMM MMMMMMWN00K000KKOO00kdllo:..;cc;..'ldoldOOkk00xk0KKXWMMMMMMM MMMMMMMMMNXXNXK0OO0Od::lc;'.......'cl:,cO0O0KXXXNWWMMMMMMMMM MMMMMMMMMMMMWWNNNNKxlcOXKk:.',''..;xXKo:o0NWWMMMMMMMMMMMMMMM MMMMMMMMMMMMMMWNKOkO0XMWKc.........c0NNKkkkO0XWMMMMMMMMMMMMM MMMMMMMMMMMMMMXOO0XWMWKx;.........'.'l0WMWXKOKWMMMMMMMMMMMMM MMMMMMMMMMMMMMWWWMMMWOldc''.......';ooc0MMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMNlc0dcxxd:':xO0xkkckWMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMXllKklox0K00KkooOklkNMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMNd:kkooxKNNNKxcoOkckWMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMNddK0lcdkKKK0xokKXdxWMMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMM0o0MWkclk00Okdo0WMOo0MMMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMXkOWMMXo;oOOOo:xNMMW0x0WMMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMWKxONMMMMXo:dOxloXMMMMW0dOWMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMN0ONMMMMMMN0dddONMMMMMMWXXWMMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMMMMMMMMMMNXNWMMMMMMMMMMMMMMMMMMMMMMMMMMM Edited by: crrdlx https://hive.blog/@crrdlx/satoshi Copyright © 2019 Mill Hill Books. All rights reserved. Third edition copyright © 2024 Mill Hill Books. All rights reserved. Published by Mill Hill Books ISBN 978-0-359-32744-7 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. • Satoshi Nakamoto, December 11, 2010, 23:39:16 UTC This statement was in reference to an article by PC World. It can be accessed at https://www.pcworld.com/article/213230/could_wikileaks_scandal_lead_to_new_virtual_currency.html. Two days later, Satoshi Nakamoto disappeared from making further public postings. Sources: • https://satoshi.nakamotoinstitute.org - This was the main resource for this book. Their work and organization is priceless. • https://BitcoinTalk.org/ - The forum set up by Satoshi. • http://www.metzdowd.com/pipermail/cryptography - The Cryptography Mailing List was used by the group generally known as “cypherpunks.” • https://plan99.net/~mike - Personal emails to/from Mike Hearn, publicly shared on the Internet at this site. • https://en.bitcoin.it/wiki/Source:Trammell/Nakamoto_emails - Personal emails to/from Dustin Trammell (aka Druid) from January 2009. Also, emails from Trammell’s website: https://www.dustintrammell.com/s/Satoshi_Nakamoto.zip • https://online.wsj.com/public/resources/documents/finneynakamotoemails.pdf - Personal emails to/from Hal Finney, publicly shared on this Wall Street Journal site. • https://www.coindesk.com/satoshi-nakamoto-hal-finney-emails - “Newly discovered emails” revealed in November, 2020, in a CoinDesk article written by Michael Kapilkov. • https://bitcoinmagazine.com/technical/bitcoin-adam-backs-complete-emails-satoshi-nakamoto which references the COPA case file dump at https://www.dropbox.com/scl/fo/4y3gdele4foy15006z8ch/h?rlkey=scs42wew1o3vwfv0nduhc43dm&e=1&dl=0 – Personal emails to/from Adam Back previously unseen publicly prior to the February 2024 COPA case. • https://mmalmi.github.io/satoshi/ - Personal emails to/from Martii Malmi. These were released publicly by Malmi in February 2024 as part of the COPA case. Notes on the Third Edition One might ask, “Why is there a third edition of Satoshi’s words?” The simple answer is that new, or rather, previously unseen Satoshi writings have emerged publicly. The “Hal Finney emails” cited above by CoinDesk in November of 2020 prompted version two of “Kicking.” Then, in February of 2024, the “COPA trial” began with the possible identity of Satoshi Nakamoto at the core of the case. That trial called in individuals who had made early electronic contact with Satoshi to offer witness statements. As a result, new, previously private “Satoshi emails” became public. Hence, here is the Third Edition of “Kicking.” I think that a chronological record of Satoshi’s writings is interesting, useful, and important. To that end, I’m committed to keeping this book freely offered and in several formats. See all the links at https://hive.blog/@crrdlx/satoshi to download a copy. • crrdlx, editor February 24, 2024 @@@@ @@@@@@@@@ @@@@@@@@@@@@@@ @@@@((&@@@@@@@@ ((&&@@@@@@ @@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@% @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ This book is available in print at https://lulu.com Digital versions (pdf, txt) can be obtained for free at https://hive.blog/@crrdlx/satoshi Visit this site for all links, digital and print. Notes from the Editor Ten years ago, on January 3, 2009, Bitcoin went live. That day, Satoshi Nakamoto generated the first Bitcoin block, which has since come to be known as the “Genesis block.” In the Genesis block, Satoshi encoded the message, “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.” This was likely to both timestamp the block to the outside world (using the title of the article on the front page of the London’s daily The Times), but, more importantly, to offer a comment. The comment gave insight that was both outward toward the financial system and inward toward Satoshi himself. Any article title could have been chosen as a timestamp. This one was clearly meant to convey a message. Satoshi sent the message that he does not favor banks. More likely, he does not like the fractional reserve banking system and the endless creation of fiat currency that coincides with fractional reserve banking. 2008 and 2009, when Bitcoin was born, were the years of rampant “cash injections,” “stimulus packages,” “quantitative easing,” and “too-big-to-fail” bank bailouts. Bitcoin, with its hard-coded 21 million coin limit, would solve the fiat addiction. Infinite paper money would be replaced by finite numbers written in code. What’s more, Satoshi fired a shot across the bow of the financial powers-that-be. Bankers, politicians, and the manipulators of the money supply have not been happy about Bitcoin and cryptocurrency. Ten years in, the powers seem to be warming to the idea a bit—or, at least, they’re beginning to realize the use-cases and the inevitability of crypto. Still, their reluctant “embrace” is very slow and very cautious. I imagine one of the most threatening things to the powerful is to suggest that power be taken from them and then dispersed to the people themselves. Putting power into the hands of the people means saying, “You know what? We the people really don’t need you after all. Have a nice day.” Bitcoin suggests this very thing financially—it gives the power, freedom, and responsibility to the individual. As a boy, my brother and I would occasionally come upon a hornet’s nest while playing in the woods. When we did, being boys, there was really nothing else to do but to throw a rock or stick at it, or kick it. Kicking a hornet’s nest isn’t rational, but just too tempting and just too much fun not to. And when you do it, you do it fast and then you run like hell! Since January 2009, some people have placed an almost religious status onto Satoshi and his writings (the term “Genesis block” serves an example). I do not subscribe to this position, and I discourage anyone from doing so. Satoshi is, or was, a man, or a woman, or a group—as fallible and as human as us all. And, I’m sure he holds just as many hang-ups and weaknesses as anyone else. Applying demi-god status to a mortal man is unfair to that person, and sets one’s self up for disappointment. And yet, Satoshi was very clever. So, I do think his writings, interactions, and thought processes are important, revolutionary, and worth documenting. I realize that all of these words are fantastically preserved and organized on websites, particularly at the Satoshi Nakamoto Institute (https://nakamotoinstitute.org/). Still, having a hard copy for reference or referral may be appealing to some. And, I realize other such books exist already. However, they include most, but not all, of Satoshi’s writings and they include excellent commentary as well. This book is distinct in that it has the entirety of Satoshi’s work included, is arranged chronologically rather than topically, and offers almost zero commentary. The goals here were to be complete, to build a chronological chain of Satoshi’s words and thoughts, and to allow Satoshi’s words to speak for themselves free from an editor’s interjections. Thus, this book was assembled. Following are all of the public writings of Satoshi Nakamoto, the founder of Bitcoin—at least these are all that I could find. They are arranged in chronological order. Many of the writings are very technical. Some are purely code and will read as jibberish to most of us. I debated whether to include these “writings” or not. But, I wished to have a full account of all of Satoshi’s writings, and so, even the code was included. Though unwieldly to read, even they convey a message—Satoshi was focused, businesslike, and pragmatic in his dealings and work. Since many of the writings are in response to others’ comments, and for the sake of revealing the context of Satoshi’s words, there are writings by other people included here as well. However, any non-Satoshi writings are italicized. Satoshi’s writings can be identified by the fact that they are not italicized. Satoshi’s words are not italized. They look like this. Words by others are italicized. They look like this. (note: since this is the TXT-VERSION, there are no italics) Compiling these writings was educational to the editor. It seemed to offer insight into Satoshi Nakamoto. Lessons were learnt regarding Satoshi combing through his words, or, at the least, following were my interpretations: Satoshi is polite. He said “Thanks” or “Thank you” several times. Often, an exclamation point was included for emphasis. And, he apologizes when appropriate. Satoshi is a good teacher. In the earlier phases especially, he patiently and clearly answers questions one-by-one. Satoshi is a clear communicator. His English, grammar, and syntax are nearly flawless. Although he does, on occasion, dabble in textese—he throws in a WTF and an AFAIK—nearly all of his communications are in clear, declarative, complete and correct sentences. Satoshi is a fantastic thinker. He is able to think with beautiful logic. He is able to think abstractly in concepts via analogies (such as the Gambler’s Ruin problem in the whitepaper). His more formal logic is seen in his code, naturally, but it is also witnessed in his writings. For example, in a response to theymos, Satoshi simply states, “The premise is false,” then he explains why. As something of an aside, that statement harkens to Ayn Rand’s Atlas Shrugged, where “check your premises” is an ongoing sub-theme in the novel. For anyone unfamiliar with the book, the phrase does two things. First, it’s a reference to Aristotelian logic of non-contradiction—if two things seem to contradict, they actually don’t, one of them is wrong—check your premises. And secondly, the uber-theme of the novel itself is an indictment of government bailouts very similar to the Chancellor’s brink-of-bailout of January 3, 2009. Atlas Shrugged damns governments and powers which purport to know what’s best and act for the people’s best interest, rather than freeing the people to simply act for themselves. I don’t think Satoshi was thinking Atlas Shrugged when he wrote the premise statement to theymos. I believe he was merely thinking clearly. But, the theme of Atlas Shrugged, and the “theme” of Bitcoin, certainly do seem to coincide with those words. Satoshi likes to double-space after a sentence is complete. This was the standard taught to typing or keyboarding students up until roughly the year 2000. Stylometry, studying a person’s literary quirks in writing, has been a ripe field for pondering the identity of Satoshi Nakamoto. It may be a stretch, but with few clues, this double-space idiosyncrasy has often been noted in places like /r/Bitcoin on Reddit. There has also been discussion about Satoshi’s tendencies toward British spellings of words, such as cheques for checks, neighbours for neighbors, decentralised or formalised with an s rather than a z, or use of the word “bloody.” Some say these British tendencies were for obfuscation—to fake the world. I personally think there is something to the British influence. His British usage reads very organicly and unforced. I interpret that Satoshi indeed had some British-influenced upbringing (e.g., Britain, or Canada or Australia or a British Caribbean island). Like micro-expressions in facial body language, wording, in organic thought or writing, becomes hard-coded. To not release those tendencies would require constant and extreme discipline. Of course, Satoshi just might well have those qualities and fool me right there! Regarding double-spacing, I tend to believe that the double-spacing may well hint at Satoshi’s age…he most likely learned to type when double-spacing after a period was standard. Revolutionary ideas have often come in history from people in their 20s or early 30s, but in this case, that seems too young. Typing this specific way, given the revolutionary thoughts for Bitcoin, and the technical skill acquired and necessary to create the code, as well as the polish in writing, Satoshi was likely not young when working on Bitcoin. Purely speculating, I would guess that he was likely around 40 when the whitepaper came out in 2008…meaning he was likely born around 1968, give-or-take a few years. Satoshi is a heads-down programmer. Many of the writings here are mundane coder-talk. They are likely cryptic jibberish to nearly everyone. Satoshi does not fiddle with small-talk or niceties. He consistently remains focused and practical. When wished a happy Christmas by Mike Hearn if he celebrates Christmas, Satoshi makes no response either way. He merely proceeds to the task-at-hand. Satoshi values privacy. This is witnessed in his words—naturally for a cypherpunk—but also in his focused neglect of including anything personal about himself (or herself), such as the Christmas non-comment. It’s worth noting here that since Satoshi Nakamoto is unknown, Satoshi’s sex is unknown. Satoshi may be a man, woman, or group. However, since サトシ is generally a male’s name in Japan, Satoshi is referred to here using singular, male pronouns. Satoshi can pack a lot into a few words. His writing style is brief and to-the-point, but not impolite or terse. On the day the whitepaper was revealed, when he writes, “I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party,” he could have almost simply stopped right there. Satoshi has a practical sense of marketing about him. He understands the importance of a good icon or logo. He understands that slow growth is not necessarily a bad thing. And he gets that there is such a thing as bad publicity (e.g., the WikiLeaks, hornet’s nest comment). Despite his focused, logical, business-minded tendencies, there seems to me to be a bit of boyishness about him. This is seldom shown, but it is there, revealed in his writings in rare glints. This leads to a final conclusion… Satoshi is human. When he writes to Mike Hearn on Wed, March 9, 2011, “That’s great news!” the guarded wall that normally shields Satoshi-the-person seems to quaver. It hints at a real person, with emotions, excitement, and an almost childlike glee in what he’s doing, lying somewhere behind the façade of Satoshi Nakamoto. He’s kicking the hornet’s nest himself, and he knows it. And, when just two days before withdrawing from public posts he writes, “That means a lot coming from you, Hal. Thanks.” I hear a deep sigh after sending that comment. • Editor January 3, 2019 Satoshi Nakamoto’s PGP Key -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.7 (MingW32) mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6 VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv /LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5 HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7 FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0 UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R 8RHwN4Gk8w== =3FTe -----END PGP PUBLIC KEY BLOCK----- The Bitcoin Whitepaper Source: https://bitcoin.org/bitcoin.pdf Bitcoin:  A Peer-to-Peer Electronic Cash System  Satoshi Nakamoto October 31, 2008 Abstract 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. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third 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 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. Messages are broadcast 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. 1. Introduction 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. 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. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. 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. 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. MMMMMWWNNNNNNNNNNNNWMMMWNNNNNNNNNNNNNWMMMWNNNNNNNNNXNNWMMMMM MMMMMWXK000000KXNXXWMMWXK0000000KXNXXWMMWXK000000KXXXXNMMMMM MMMMMWXXXKKKKKXNNXXWMMWXKKK00000KXNXXWMMWXKXK000KKXNXXNMMMMM MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: a diagram showing transactions NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM MMMMMMWWWNNXXNNNWNWWMMMWNNNXXXXXXNNNNWWMMWNNNXXXXXNWNNWMMMMM MMMMMMWWNXK0KKKNWNWMMMMWNNK00000KXNNWMMMMWNNK00000KNNWMMMMMM MMMMMMWWNNXXXXXNNWWMMMMWNNXXXXXXXXNNWMMMMMWNXXXXXXXNNWMMMMMM MMMMMMMMMMMMWMMMWMMMMMMMMMMMMWWMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 2. Transactions 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. 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. 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[1], 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. 3. Timestamp Server 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[2-5]. 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. MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: depicting transactions NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM 4. Proof-of-Work 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[6], 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. 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. MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: depicting blocks NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM 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. 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. 5. Network The steps to run the network are as follows: 1. New transactions are broadcast to all nodes. 2. Each node collects new transactions into a block. 3. Each node works on finding a difficult proof-of-work for its block. 4. When a node finds a proof-of-work, it broadcasts the block to all nodes. 5. Nodes accept the block only if all transactions in it are valid and not already spent. 6. 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. 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. 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. 6. Incentive 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. 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. 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. 7. Reclaiming Disk Space 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 [7][2][5], 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. MMMMMWWNNNNNNNNNNNNWMMMWNNNNNNNNNNNNNWMMMWNNNNNNNNNXNNWMMMMM MMMMMWXK000000KXNXXWMMWXK0000000KXNXXWMMWXK000000KXXXXNMMMMM MMMMMWXXXKKKKKXNNXXWMMWXKKK00000KXNXXWMMWXKXK000KKXNXXNMMMMM MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: blocks and hashes NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM MMMMMMWWWNNXXNNNWNWWMMMWNNNXXXXXXNNNNWWMMWNNNXXXXXNWNNWMMMMM MMMMMMWWNXK0KKKNWNWMMMMWNNK00000KXNNWMMMMWNNK00000KNNWMMMMMM MMMMMMWWNNXXXXXNNWWMMMMWNNXXXXXXXXNNWMMMMMWNXXXXXXXNNWMMMMMM MMMMMMMMMMMMWMMMWMMMMMMMMMMMMWWMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 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. 8. Simplified Payment Verification 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. MMMMMWWNNNNNNNNNNNNWMMMWNNNNNNNNNNNNNWMMMWNNNNNNNNNXNNWMMMMM MMMMMWXK000000KXNXXWMMWXK0000000KXNXXWMMWXK000000KXXXXNMMMMM MMMMMWXXXKKKKKXNNXXWMMWXKKK00000KXNXXWMMWXKXK000KKXNXXNMMMMM MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: block hashes NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM MMMMMMWWWNNXXNNNWNWWMMMWNNNXXXXXXNNNNWWMMWNNNXXXXXNWNNWMMMMM MMMMMMWWNXK0KKKNWNWMMMMWNNK00000KXNNWMMMMWNNK00000KNNWMMMMMM MMMMMMWWNNXXXXXNNWWMMMMWNNXXXXXXXXNNWMMMMMWNXXXXXXXNNWMMMMMM MMMMMMMMMMMMWMMMWMMMMMMMMMMMMWWMMMMMMMMMMMMMMMMMMMMMMMMMMMMM As 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. 9. Combining and Splitting Value 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. MMMMMWXXXKKKKKXNNXXWMMWXKKK00000KXNXXWMMWXKXK000KKXNXXNMMMMM MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: transaction NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM 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. 10. Privacy 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. MMMMMWWNNNNNNNNNNNNWMMMWNNNNNNNNNNNNNWMMMWNNNNNNNNNXNNWMMMMM MMMMMWXK000000KXNXXWMMWXK0000000KXNXXWMMWXK000000KXXXXNMMMMM MMMMMWXXXKKKKKXNNXXWMMWXKKK00000KXNXXWMMWXKXK000KKXNXXNMMMMM MMMMMWXXWXK0KKKNWXXWMMWXXNK0000KKXNXXWMMWXKNX000KKXNXKNMMMMM MMMMWNKXXXKKXKKXNXKNWWNKKXK0KKKKKXNXKNWWWXKXKKKKKKXXXXNWMMMM MMMWWNKKXXKKK0XNXXKNNNNKXXXKKKKKXNXXXXNNNKKXXKKKKXNXXXNWMMMM MMMMMWXNWNX XXXXNMMMMM MMMMMMMXNMM image: traditional privacy model NNWXXWMMMM MMMMWNXXNNN NNNXNWMMMM MMMMMWX0XXKKKXXXNXXWMMWX0XNXXXXXXNNNXWMMWK0KXKKKXXXNNXNMMMMM MMMMMWXKXXKKKKKXNXXWMMWXKXNKKKKKXNNXNWMMWXKXXK0KKKXNNXNMMMMM MMMMMNK0KXKXXXXXXXXWWNNK0KXXXXXXXXXXXWWNNX0KXXKKXXXXXXWMMMMM MMMMWWWWWWWWWWWWWNWWNNWWWWWNWWNNNNWWWWNNWWWWNNWWWWWWWWWWMMMM MMMMMMWWWNNXXNNNWNWWMMMWNNNXXXXXXNNNNWWMMWNNNXXXXXNWNNWMMMMM MMMMMMWWNXK0KKKNWNWMMMMWNNK00000KXNNWMMMMWNNK00000KNNWMMMMMM MMMMMMWWNNXXXXXNNWWMMMMWNNXXXXXXXXNNWMMMMMWNXXXXXXXNNWMMMMMM MMMMMMMMMMMMWMMMWMMMMMMMMMMMMWWMMMMMMMMMMMMMMMMMMMMMMMMMMMMM 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. 11. Calculations 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. The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[8]: pqqz=== probability an honest node finds the next block probability the attacker finds the next block probability the attacker will ever catch up from z blocks behindp= probability an honest node finds the next blockq= probability the attacker finds the next blockqz= probability the attacker will ever catch up from z blocks behind qz={1(q/p)zifp≤qifp>q}qz={1ifp≤q(q/p)zifp>q} Given our assumption that p>qp>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late. The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction. The recipient waits until the transaction has been added to a block and zz blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value: λ=zqpλ=zqp To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point: ∑k=0∞λke−λk!⋅{(q/p)(z−k)1ifk≤zifk>z}∑k=0∞λke−λk!⋅{(q/p)(z−k)ifk≤z1ifk>z} Rearranging to avoid summing the infinite tail of the distribution... 1−∑k=0zλke−λk!(1−(q/p)(z−k))1−∑k=0zλke−λk!(1−(q/p)(z−k)) Converting to C code... #include double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } Running some results, we can see the probability drop off exponentially with zz. q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006 Solving for P less than 0.1%... P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340 12. Conclusion 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. 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. References 1. W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998. ↩ 2. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. ↩ ↩ 3. S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. ↩ 4. D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. ↩ 5. S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. ↩ ↩ 6. A. Back, "Hashcash - a denial of service counter-measure,"http://www.hashcash.org/papers/hashcash.pdf, 2002. ↩ 7. R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980. ↩ 8. W. Feller, "An introduction to probability theory and its applications," 1957. ↩ Emails, mailing list writings, forum posts by Satoshi Nakamoto (arranged in chronological order): Adam Back “COPA trial” email (these Adam Back-Satoshi emails became public in February of 2024) From: "satoshi@anonymousspeech.com" Sent: Wed 8/20/2008 6:30:39 PM (UTC+01:00) To: adam@cypherspace.org Subject: Citation of your Hashcash paper 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: [5] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. I 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/ecashpdf.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. Title: Electronic Cash Without a Trusted Third PartyAbstract: 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 doublespending 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. satoshi@anonymousspeech.com Adam Back “COPA trial” email From: "Adam Back" Sent: Thur 8/21/2008 1:55:59 PM (UTC+01:00) To: satoshi@anonymousspeech.com Cc: adam@cypherspace.org Subject: Re: Citation of your Hashcash paper 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 didn’t write up a paper). Adam On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com wrote: > 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: > > [5] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. > > I 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/ecashpdf.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. > > Title: Electronic Cash Without a Trusted Third Party > > Abstract: 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. > > satoshi@anonymousspeech.com > Adam Back “COPA trial” email From: "satoshi@anonymousspeech.com" Sent: Thur 8/21/2008 6:59:49 PM (UTC+01:00) To: adam@cypherspace.org Subject: RE: Citation of your Hashcash paper 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. The 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. Satoshi >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). > >Adam >>On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com > wrote: >> 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: >> >> [5] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. >> >> I 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/ecashpdf.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. >> >> Title: Electronic Cash Without a Trusted Third Party >> >> Abstract: 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. >> >> satoshi@anonymousspeech.com >> Adam Back “COPA trial” email From: "Adam Back" Sent: Thur 8/21/2008 7:17:17 PM (UTC+01:00) To: satoshi@anonymousspeech.com Cc: adam@cypherspace.org Subject: Re: Citation of your Hashcash paper 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. Adam On Thu, Aug 21, 2008 at 6:59 PM, satoshi@anonymousspeech.com wrote: > 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. > > The 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. > > Satoshi > >>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). >> >>Adam >> >>On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com >> wrote: >>> 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: >>> >>> [5] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. >>> >>> I 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/ecashpdf.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. >>> >>> Title: Electronic Cash Without a Trusted Third Party >>> >>> Abstract: 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 toprevent 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. >>> >>> satoshi@anonymousspeech.com >>> Cryptography Mailing List Bitcoin P2P e-cash paper 2008-10-31 18:10:00 UTC -  -  I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party. The paper is available at: http://www.bitcoin.org/bitcoin.pdf The main properties: Double-spending is prevented with a peer-to-peer network. No mint or other trusted parties. Participants can be anonymous. New coins are made from Hashcash style proof-of-work. The proof-of-work for new coin generation also powers the network to prevent double-spending. Bitcoin: A Peer-to-Peer Electronic Cash System Abstract. 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 provide 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. Full paper at: http://www.bitcoin.org/bitcoin.pdf Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-03 01:37:43 UTC -  -  >Satoshi Nakamoto wrote: >> I've been working on a new electronic cash system that's fully >> peer-to-peer, with no trusted third party. >>  >> The paper is available at: >> http://www.bitcoin.org/bitcoin.pdf > >We very, very much need such a system, but the way I understand your  >proposal, it does not seem to scale to the required size. > >For transferable proof of work tokens to have value, they must have  >monetary value. To have monetary value, they must be transferred within  >a very large network - for example a file trading network akin to  >bittorrent. > >To detect and reject a double spending event in a timely manner, one  >must have most past transactions of the coins in the transaction, which,  > naively implemented, requires each peer to have most past  >transactions, or most past transactions that occurred recently. If  >hundreds of millions of people are doing transactions, that is a lot of  >bandwidth - each must know all, or a substantial part thereof. > 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. The 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. If 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.  Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-03 16:23:49 UTC -  -  >> As long as honest nodes control the most CPU power on the network, >> they can generate the longest chain and outpace any attackers. > >But they don't. Bad guys routinely control zombie farms of 100,000 >machines or more. People I know who run a blacklist of spam sending >zombies tell me they often see a million new zombies a day. > >This is the same reason that hashcash can't work on today's Internet >-- the good guys have vastly less computational firepower than the bad >guys. Thanks for bringing up that point. I 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.  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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-06 20:15:40 UTC -  -  >[Lengthy exposition of vulnerability of a systm to use-of-force >monopolies ellided.] > >You will not find a solution to political problems in cryptography. 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.  Satoshi Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-08 18:54:38 UTC -  -  Ray Dillinger: > the "currency" is inflationary at about 35%  > as that's how much faster computers get annually > ... the inflation rate of 35% is almost guaranteed  > by the technology Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases." As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future. 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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-09 01:58:48 UTC -  -  Hal Finney wrote: > it is mentioned that if a broadcast transaction does not reach all nodes, > it is OK, as it will get into the block chain before long. How does this > happen - what if the node that creates the "next" block (the first node > to find the hashcash collision) did not hear about the transaction, > and then a few more blocks get added also by nodes that did not hear > about that transaction? Do all the nodes that did hear it keep that > transaction around, hoping to incorporate it into a block once they get > lucky enough to be the one which finds the next collision? 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. > Or for example, what if a node is keeping two or more chains around as > it waits to see which grows fastest, and a block comes in for chain A > which would include a double-spend of a coin that is in chain B? Is that > checked for or not? (This might happen if someone double-spent and two > different sets of nodes heard about the two different transactions with > the same coin.) 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. 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.  > I also don't understand exactly how double-spending, or cancelling > transactions, is accomplished by a superior attacker who is able to muster > more computing power than all the honest participants. I see that he can > create new blocks and add them to create the longest chain, but how can > he erase or add old transactions in the chain? As the attacker sends out > his new blocks, aren't there consistency checks which honest nodes can > perform, to make sure that nothing got erased? More explanation of this > attack would be helpful, in order to judge the gains to an attacker from > this, versus simply using his computing power to mint new coins honestly. 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. This 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.  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. > As far as the spending transactions, what checks does the recipient of a > coin have to perform? Does she need to go back through the coin's entire > history of transfers, and make sure that every transaction on the list is > indeed linked into the "timestamp" block chain? Or can she just do the > latest one?  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. > Do the timestamp nodes check transactions, making sure that > the previous transaction on a coin is in the chain, thereby enforcing > the rule that all transactions in the chain represent valid coins? 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. > Sorry about all the questions, but as I said this does seem to be a > very promising and original idea, and I am looking forward to seeing > how the concept is further developed. It would be helpful to see a more > process oriented description of the idea, with concrete details of the > data structures for the various objects (coins, blocks, transactions), > the data which is included in messages, and algorithmic descriptions > of the procedures for handling the various events which would occur in > this system. You mentioned that you are working on an implementation, > but I think a more formal, text description of the system would be a > helpful next step. 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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-09 03:09:49 UTC -  -  James A. Donald wrote: > The core concept is that lots of entities keep complete and consistent > information as to who owns which bitcoins. > > But maintaining consistency is tricky. It is not clear to me what > happens when someone reports one transaction to one maintainer, and > someone else transports another transaction to another maintainer. The > transaction cannot be known to be valid until it has been incorporated > into a globally shared view of all past transactions, and no one can > know that a globally shared view of all past transactions is globally > shared until after some time has passed, and after many new > transactions have arrived. > > Did you explain how to do this, and it just passed over my head, or > were you confident it could be done, and a bit vague as to the details? 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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-09 16:31:26 UTC -  -  James A. Donald wrote: >OK, suppose one node incorporates a bunch of >transactions in its proof of work, all of them honest >legitimate single spends and another node incorporates a >different bunch of transactions in its proof of >work, all of them equally honest legitimate single >spends, and both proofs are generated at about the same >time. > >What happens then? 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.  In 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. It's not a problem if transactions have to wait one or a few extra cycles to get into a block.  Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-10 02:14:30 UTC -  -  James A. Donald wrote: > Furthermore, it cannot be made to work, as in the > proposed system the work of tracking who owns what coins > is paid for by seigniorage, which requires inflation. 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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-10 22:18:20 UTC -  -  James A. Donald wrote: > So what happened to the coin that lost the race? > > ... it is a bit harsh if the guy who came second  > is likely to lose his coin. 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. > Further, your description of events implies restrictions > on timing and coin generation - that the entire network > generates coins slowly compared to the time required for > news of a new coin to flood the network Sorry if I didn't make that clear. 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. > We want spenders to have certainty that their > transaction is valid at the time it takes a spend to > flood the network, not at the time it takes for branch > races to be resolved. 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. > If one node is ignoring all spends that it does not  > care about, it suffers no adverse consequences. With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-13 22:56:55 UTC -  -  James A. Donald wrote: > It is not sufficient that everyone knows X. We also > need everyone to know that everyone knows X, and that > everyone knows that everyone knows that everyone knows X > - which, as in the Byzantine Generals problem, is the > classic hard problem of distributed data processing. The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context. A 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. 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. 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. The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved. Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-14 18:55:35 UTC -  -  Hal Finney wrote: > I think it is necessary that nodes keep a separate  > pending-transaction list associated with each candidate chain.  > ... One might also ask ... how many candidate chains must  > a given node keep track of at one time, on average? 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. With 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. > Or as James raised earlier, if the network broadcast  > is reliable but depends on a potentially slow flooding  > algorithm, how does that impact performance? 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. I'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets. > 3. The bitcoin system turns out to be socially useful and valuable, so > that node operators feel that they are making a beneficial contribution > to the world by their efforts (similar to the various "@Home" compute > projects where people volunteer their compute resources for good causes). >  > In this case it seems to me that simple altruism can suffice to keep the > network running properly. It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-15 04:43:00 UTC -  -  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. Ray Dillinger (Bear) wrote: > When a coin is spent, the buyer and seller digitally sign a (blinded) > transaction record. Only the buyer signs, and there's no blinding.  > If someone double spends, then the transaction record  > can be unblinded revealing the identity of the cheater.  Identities are not used, and there's no reliance on recourse. It's all prevention. > This is done via a fairly standard cut-and-choose  > algorithm where the buyer responds to several challenges > with secret shares 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. > They may also receive chains as long as the one they're trying to > extend while they work, in which the last few "links" are links > that are *not* in common with the chain on which they're working. > These they ignore.  Right, if it's equal in length, ties are broken by keeping the earliest one received. > If it contains a double spend, then they create a "transaction"  > which is a proof of double spending, add it to their pool A,  > broadcast it, and continue work. 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.  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. If 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. 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.  Even 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. > If the new chain is accepted, then they give up on adding their > current link, dump all the transactions from pool L back into pool > A (along with transactions they've received or created since > starting work), eliminate from pool A those transaction records > which are already part of a link in the new chain, and start work > again trying to extend the new chain. Right. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time. > CPU-intensive digital signature algorithm to  > sign the chain including the new block L.  It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature.  > Is there a mechanism to make sure that the "chain" does not consist > solely of links added by just the 3 or 4 fastest nodes? 'Cause a > broadcast transaction record could easily miss those 3 or 4 nodes > and if it does, and those nodes continue to dominate the chain, the > transaction might never get added. 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. 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. > Also, the work requirement for adding a link to the chain should > vary (again exponentially) with the number of links added to that > chain in the previous week, causing the rate of coin generation > (and therefore inflation) to be strictly controlled. Right. > You need coin aggregation for this to scale. There needs to be > a "provable" transaction where someone retires ten single coins > and creates a new coin with denomination ten, etc.  Every transaction is one of these. Section 9, Combining and Splitting Value.  Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-15 18:02:00 UTC -  -  Ray Dillinger wrote: > One way to do this would be > to have the person recieving the coin generate an asymmetric > key pair, and then have half of it published with the > transaction. In order to spend the coin later, s/he must > demonstrate posession of the other half of the asymmetric > key pair, probably by using it to sign the key provided by > the new seller. Right, it's ECC digital signatures. A new key pair is used for every transaction. It's not pseudonymous in the sense of nyms identifying people, but it is at least a little pseudonymous in that the next action on a coin can be identified as being from the owner of that coin. > Mmmm. I don't know if I'm comfortable with that. You're saying > there's no effort to identify and exclude nodes that don't > cooperate? I suspect this will lead to trouble and possible DOS > attacks. There is no reliance on identifying anyone. As you've said, it's futile and can be trivially defeated with sock puppets. The credential that establishes someone as real is the ability to supply CPU power.  > Until.... until what? How does anybody know when a transaction > has become irrevocable? Is "a few" blocks three? Thirty? A > hundred? Does it depend on the number of nodes? Is it logarithmic > or linear in number of nodes? Section 11 calculates the worst case under attack. Typically, 5 or 10 blocks is enough for that. If you're selling something that doesn't merit a network-scale attack to steal it, in practice you could cut it closer. > But in the absence of identity, there's no downside to them > if spends become invalid, if they've already received the > goods they double-spent for (access to website, download, > whatever). The merchants are left holding the bag with > "invalid" coins, unless they wait that magical "few blocks" > (and how can they know how many?) before treating the spender > as having paid. > > The consumers won't do this if they spend their coin and it takes > an hour to clear before they can do what they spent their coin on. > The merchants won't do it if there's no way to charge back a > customer when they find the that their coin is invalid because > the customer has doublespent. This is a version 2 problem that I believe can be solved fairly satisfactorily for most applications. 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. 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. Information based goods like access to website or downloads are non-fencible. Nobody is going to be able to make a living off stealing access to websites or downloads. They can go to the file sharing networks to steal that. Most instant-access products aren't going to have a huge incentive to steal.  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. Satoshi Nakamoto Cryptography Mailing List Bitcoin P2P e-cash paper 2008-11-17 17:24:43 UTC -  -  James A. Donald wrote: > > Fortunately, it's only necessary to keep a > > pending-transaction pool for the current best branch. >  > This requires that we know, that is to say an honest > well behaved peer whose communications and data storage > is working well knows, what the current best branch is - I mean a node only needs the pending-tx pool for the best branch it has. The branch that it currently thinks is the best branch. That's the branch it'll be trying to make a block out of, which is all it needs the pool for. > > Broadcasts will probably be almost completely > > reliable. >  > Rather than assuming that each message arrives at least > once, we have to make a mechanism such that the > information arrives even though conveyed by messages > that frequently fail to arrive. I think I've got the peer networking broadcast mechanism covered.  Each node sends its neighbours an inventory list of hashes of the new blocks and transactions it has. The neighbours request the items they don't have yet. If the item never comes through after a timeout, they request it from another neighbour that had it. Since all or most of the neighbours should eventually have each item, even if the coms get fumbled up with one, they can get it from any of the others, trying one at a time. The inventory-request-data scheme introduces a little latency, but it ultimately helps speed more by keeping extra data blocks off the transmit queues and conserving bandwidth. > You have an outline > and proposal for such a design, which is a big step > forward, but the devil is in the little details. 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) Satoshi Nakamoto Personal email Editor’s note: In late November of 2020, three previously unknown emails emerged which are believed to have been correspondence between Satoshi Nakamoto and Hal Finney. The emails were dated November 19, 2008 (Finney to Nakamoto); January 8, 2009 (Nakamoto to Finney); and January 9, 2009 (Nakamoto to Finney). This places them a couple of weeks after the Bitcoin Whitepaper’s release and a week or so after the Bitcoin “Genesis Block” was mined. Thus, they were very early in Bitcoin history. In an article by professor Michael Kapilkov, CoinDesk.com reported on the emails and explained their validity (see https://www.coindesk.com/satoshi-nakamoto-hal-finney-emails). In short, CoinDesk reported that the emails had been on Hal Finney’s computer and that they had been previously shared with reporter Nathaniel Popper during research for his book titled “Digital Gold: Bitcoin and the Inside Story of the Misfits and Millionaires Trying to Reinvent Money” published in 2016, two years after Finney’s death. In the article, CoinDesk stated that Hal Finney’s widow, Fran Finney, had been contacted concerning the authenticity of the emails. The CoinDesk article explains that she corroborated that the emails had indeed been on Hal’s computer and that they had indeed been shared with Popper for his research. The CoinDesk article also stated that Popper, in turn, had shared the three previously unseen emails with Kapilkov, who then brought the emails to light in the CoinDesk article. Although the November 19 email was not written by Satoshi, it is included here for context. From hal@finney.org Wed Nov 19 07:20:46 2008 Return-Path: X-Original-To: hal@finney.org Delivered-To: hal@finney.org Received: by finney.org (Postfix, from userid 500) id A78D414F6E2; Wed, 19 Nov 2008 07:20:46 -0800 (PST) To: hal@finney.org, satoshi@vistomail.com Subject: Re: Bitcoin source files attached Cc: bear@sonic.net, jamesd@echeque.com Message-Id: <20081119152046.A78D414F6E2@finney.org> Date: Wed, 19 Nov 2008 07:20:46 -0800 (PST) From: hal@finney.org (“Hal Finney”) X-Bogosity: Ham, tests-bogofilter, spamicity=0.000000, version=1.0.3 Status: RO Ah, I see, thanks for the corrections. Some of the discussion and concern over performance may related to the eventual size of the P2P node network. How large do you envision it becoming? Tens of nodes? Thousands? Millions? And 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? Hal bitcoin-list [bitcoin-list] Welcome 2008-12-10 17:00:23 UTC -  -  Welcome to the Bitcoin mailing list! Genesis Block Bitcoin v0.1 released 2009-01-03 18:15:05 UTC -  -  The Times 03/Jan/2009 Chancellor on brink of second bailout for banks View the Genesis block on blockchain.com at https://www.blockchain.com/btc/block/000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f (shortcut: goo.gl/hm5ZzY) and at the encrypted note by Satoshi at https://www.blockchain.com/btc/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b (shortcut: goo.gl/2csRje). Image credit: Bitcoin Wiki at https://en.bitcoin.it/wiki/Genesis_block Cryptography Mailing List Bitcoin v0.1 released 2009-01-08 19:27:40 UTC -  -  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. See bitcoin.org for screenshots. Download link: http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar Windows only for now. Open source C++ code is included. - Unpack the files into a directory - Run BITCOIN.EXE - It automatically connects to other nodes 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. The software is still alpha and experimental. There's no guarantee the system's state won't have to be restarted at some point if it becomes necessary, although I've done everything I can to build in extensibility and versioning. 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. first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins etc... When 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. Satoshi Nakamoto Personal email Editor’s note: This is the second of the three previously unknown emails that emerged in November 2020. The emails were dated November 19, 2008 (Finney to Nakamoto); January 8, 2009 (Nakamoto to Finney); and January 9, 2009 (Nakamoto to Finney). From satoshi@vistomail.com Thu Jan 8 20:54:55 2009 Return-Path: X-Original-To: hal@finney.org Delivered-To: hal@finney.org Received: from mail.anonymousspeech.com (anonymousspeech.com [124.217.253.42]) by finney.org (Postfix) with ESMTP id 467AA14F6E1 for ; Thu, 8 Jan 2009 20:54:53 -0800 (PST) Received: from server123 ([124.217.253.42]) by anonymousspeech.com with MailEnable ESMTP; Fri, 09 Jan 2009 13:32:28 +0800 MIME-Version: 1.0 Date: Fri, 09 Jan 2009 13:21:04 +0800 X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com) X-Priority: 3 (Normal) Subject: Bitcoin v0.1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable From: “Satoshi Nakamoto” Reply-To: satoshi@vistomail.com To: hal@finney.org Message-ID: X-Bogosity: Ham, tests=bogofilter, spamcity=0.000000, version=1.0.3 Status: RO Thought you’d like to know, the Bitcoin v0.1 release with EXE and full sourcecode is up on Sourceforge: http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar www.bitcoin.org has release notes and screenshots. Satoshi Personal email Editor’s note: This is the third of the three previously unknown emails that emerged in November 2020. The emails were dated November 19, 2008 (Finney to Nakamoto); January 8, 2009 (Nakamoto to Finney); and January 9, 2009 (Nakamoto to Finney). From satoshi@vistomail.com Fri Jan 9 08:08:37 2009 Return-Path: X-Original-To: hal@finney.org Delivered-To: hal@finney.org Received: from mail.anonymousspeech.com (anonymousspeech.com [124.217.253.421]) by finney.org (Postfix) with ESMTP id 220A414F6E1 for ; Fri, 9 Jan 2009 08:08:35 -0800 (PST) Received: from server123 ([124.217.253.421]) by anonymousspeech.com with MailEnable ESMTP; Sat, 10 Jan 2009 00:46:09 +0800 MIME-Version: 1.0 Date: Sat, 10 Jan 2009 00:43:01 +0800 X-Mailer: Chilkat Software Inc (http://www.chilkatsoft.com) X-Priority: 3 (Normal) Subject: Re: Bitcoin v0.1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable From: “Satoshi Nakamoto” Reply-To: satoshi@vistomail.com To: hal@finney.org Message-ID: X-Bogosity: Ham, tests=bogofilter, spamcity=0.000000, version=1.0.3 Status: 0 Sure thing. If you have any questions, feel free. >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 – > >Hal > Cryptography Mailing List ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sat, Jan 10, 2009 at 11:52 AM Subject: RE:Crash in bitcoin 0.1.0 To: hal.finney@gmail.com 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. I've attached bitcoin.exe with symbols. (gcc symbols for gdb, if you're using MSVC I can send you an MSVC build with symbols) Thanks for your help! >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. > >The 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. > >When I have a chance, I'll try building it, although it looks like it >would take me a while to acquire all the dependencies. > >Hal From: Satoshi Nakamoto Date: Sat, Jan 10, 2009 at 2:59 PM Subject: Re: Crash in bitcoin 0.1.0 To: hal.finney@gmail.com 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. I'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. irc.cpp: if (pszName[0] == 'u') { CAddress addr; if (DecodeAddress(pszName, addr)) { CAddrDB addrdb; if (AddAddress(addrdb, addr)) printf("new "); else { // make it try connecting sooner CRITICAL_BLOCK(cs_mapAddresses) if (mapAddresses.count(addr.GetKey())) mapAddresses[addr.GetKey()].nLastFailed = 0; } addr.print(); } else { printf("decode failed\n"); } } >Yes, actually the version with MSVC symbols would be better, that is >the one I am using. > >I 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. > >I have to go out but I'll leave this version running for a while. > >Hal Adam Back “COPA trial” email From: "Satoshi Nakamoto" Sent: Sat 1/10/2009 6:46:45 PM (UTC) To: adam@cypherspace.org Subject: Re: Citation of your Hashcash paper Thanks for the pointers you gave me to Wei Dai's b-money paper and others. I just released the open source implementation of my paper, Bitcoin v0.1. Details, download and screenshots are at www.bitcoin.org The 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. There was a discussion of the design on the Cryptography mailing list. Hal Finney gave a good high-level overview: | One 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. Satoshi >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). > >Adam > >On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com > wrote: >> 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: >> >> [5] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 2002. >> >> I 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/ecashpdf.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. >> >> Title: Electronic Cash Without a Trusted Third Party >> >> Abstract: 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 toprevent 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. >> >> satoshi@anonymousspeech.com >> Cryptography Mailing List ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sat, Jan 10, 2009 at 6:55 PM Subject: Re: Crash in bitcoin 0.1.0 To: hal.finney@gmail.com 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. The 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. Thanks, Satoshi ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sat, Jan 10, 2009 at 7:11 PM Subject: Re: Crash in bitcoin 0.1.0 To: hal.finney@gmail.com 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. I can't use MSVC 6.0 for the release because its optimization of the SHA-256 routines is too slow. I've attached a copy of the debug runtime DLLs. (They're redistributable) >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. > >The 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. > >Hal ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sun, Jan 11, 2009 at 4:36 PM Subject: How's v0.1.2 going? To: hal.finney@gmail.com 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. I'm attaching the msvc debug version in case you need it. Satoshi ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sun, Jan 11, 2009 at 4:49 PM Subject: v0.1.2 gcc debug build attached To: hal.finney@gmail.com Could you send me your debug.log? The gcc debug version is attached. gdb is easier to use than you'd think. gdb.exe is the only file. You run gdb bitcoin.exe then type "run" then 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) ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sun, Jan 11, 2009 at 5:25 PM Subject: Re: v0.1.2 debug.log To: hal.finney@gmail.com OK, so no crash or exception window or anything. debug.log is all I need then. It 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. You 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. If 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. The 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. Thanks! >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. > >Hal ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sun, Jan 11, 2009 at 9:31 PM Subject: select failed 10038 fix To: hal.finney@gmail.com 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. Without 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. This 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. Looks 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. Version 0.1.3 exe attached. bitcoin-list [bitcoin-list] Bitcoin v0.1.2 now available 2009-01-11 22:32:18 UTC -  -  Bitcoin v0.1.2 is now available for download. See http://www.bitcoin.org for the download link. All the problems I've been finding are in the code that automatically finds and connects to other nodes, since I wasn't able to test it in the wild until now. There are many more ways for connections to get screwed up on the real Internet. Bugs fixed: - Fixed various problems that were making it hard for new nodes to see other nodes to connect to. - If you're behind a firewall, it could only receive one connection, and the second connection would constantly disconnect and reconnect. These problems are kind of screwing up the network and will get worse as more users arrive, so please make sure to upgrade. Satoshi Nakamoto From dtrammell@dustintrammell.com Sun Jan 11 23:14:04 2009 On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote: > 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. I'm currently reading through your paper. At the timestamp server section you mention newspapers and usenet, so I thought you might be interested in this if you have not seen it already: http://www.publictimestamp.org/ By the way, I'm also currently running the alpha code on one of my workstations. So far it has two "Generated" messages, however the "Credit" field for those is 0.00 and the balance hasn't changed. Is this due to the age/maturity requirement for a coin to be valid? Cheers, Dustin D. Trammell dtrammell@dustintrammell.com http://www.dustintrammell.com ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Mon, Jan 12, 2009 at 8:41 AM Subject: Re: select failed 10038 fix To: hal.finney@gmail.com 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. Did 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. Unfortunately, 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. You can send to my Bitcoin address if you want to, but you won't get to see the full transfer sequence: 1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD You 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. I 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. Satoshi >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. > >Hal ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Mon, Jan 12, 2009 at 10:50 AM Subject: Re: select failed 10038 fix To: hal.finney@gmail.com Could you send me the debug.log from the 0.1.3 crash? I can usually get a lot just from that. I'll send you the debug builds shortly. >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. > >Hal ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Mon, Jan 12, 2009 at 11:26 AM Subject: Re: v0.1.3 msvc debug build To: hal.finney@gmail.com Here's the 0.1.3 MSVC debug build >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. > >Hal > >On Mon, Jan 12, 2009 at 8:41 AM, Satoshi Nakamoto wrote: >> 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. >> >> Did 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. >> >> Unfortunately, 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. >> >> You can send to my Bitcoin address if you want to, but you won't >> get to see the full transfer sequence: >> 1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD >> >> You 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. >> >> I 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. >> >> Satoshi >> >>>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. >>> >>>Hal >>> >>>On Sun, Jan 11, 2009 at 9:31 PM, Satoshi Nakamoto wrote: >>>> 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. >>>> >>>> Without 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. >>>> >>>> This 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. >>>> >>>> Looks 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. >>>> >>>> Version 0.1.3 exe attached. ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Mon, Jan 12, 2009 at 11:39 AM Subject: Re: v0.1.3 gcc debug build To: hal.finney@gmail.com and the gcc debug build w/gdb.exe >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. > >Hal From satoshi@vistomail.com Mon Jan 12 18:52:45 2009 > I'm currently reading through your paper. At the timestamp server > section you mention newspapers and usenet, so I thought you might be > interested in this if you have not seen it already: > > http://www.publictimestamp.org/ Thanks, I hadn't seen that yet. It looks very well presented. There was an older one that's been running for a long time that publishes its hashes to Usenet. I'm surprised this one isn't using Usenet, although it is kind of difficult to get access to post to Usenet in an automated way these days. If they can get a magazine or newspaper to publish their hashes, it would work a lot easier in court for their purposes. Bitcoin and all timestamp servers share the basic functionality of periodically collecting things into blocks and hashing them into a chain. > By the way, I'm also currently running the alpha code on one of my > workstations. So far it has two "Generated" messages, however the > "Credit" field for those is 0.00 and the balance hasn't changed. Is > this due to the age/maturity requirement for a coin to be valid? Right, the credit field stays 0.00 until it matures, then it'll be 50.00. Do you think it would be clearer if I left the credit field blank until it matures? I should put some text in the transaction details (when you double click on it) explaining how it works. (was it obvious you can doubleclick on a line for details?) Be sure to upgrade to v0.1.3 if you haven't already. This version has really stabilized things. Satoshi bitcoin-list [bitcoin-list] Bitcoin v0.1 Alpha release notes 2009-01-12 20:20:47 UTC -  -  Release notes for Bitcoin v0.1 Alpha Bitcoin is 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. You can find screenshots and the download link at: http://www.bitcoin.org Windows only for now. Open source C++ code is included. - Unpack the files into a directory - Run BITCOIN.EXE - It automatically connects to other nodes 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. The software is still alpha and experimental. There's no guarantee the system's state won't have to be restarted at some point if it becomes necessary, although I've done everything I can to build in extensibility and versioning. 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. first 4 years: 10,500,000 coins next 4 years: 5,250,000 coins next 4 years: 2,625,000 coins next 4 years: 1,312,500 coins etc... When 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. Satoshi Nakamoto bitcoin-list [bitcoin-list] Bitcoin v0.1.3 2009-01-12 22:48:23 UTC -  -  It looks like we're through with the worst of the Internet connection issues. 0.1.3 fixed a problem where your node's communications could go dead after a while. The network is running much more smoothly now with this version.  If you've successfully generated a block, you've seen it has a maturation countdown before you can spend it. Once it matures, the Credit column will change from 0.00 to 50.00. For a block to be valid, it has to be broadcasted to the network and get into the block chain, which is why Generate does not run if you're not connected. If you generated a block without being connected, the network wouldn't know about it and would continue building the chain without it, leaving it behind, and the maturation countdown would change to "(not accepted)" when your node sees that it wasn't used. If you subtract 1 from the status column, that's how many blocks have been chained after yours. Satoshi Nakamoto ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Mon, Jan 12, 2009 at 11:59 PM Subject: Re: select failed 10038 fix To: hal.finney@gmail.com Definitely the disk full. I completely put off disk full handling until a later version. Probably about time I did it now. Well, that's a relief. Satoshi >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. > >I 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, > >EXCEPTION: NSt8ios_base7failureE >CAutoFile::read : end of file > >Normally this should be a rare occurrence with the large disk sizes >people have today. > >Hal > >On 1/12/09, Satoshi Nakamoto wrote: >> Could you send me the debug.log from the 0.1.3 crash? >> I can usually get a lot just from that. >> >> I'll send you the debug builds shortly. >> >> >>>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. >>> >>>Hal ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Tue, Jan 13, 2009 at 2:42 PM Subject: Re: disk full To: hal.finney@gmail.com 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. I 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. If there is a problem, it could easily be solved by deleting your block files, as follows: (exit Bitcoin and make sure it's stopped) cd /d "%appdata%\bitcoin" (backup this directory first) del blk0001.dat del blkindex.dat It'll then re-download the block chain. Your transactions and generated blocks show as 0/unconfirmed until it's done downloading. The 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. The 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. Satoshi >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. > >I 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, > >EXCEPTION: NSt8ios_base7failureE >CAutoFile::read : end of file > >Normally this should be a rare occurrence with the large disk sizes >people have today. > >Hal From satoshi@vistomail.com Tue Jan 13 07:55:20 2009 From satoshi@vistomail.com Tue Jan 13 07:55:20 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com > It actually posts the hash blocks to a Google Group called > 'proof-hashes', so similar result as if it were posting to Usenet. > > http://groups.google.com/group/proof-hashes > > Since I run that group, and it's sole purpose is to archive > proof-of-work hashes, feel free to join an account to have your system > post there as well if you like. Sweet, I was looking for a group like that on Usenet at one point to see what I would use if I needed, and nothing really fit. I'm sure Google groups is a lot easier to post to. There are some scenarios where a Usenet or Google group could be used as a supplemental defence. Bitcoin is at its most vulnerable in the beginning when the total network CPU power is small. That's offset by the fact that the incentive to attack it is also low when it's small. Hopefully the easy solution of just growing up and getting past that stage will work. If not, there are ways a Google group could help, if it really came to that. > Electronic currency and cryptography are two things that I am very > interested in so as you would assume I was drawn to this project > immediately when I saw it posted to the Cryptography email list. Feel > free to ping me for feedback or to test out new features, I'll be happy > to help out. We definitely have similar interests! You know, I think there were a lot more people interested in the 90's, but after more than a decade of failed Trusted Third Party based systems (Digicash, etc), they see it as a lost cause. I hope they can make the distinction, that this is the first time I know of that we're trying a non-trust based system. > When the > coins mature, will that generate a new 'credit' transaction, or will the > existing generation transaction line's credit field be updated? The existing transaction line will change. > Upon opening version 0.1.3, all four of my transaction entries still say > 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'. > Does this mean that some other node had extended the chain first and my > coins were generated in a dead branch? If so, why did the previous > instance of the software not detect this immediately and begin > generating coins in the winning branch? Bug in 0.1.0? You're right, sorry about that. It's the bug that was fixed in 0.1.3. The communications thread would get blocked, so you would make connections, but they would go silent after a while. When you found a block, you couldn't broadcast it to the network, so it didn't get into the chain. You weren't receiving anything either to know that the network had gone on without you, until you restarted it. The bug is also what caused bitcoin.exe to fail to exit. The communications thread was blocked and failed to exit. Bitcoin does a careful shutdown in case it might be in the middle of an important transaction, but actually it's completely safe to kill it. This is all fixed in 0.1.3. If you give me your IP, I'll send you some coins. > One other question I had... What prevents the single node with the most > CPU power from generating and retaining the majority of the BitCoins? > If every node is working independently of all others, if one is > significantly more powerful than the others, isn't it probable that this > node will reach the proper conclusion before other nodes? An > underpowered node may get lucky once in a while, but if they are at a > significant horsepower advantage I would expect the majority of BitCoins > to be generated by the most powerful node. It's not like a race where if one car is twice as fast, it'll always win. It's an SHA-256 that takes less than a microsecond, and each guess has an independent chance of success. Each computer's chance of finding a hash collision is linearly proportional to it's CPU power. A computer that's half as fast would get half as many coins. > I'll watch this instance and see how it goes... Let me know how it goes. If you have any trouble with it, send me your debug.log file. I can often figure out what went wrong just from that. Satoshi From satoshi@vistomail.com Thu Jan 15 19:15:23 2009 From satoshi@vistomail.com Thu Jan 15 19:15:23 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com > I've had that address for a while though so hopefully my dhcp > client is being successful at renewing and not losing my address. > It does change from time to time, but that address should be good > for a while. There's at least one node who's inbound IP keeps changing all the time within the same class B. Maybe every time the program is run. I wasn't expecting that. Do you mind if I CC the rest of this to bitcoin-list or Cryptography? BTW, bitcoin-list is: bitcoin-list@lists.sourceforge.net Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list > Dustin D. Trammell wrote: > > Satoshi Nakamoto wrote: > > You know, I think there were a lot more people interested in the 90's, > > but after more than a decade of failed Trusted Third Party based systems > > (Digicash, etc), they see it as a lost cause. I hope they can make the > > distinction that this is the first time I know of that we're trying a > > non-trust-based system. > > Yea, that was the primary feature that caught my eye. The real trick > will be to get people to actually value the BitCoins so that they become > currency. Hal sort of alluded to the possibility that it could be seen as a long-odds investment. 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 TTP gets cold feet. Even if it doesn't take off straight away, it's now available for use by the next guy who comes up with a plan that needs some kind of token or electronic currency. It could get started in a closed system or narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. 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. 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. Satoshi From satoshi@vistomail.com Thu Jan 15 19:46:35 2009 From satoshi@vistomail.com Thu Jan 15 19:46:35 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com I group attacks into two classes: 1) Attacks that can only be done by someone actually in the chain of communication 2) Attacks that can be done by anyone on the Internet from anywhere Type 1 exposes you to people in your house or company on your local LAN, admins at ISPs in between, and the LAN on the recipient's side. Type 2 exposes you to a billion people who can self-select to be attackers and get economy of scale when they develop one technique to attack multiple victims. Sending by IP requests a new public key, so yes, it's vulnerable to type 1 man-in-the-middle. If that's a concern, sending to a Bitcoin address doesn't have that vulnerability, although there's a small privacy tradeoff. I have a feeling most of the time people will get Bitcoin addresses off of non-SSL websites and unsigned cleartext e-mail, which is already vulnerable to type 1 and type 2 through DNS poisoning. One solution would be to use both the IP and Bitcoin addresses when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses the public key of the Bitcoin address to sign the new public key to prove that you're sending to who you think you are. If the system starts to be used for real business purposes, I will certainly implement that. Another solution is to use SSL. For now, it's pretty obvious that if you send to an IP, you didn't give any other identifying information about the recipient, so you're blindly sending to whoever answers that IP. Another feature for later is an option to encrypt your wallet. > If I understand how that is done correctly, you just compute the > transaction into the block chain and let the intended recipient > 'discover' it, correct? That's correct. > An alternative could be to allow the network > nodes to provide a resolution service, where they ask around for the > network address of a BitCoin address, and if that node is online, once a > consensus is agreed upon by the network for that address the sending > BitCoin application connects directly there. It would be nice to only need the Bitcoin address and have the IP worked out behind the scenes. Might have privacy or denial of service issues. Certainly before another sending method is implemented, there's plenty of time now to fully think through the design and make sure it's the best way. Satoshi Cryptography Mailing List Bitcoin v0.1 released 2009-01-16 16:03:14 UTC -  -  > Dustin D. Trammell wrote: > > Satoshi Nakamoto wrote: > > You know, I think there were a lot more people interested in the 90's, > > but after more than a decade of failed Trusted Third Party based systems > > (Digicash, etc), they see it as a lost cause. I hope they can make the > > distinction that this is the first time I know of that we're trying a > > non-trust-based system. > > Yea, that was the primary feature that caught my eye. The real trick > will be to get people to actually value the BitCoins so that they become > currency. 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 could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite. 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.  Satoshi Nakamoto http://www.bitcoin.org From satoshi@vistomail.com Fri Jan 16 18:42:18 2009 From satoshi@vistomail.com Fri Jan 16 18:42:18 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com > One thing that came to mind on this topic is the potential for BitCoin > loss if you have a system failure. The application doesn't seem to > store any data in the directory that it runs in, so I assume it's stored > in the registry and other places (haven't cracked out ProcessExplorer > yet to check myself), so it may be a good idea to have the application > be able to export everything that it needs for recovery to a file that > could be backed up off of the system. The files are in "%appdata%\Bitcoin", that's the directory to backup. The data is stored in a transactional database DBM, so it should be safe from loss if there's a crash or power failure. %appdata% is per-user access privilege. Most new programs like Firefox store their settings files there, despite the headwind of Microsoft changing the directory name with every Windows release and being full of spaces and so long it runs off the screen. > One other thing I noticed today is that if you close the application it > doesn't appear to cleanly close it's network sockets (TCP RST's start > flying). Probably an item for the low-priority todo list (: Just now added code to the next release for that. Satoshi ---------- Forwarded message ---------- From: Satoshi Nakamoto Date: Sat, Jan 24, 2009 at 4:47 PM Subject: Re: disk full To: hal.finney@gmail.com I hate duplicating code, but the compiler forces us. Copy the body of the function above it, like this: void insert(iterator it, const_iterator first, const_iterator last) { if (it == vch.begin() + nReadPos && last - first <= nReadPos) { // special case for inserting at the front when there's room nReadPos -= (last - first); memcpy(&vch[nReadPos], &first[0], last - first); } else vch.insert(it, first, last); } #if !defined(_MSC_VER) || _MSC_VER >= 1300 void insert(iterator it, const char* first, const char* last) { if (it == vch.begin() + nReadPos && last - first <= nReadPos) { // special case for inserting at the front when there's room nReadPos -= (last - first); memcpy(&vch[nReadPos], &first[0], last - first); } else vch.insert(it, first, last); } #endif The modified version of serialize.h is attached. BTW, 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. My 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. Satoshi From satoshi@vistomail.com Sun Jan 18 17:01:09 2009 From satoshi@vistomail.com Sun Jan 18 17:01:09 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com It should be your Bitcoin address at home that you received it with. There's no way for it to know who it's from, so the best it can do is tell which of your addresses it was received on. You can create multiple addresses and give a different address to each person and label them to help figure out who's sending to you. It doesn't know any names other than what you tell it. The name printed there is what's associated in your address book for that address, either under the Address Book button or the "Change..." button to the right of your Bitcoin address. >Hey Satoshi, > >After that first transfer of 25.00, you didn't send me another 100.00 >did you? I sent myself 100.00 from my BitCoin application at work to my >one at home using the BitCoin address rather than by IP. My application >at home has a 100.00 transfer received, however it's transaction details >say "Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv". That >is not my BitCoin address from work, so I assume this means that I >received the payment encoded with a block that was computed by your >client? If so, how did it know your name in addition to the BitCoin >address that generated it? I don't recall there being a place in my >application to even put my name. > >-- >Dustin D. Trammell >dtrammell@dustintrammell.com >http://www.dustintrammell.com > From satoshi@vistomail.com Mon Jan 19 17:02:37 2009 From satoshi@vistomail.com Mon Jan 19 17:02:37 2009 Return-Path: Delivered-To: dustintrammell-dtrammell@dustintrammell.com >On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote: >> It should be your Bitcoin address at home that you received it >> with. There's no way for it to know who it's from, so the best >> it can do is tell which of your addresses it was received on. >> You can create multiple addresses and give a different address >> to each person and label them to help figure out who's sending >> to you. > >Ah! I didn't even notice it was my address at home, you're right (: I >do have multiple addresses created at home so I didn't make the >connection. > >> It doesn't know any names other than what you tell it. The name >> printed there is what's associated in your address book for that >> address, either under the Address Book button or the "Change..." >> button to the right of your Bitcoin address. > >Ahh you're right, 'Satoshi' is associated with the address that received >the payment under the Change button's addresses. I don't recall setting >that value though, is that the default or something? (this is the first, >default, address that the application generated itself when I first ran >it) The first default one is labelled "Your Address" when it's created. All 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. 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. Satoshi Cryptography Mailing List Bitcoin v0.1 released 2009-01-25 15:47:10 UTC -  -  Hal Finney wrote: > > * Spammer botnets could burn through pay-per-send email filters > > trivially > If POW tokens do become useful, and especially if they become money, > machines will no longer sit idle. Users will expect their computers to > be earning them money (assuming the reward is greater than the cost to > operate). A computer whose earnings are being stolen by a botnet will > be more noticeable to its owner than is the case today, hence we might > expect that in that world, users will work harder to maintain their > computers and clean them of botnet infestations. Another factor that would mitigate spam if POW tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They'd essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don't read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective.  The process has the potential to establish the POW token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers. Interestingly, one of the e-gold systems already has a form of spam called "dusting". Spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field. If the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam. Satoshi Nakamoto bitcoin-list Re: [bitcoin-list] Problems 2009-01-25 16:45:25 UTC -  -  From: Nicholas Bohm 2009-01-25 10:17 > I have had a couple of problems running bitcoin: is this an appropriate > list for reporting them (with about 70kb of attachments)? What's the problem you're having? If you send me your debug.log file directly (best not to send attachments to the list), I can take a look at what's happening. Satoshi Nakamoto bitcoin-help at vistomail dot com bitcoin-list [bitcoin-list] Bitcoin v0.1.5 released 2009-02-04 19:46:04 UTC -  -  Version 0.1.5 is now available. It includes the fix for the problem Nicholas had, checking for disk full and changes to try to improve things that were confusing. Special thanks to Nicholas and Dustin for all their help and feedback! Download link: http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441 Changes: - disk full warning - fixed a bug that could occur if dns lookup failed - prevent entering your own address in the address book, which confusingly changed the label for your own address - moved change address button to menu under options - tweaks to make it get connected faster - close sockets on exit - created minimum fee for transactions less than 1 cent - hid the transaction-type selection box that only had one choice - cleaned up ParseMoney a little - slightly cleaner reformatting of message text - changed the font in transaction details dialog - added some explanation text to transaction details for generated coins - reworded the description for transactions received with bitcoin address Satoshi Nakamoto http://www.bitcoin.org P2P Foundation Bitcoin open source implementation of P2P currency 2009-02-11 22:27:00 UTC -  -  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: Download 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. It'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. One 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. Bitcoin'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 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. Satoshi Nakamoto http://www.bitcoin.org P2P Foundation Bitcoin open source implementation of P2P currency 2009-02-15 16:42:00 UTC -  -  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. 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. P2P Foundation Bitcoin open source implementation of P2P currency 2009-02-18 20:50:00 UTC -  -  It is a global distributed database, with additions to the database by consent of the majority, based on a set of rules they follow: - Whenever someone finds proof-of-work to generate a block, they get some new coins - The proof-of-work difficulty is adjusted every two weeks to target an average of 6 blocks per hour (for the whole network) - 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. As an example, if there are 1000 nodes, and 6 get coins each hour, it would likely take a week before you get anything. 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. 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. 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. bitcoin-list Re: [bitcoin-list] Bitcoin v0.1.5 released 2009-02-22 17:47:52 UTC -  -  > What's next? The next thing for v0.1.6 is to take advantage of multiple processors to generate blocks. Currently it only starts one thread. If you have a multi-core processor like a Core Duo or Quad this will double or quadruple your production. Later I want to add interfaces to make it really easy to integrate into websites from any server side language. Satoshi http://www.bitcoin.org bitcoin-list Re: [bitcoin-list] Bitcoin v0.1.5 released 2009-03-04 16:59:12 UTC -  -  Hal Finney wrote: > That sounds good. I'd also like to be able to run multiple coin/block > generators on multiple machines, all behind a single NAT address. I > haven't tried this yet so I don't know if it works on the current > software. The current version will work fine. They'll each connect over the Internet, while incoming connections only come to the host that port 8333 is routed to.  As an optimisation, I'll make a switch "-connect=1.2.3.4" to make it only connect to a specific address. You could make your extra nodes connect to your primary, and only the primary connects over the Internet. It doesn't really matter for now, since the network would have to get huge before the bandwidth is anything more than trivial. > BTW I don't remember if we talked about this, but the other day some > people were mentioning secure timestamping. You want to be able to > prove that a certain document existed at a certain time in the past. > Seems to me that bitcoin's stack of blocks would be perfect for this. Indeed, Bitcoin is a distributed secure timestamp server for transactions. A few lines of code could create a transaction with an extra hash in it of anything that needs to be timestamped.  I should add a command to timestamp a file that way. > > > Later I want to add interfaces to make it really easy to integrate > > > into websites from any server side language. > > Right, and I'd like to see more of a library interface that could be > called from programming or scripting languages, on the client side as > well. Exactly. Satoshi Nakamoto http://www.bitcoin.org Mike Hearn  Sun, Apr 12, 2009 at 12:46 PM To: satoshin@gmx.com Hi Satoshi, I read your paper on BitCoin with great interest. I found it a bit confusing though - I believe it may be easier to follow if you provide some examples. Specifically, it's not quite clear to me what blocks contain. If I understand correctly, there is only one (or maybe a few) global chain[s] into which all transactions are hashed. If there is only one chain recording "the story of the economy" so to speak, how does this scale? In an imaginary planet-wide deployment there would be millions of even billions of transactions per hour being hashed into the chain. I realize that each PoW can wrap many transactions in one block, nonetheless, that's a large amount of data to hash. If there are many chains, how are transactions assigned to each chain such that it is still difficult to overpower the network? Eg, if there are 10 global chains, the amount of cpu power you need to beat the system is only 10% of what it was previously. I also wonder if the assumption of 1 core = 1 vote is sound. If the majority of nodes are on standard computers, it seems likely that an attacker could use FPGA or custom ASICs to get significantly better performance. What are your thoughts on using custom hardware to beat the chain? I found the section on incentives hard to follow. In particular, I'm not clear on what triggers the transition from minting new coins as a reason to run a node, to charging transaction fees (isn't the point of BitCoin largely to zero transaction costs anyway?). Presumably there's some human in charge of the system - eg, you decided somehow that 24 million coins was a good number to have, and would distribute some kind of rules file saying "coins minted after this timestamp must have an N+1 zero bits prefix", which honest nodes enforce. How did you decide on the inflation schedule for v1? Where did 24 million coins come from? What denominations are these coins? You mention a way to combine and split value but I'm not clear on how this works. For instance are bitcoins always denominated by an integer or can you have fractional bitcoins? So many questions :) But it's rare that I encounter truly revolutionary ideas. The last time I was this excited about a new monetary scheme was when I discovered Ripple. If you have any thoughts on Ripple, I'd also love to hear them. thanks -mike Satoshi Nakamoto  Sun, Apr 12, 2009 at 10:44 PM To: Mike Hearn Hi Mike, I'm glad to answer any questions you have.  If I get time, I ought to write a FAQ to supplement the paper. There is only one global chain. The 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. By 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. I 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. Eventually, 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. A 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. My 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. Ripple is interesting in that it's the only other system that does something with trust besides concentrate it into a central server. Satoshi [Quoted text hidden] Mike Hearn  Mon, Apr 13, 2009 at 1:39 PM To: Satoshi Nakamoto Thanks Satoshi, I tried the app yesterday. It seems to work pretty well running on Wine (I tried it on MacOS but it should run on Linux too, and will try that next week when I am back at work). In the lower right hand corner it has a block count which increases rapidly and then stops. Is this the length of the global chain? It seems to advance far too fast for that. Or is this the number of genesis blocks that have been tried but did not result in a partial collision? I'm not sure if the way it stops and starts is expected, or some glitch caused by it running under emulation. My best guess - it is the length of the global chain, and the rapid advance at the start is as the software downloads and verifies the preceding blocks in the chain as being valid. With regards to the buyer/seller experience, I understand that the global chain advances at about 6-7 blocks per hour under the current settings. If we assume that 0.1% is a good risk rate, then z=5 thus any transaction must wait a bit less than an hour before being solidified in the chain. As micropayments for things like web content or virtual goods are by definition something that requires low overhead, waiting an hour seems like quite a significant hurdle. I understand that nodes attempt to find a POW to advance the global chain in an uncoordinated fashion. This sentence however:     "If a majority of CPU power is controlled by honest nodes, the honest chain will grow the  fastest and outpace any competing chains." is confusing for me, because it appears the only way the honest chain can grow faster than a chain worked on by 1 attacking cpu is if the keyspace to scan looking for a partial collision is sharded evenly amongst the participating honest nodes. That way the speed at which collisions are found would be proportional to the number of nodes. Yet I don't see any discussion of such work sharding, which obviously adds complexity. Likewise:    "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." How is the required difficulty of each block communicated through the network and agreed upon? Thanks once again. I have yet more questions but this is enough for one email :) I will be happy to summarize these discussions into an FAQ-like document at some point. Apologies if the questions seem trivial. -mike [Quoted text hidden] Mike Hearn  Mon, Apr 13, 2009 at 10:51 PM To: Satoshi Nakamoto Something else that isn't clear to me - does the global chain only get extended when there is actual work to do? Currently it seems to grow all the time, although there are only a few people in the network. So presumably it gets extended with null blocks. Is this actually required? The timestamping doesn't have to be actually in parallel with real time does it ... it's merely establishing an ordering of events. [Quoted text hidden] Satoshi Nakamoto  Mon, Apr 13, 2009 at 11:00 PM To: Mike Hearn Mike Hearn wrote: My best guess - it is the length of the global chain, and the rapid advance at the start is as the software downloads and verifies the preceding blocks in the chain as being valid. Right.  I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain". If we assume that 0.1% is a good risk rate, then z=5 thus any transaction must wait a bit less than an hour before being solidified in the chain. As micropayments for things like web content or virtual goods are by definition something that requires low overhead, waiting an hour seems like quite a significant hurdle. For the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers. For 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. Currently, 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. The 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. Anything 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. is confusing for me, because it appears the only way the honest chain can grow faster than a chain worked on by 1 attacking cpu is if the keyspace to scan looking for a partial collision is sharded evenly amongst the participating honest nodes. That way the speed at which collisions are found would be proportional to the number of nodes. Yet I don't see any discussion of such work sharding, which obviously adds complexity. The 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. How is the required difficulty of each block communicated through the network and agreed upon? It'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. Thanks once again. I have yet more questions but this is enough for one email :) I will be happy to summarize these discussions into an FAQ-like document at some point. Apologies if the questions seem trivial. No problem, thanks for testing it on Mac Wine. Satoshi [Quoted text hidden] Satoshi Nakamoto  Mon, Apr 13, 2009 at 11:11 PM To: Mike Hearn 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. As you say, it's the order of events that matters. [Quoted text hidden] Mike Hearn  Mon, Apr 13, 2009 at 11:18 PM To: Satoshi Nakamoto Oh yes, of course, that's fundamental. Silly me. Thanks for your answers. I'd recommend being over-explicit for early versions of the software, something like  "Global chain is currently %d blocks long". I guess the key problem right now is that once you generate coins, there's nobody to test it with, even for dummy transactions. Is there a plan for a mailing list or some kind of trivial marketplace to give people something to do with their newly minted bitcoins? Satoshi Nakamoto  Tue, Apr 14, 2009 at 7:41 PM To: Mike Hearn 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. If 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. [Quoted text hidden] Mike Hearn  Sat, Apr 18, 2009 at 3:08 PM To: Satoshi Nakamoto Hi Satoshi, I sent you 32.51 coins, my bitcoin address is 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7rnj5n My IP is currently 84.73.233.199, however, it's a laptop so may or may not be online at the time you act on this mail. I suggest using the bitcoin address instead. It'd be convenient if the same comment functionality was available via indirect transfer. Can the comment be encrypted using the public key of the receiver and placed into a block? [Quoted text hidden] Satoshi Nakamoto  Sat, Apr 18, 2009 at 6:16 PM To: Mike Hearn I sent back 32.51 and 50.00. I 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. [Quoted text hidden] Mike Hearn  Sat, Apr 18, 2009 at 9:25 PM To: Satoshi Nakamoto Thanks. I sent you back 50, so now we're even. For some reason your transfer to me shows up as "From: unknown" even though I added you to my address book. I have a "Generated (not accepted)" line in my transaction list, it seems like an attempt to generate a coin went wrong somehow. Not sure what happened here - presumably my node successfully solved a block but then I went offline before it was sent to the network? I suppose for sending metadata with a transaction some other mechanism will be needed, for instance, broadcast of encrypted messages associated with a transaction that persist for (say) a month, with some kind of budget on how much storage a node can use for messages. Alternatively, a payee could generate some reference number which is of some significance to themselves but otherwise opaque, and give it to the payer, thus it does not need to be encrypted and can be put into the block directly. [Quoted text hidden] Satoshi Nakamoto  Sat, Apr 18, 2009 at 10:52 PM To: Mike Hearn Got the 50. Transactions 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. The "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. [Quoted text hidden] Mike Hearn  Sat, Apr 18, 2009 at 11:23 PM To: Satoshi Nakamoto Yes, I believe most P2P clients use the UPnP protocol to get routers to open up the port automatically. That would probably improve the listen rate significantly. I just discovered DMZ wasn't enabled on my router, though I thought it was. That's now fixed. Is there a way to be told of new versions? Does the app auto update itself? Again, some kind of mailing list would be excellent. I was thinking through how a practical micropayment implementation for the web might work in the last few days. One key issue is ensuring micropayments are fully automatic, yet can't be easily abused to drain the users account. I think the right approach would be to allow any website that presents an EV SSL cert to automatically request a micropayment, by default the browser always accepts as long as the charge is "low" and displays a small notification of what has occurred. Sites can then show that content requires payment in any way that suits their site design. Abusive sites that don't meet some simple guidelines (eg, showing unambiguously that clicking a link will trigger payment, or taking payment from direct search engine links) would simply have their SSL cert blacklisted, much like anti-phishing filters work today. The protocol could be very straightforward and implemented by a Firefox extension or an IE BHO. Some static file (eg, a protocol buffer) is hosted on the site. It specifies the charge, a transaction description, the target IP and a URL for the browser to load after the transaction was accepted by the target node, to which the user identifier is sent in a URL parameter.  The site can then give back a cookie and the paywalled content. The entire process is automatic and simply results in, say, a little coin animation in the URL bar. Thus it's as convenient as regular web browsing. The users software would have some limit on what payments are automatically accepted. The main problem with this approach is that somebody has to decide what the user interface guidelines are, then enforce them via blacklisting, as well as decide what payment requirements are low enough to be automatic vs requiring a user prompt. This introduces a trusted authority back into the system. However, it's one that the user can choose in an open market. By the way, if you're not already using protocol buffers for the node-to-node traffic, I recommend them. We use them here at Google for everything, they solve a lot of versioning problems simply and efficiently. Satoshi Nakamoto  Sun, Apr 19, 2009 at 2:14 AM To: Mike Hearn The list is: bitcoin-list@lists.sourceforge.net Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list I'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. Your 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. I 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. Lack of chargeback support 4 messages Mike Hearn  Sat, Apr 25, 2009 at 9:30 PM To: Satoshi Nakamoto Hi Satoshi, I just read the following wiki page: http://en.wikipedia.org/wiki/Chargeback which claims that "U.S. debit card holders are guaranteed reversal rights by Federal Reserve Regulation E under the Electronic Funds Transfer Act. Similar rights extend globally pursuant to the rules established by the corresponding card association or bank network." The "Electronic Funds Transfer Act" sounds awfully generic, do you think it'd apply to BitCoin? If so, would the inability to do chargebacks risk making it illegal? Satoshi Nakamoto  Mon, Apr 27, 2009 at 12:11 AM To: Mike Hearn 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. Bitcoin is fundamentally designed to be able to do non-reversible transactions, and there certainly are applications that need that. If 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. Martii Malmi (AKA Sirius) “COPA trial” email #1 (these Martii Malmi-Satoshi emails became public in February of 2024, see https://mmalmi.github.io/satoshi/) Date: Sat, 02 May 2009 18:06:58 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: Martti Malmi Thanks for starting that topic on ASC, your understanding of bitcoin is spot on. Some of their responses were rather Neanderthal, although I guess they're so used to being anti-fiat-money that anything short of gold isn't good enough. They concede that something is flammable, but argue that it'll never burn because there'll never be a spark. Once it's backed with cash, that might change, but I'd probably better refrain from mentioning that in public anymore until we're closer to ready to start. I think we'll get flooded with newbies and we need to get ready first. What we need most right now is website writing. My writing is not that great, I'm a much better coder. Maybe you could create the website on sourceforge, which is currently blank. If you can write a FAQ, I can give you a compilation of my replies to questions in e-mail and forums for facts and details and ideas. Codewise, there's not much that's easy right now. One thing that's needed is an interface for server side scripting languages such as Java, Python, PHP, ASP, etc. Bitcoin would be running on the web server, and server side script could call it to do transactions. It's Windows, so I guess OLE/COM is the interface. One easy thing that really helps is to run a node that can accept incoming connections (forward port 8333 on your firewall) to make sure that new users who try it out have someone to connect to. If they run it and get no connections, they'll probably just give up. Satoshi Martti Malmi wrote: > Message body follows: > > Hello, > > I'm Trickstern from the anti-state.com forum, and I would > like to help with Bitcoin, if there's something I can do. > > I have a good touch on Java and C languages from school > courses (I'm studying CS), but not so very much development > experience yet. I think I could learn the C++ tricks quite > easily on that basis. I could also do testing or > documentation. > > Best regards, > Martti Malmi Martii Malmi (AKA Sirius) “COPA trial” email #3 Date: Sun, 03 May 2009 23:32:26 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > All right, I can do the website and the FAQ. I'll start writing the FAQ > now with the questions that I can think of. That would be great! I added you (dmp1ce) as a dev to the sourceforge project and gave you access to edit the web space and everything. > I have a feature suggestion for the program: a UI tool for creating > password protected private keys and saving them into a custom location. > Backups of the key will be needed to be safe from losing the control of > your coins, and for using the coins on more than one computers. Password > protection would be needed to make using your money more difficult for > someone who happens to find your key file. Definitely. This will be an absolutely essential feature once things get going, making it so you can lock your wealth up with strong encryption and back it up more securely than any physical safe. So far I've been putting it off in favour of other features because it's not crucial yet until bitcoins start to have value. I plan to work on the escrow feature next, which is needed to make actual trades for physical stuff safer and before backing the currency with fiat money can begin. > I'm running a bitcoin node always when my PC is powered on, which means > about 24/7. Bitcoin is a great project, and it's really cool to > participate! Thanks! Right now there are a lot of people on the network who can't receive incoming connections, so every node that can really helps. Having more helps keep down the "(not accepted)" issue for now until I reduce the chances of that happening in v0.1.6. I guess one answer for the FAQ should be how to set up your firewall to forward port 8333 so you can receive incoming connections. The question could be something like "what if I have 0 connections" and that could be the answer that it might be because the nodes you can connect with is limited if you don't set that up. Here's a compilation of questions I've answered in forums and e-mail that should help you see what questions are frequently asked and some answers I've used. It's not intended to use all or most of the material here, just pick and choose. This is just a dump of everything I've answered. Some issues that we don't have easy answers for are best not to bring up. Casual users seems content to assume that the system works as stated (which it does), and getting into the design details just opens a can of worms that can't be answered without a deep understanding of the system. The advanced questions I've received have mostly been unique per person and best answered individually. **** QUESTION AND ANSWER DUMP **** Any questions used for the FAQ should probably be rephrased. questions: > The bottom of the UI shows: > > Generating 4 connections 4024 blocks 164 transactions > > I understand "generating"; I assume I am connected to 4 other nodes; and > I know I have recorded 164 transactions (including failed generation > attempts). I'm not clear what the "blocks" figure describes. It's much > smaller than the total of all the blocks shown against all my transactions. > It's the total number of blocks in the block chain, meaning the network's block chain, which everyone has a copy of. Every Bitcoin node displays the same number and it goes up about every 10 minutes whenever someone generates a block. When you haven't had it running for a while, once you're connected it spins up rapidly as it downloads what was generated while you were gone to catch up. I'm not sure exactly how to describe it (that would fit on the status bar in 1 word, maybe 2 words max), any ideas? The blocks number in the status column next to your transactions is the number of blocks that have come after that transaction. Your transaction is essentially "in" that many blocks. Satoshi > My best guess - it > is the length of the global chain, and the rapid advance at the start > is as the software downloads and verifies the preceding blocks in the > chain as being valid. Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain". > I'm having an unusual run of (block not-accepted) failures, and thought I'd let you know in > case this was of any significance. What rate of not-accepted did you see? I didn't see anything unusual on my end. If you had more than, say, 4 in a row, that would be abnormal and probably a loss of network communication. If it's scattered and less than 25%, just random bad luck. It's normal and harmless to randomly get some per cent of not-accepted, and of course randomness can sometimes bunch up and look like a pattern. The idea of an option to View/Hide unaccepted blocks is a good one, as well as View/Hide all generated blocks so you can more easily see incoming transactions. Seeing the unaccepted blocks is just annoying and frustrating. Everyone faces the same rate of unaccepted, it's just a part of the process. It would probably be best to default to hide unaccepted blocks, so as not to show giving and taking away something that never was, and not show new generated blocks at all until they have at least one confirmation. It would only mean finding out you have a generated block 15 minutes later than normal, and then you still have 119 blocks to go before it matures anyway. This is on the to-do list for v0.1.6. Satoshi [note: I have some improvements in 0.1.6 to reduce this problem somewhat, and it'll also improve when the network is larger] > For some reason your transfer to me shows up as "From: unknown" even > though I added you to my address book. > > I have a "Generated (not accepted)" line in my transaction list, it > seems like an attempt to generate a coin went wrong somehow. Not sure > what happened here - presumably my node successfully solved a block > but then I went offline before it was sent to the network? Transactions 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. I 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. The "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. > ...So far it has two "Generated" messages, however the > "Credit" field for those is 0.00 and the balance hasn't changed. Is > this due to the age/maturity requirement for a coin to be valid? Right, the credit field stays 0.00 until it matures, then it'll be 50.00. BTW, you can doubleclick on a line for details. > ...understand correctly, there is only one (or maybe a few) global > chain[s] into which all transactions are hashed. If there is only one > chain recording "the story of the economy" so to speak, how does this > scale? In an imaginary planet-wide deployment there would be millions > of even billions of transactions per hour being hashed into the chain... > ...I found the section on incentives hard to follow. In particular, I'm > not clear on what triggers the transition from minting new coins as a > reason to run a node, to charging transaction fees (isn't the point of > BitCoin largely to zero transaction costs anyway?). Presumably there's > some human in charge of the system... > ...How did you decide on the inflation schedule for v1? Where did 21 > million coins come from? What denominations are these coins? You > mention a way to combine and split value but I'm not clear on how this > works. For instance are bitcoins always denominated by an integer or > can you have fractional bitcoins?... > ...it's rare that I encounter truly > revolutionary ideas. The last time I was this excited about a new > monetary scheme was when I discovered Ripple. If you have any thoughts > on Ripple, I'd also love to hear them. There is only one global chain. The 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. By 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. I 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. A 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. My 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. Ripple is interesting in that it's the only other system that does something with trust besides concentrate it into a central server. Satoshi > If we assume that 0.1% is a good risk rate, then z=5 thus > any transaction must wait a bit less than an hour before being > solidified in the chain. As micropayments for things like web content > or virtual goods are by definition something that requires low > overhead, waiting an hour seems like quite a significant hurdle. For the actual risk, multiply the 0.1% by the probability that the buyer is an attacker with a huge network of computers. For 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. Currently, 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. The 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. Anything 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. > How is the required difficulty of each block communicated through the > network and agreed upon? It'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. > Is the code free/open source or just open source? It's free open source. It's the MIT license, which just requires some disclaimer text be kept with the source code, other than that you can do just about anything you want with it. The source is included in the main download. Satoshi > Is there a way to be told of new versions? Does the app auto update > itself? Some kind of mailing list would be excellent. The list is: bitcoin-list@lists.sourceforge.net Subscribe/unsubscribe page: http://lists.sourceforge.net/mailman/listinfo/bitcoin-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list I'll always announce new versions there. Automatic update, or at least notification of new versions, is definitely on the list. [this inflation discussion was before the transaction fee mechanism and fixed plan of 21 million coins was posted, so it may not be as applicable anymore] > Since they can be created for free (or at the cost > of computer power people have anyway for other reasons), > monetizing them means simply giving away money. You're still thinking as if the difficulty level will be so easy that people will be able to generate all the bitcoins they want. Imagine you have to run your computer 24/7 for a month to generate 1 cent. After a year, you could generate 12 cents. That's not going to make it so people can just generate all the bitcoin they want for spending. The value of bitcoins would be relative to the electricity consumed to produce them. All modern CPUs save power when they're idle. If you run a computational task 24/7, not letting it idle, it uses significantly more power, and you'll notice it generates more heat. The extra wattage consumed goes straight to your power bill, and the value of the bitcoins you produce would be something less than that. > Why would they, when they make money by generating > new ones No, they can't make money that way. It would cost them more in electricity than they'd be selling the bitcoins for. Historically, people have taken up scarce commodities as money, if necessary taking up whatever is at hand, such as shells or stones. Each has a kernel of usefulness that helped bootstrap the process, but the monetary value ends up being much more than the functional value alone. Most of the value comes from the value that others place in it. Gold, for instance, is pretty, non-corrosive and easily malleable, but most of its value is clearly not from that. Brass is shiny and similar in colour. The vast majority of gold sits unused in vaults, owned by governments that could care less about its prettiness. Until now, no scarce commodity that can be traded over a communications channel without a trusted third party has been available. If there is a desire to take up a form of money that can be traded over the Internet without a TTP, then now that is possible. Satoshi > As more capable > computer hardware comes out, the natural supply per user > doubles at every cycle of Moore's law. Actually, that is handled. There's a moving average that compensates for the total effort being expended so that the total production is a constant. As computers get more powerful, the difficulty increases to compensate. > I do not recall any economic history of a commodity subject > to natural inflation ever being used as money There's gold for one. The supply of gold increases by about 2%-3% per year. Any fiat currency typically averages more inflation than that. > Won't there be massive inflation as computers get faster and are able to solve the proof-of-work problem faster? The difficulty is controlled by a moving average that compensates for the total effort being expended to keep the total production constant. As computers get more powerful, the difficulty increases to compensate. > If someone double spends, then the transaction record > can be unblinded revealing the identity of the cheater? Identities are not used, and there's no reliance on recourse. It's all prevention. > ...You're saying > there's no effort to identify and exclude nodes that don't > cooperate? I suspect this will lead to trouble and possible DOS > attacks. There is no reliance on identifying anyone. As you've said, it's futile and can be trivially defeated with sock puppets. The credential that establishes someone as real is the ability to supply CPU power. > But in the absence of identity, there's no downside to them > if spends become invalid, if they've already received the > goods they double-spent for (access to website, download, > whatever). The merchants are left holding the bag with > "invalid" coins, unless they wait that magical "few blocks" > (and how can they know how many?) before treating the spender > as having paid. > > The consumers won't do this if they spend their coin and it takes > an hour to clear before they can do what they spent their coin on. > The merchants won't do it if there's no way to charge back a > customer when they find the that their coin is invalid because > the customer has doublespent. This is a version 2 problem that I believe can be solved fairly satisfactorily for most applications. 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. 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. Information based goods like access to website or downloads are non-fencible. Nobody is going to be able to make a living off stealing access to websites or downloads. They can go to the file sharing networks to steal that. Most instant-access products aren't going to have a huge incentive to steal. 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. Satoshi [in response to a question about scale] 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. To 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. Important 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. Satoshi > One other question I had... What prevents the single node with the most > CPU power from generating and retaining the majority of the BitCoins? > If every node is working independently of all others, if one is > significantly more powerful than the others, isn't it probable that this > node will reach the proper conclusion before other nodes? An > underpowered node may get lucky once in a while, but if they are at a > significant horsepower advantage I would expect the majority of BitCoins > to be generated by the most powerful node. It's not like a race where if one car is twice as fast, it'll always win. It's an SHA-256 that takes less than a microsecond, and each guess has an independent chance of success. Each computer's chance of finding a hash collision is linearly proportional to it's CPU power. A computer that's half as fast would get half as many coins. [question about what to backup] The files are in "%appdata%\Bitcoin", that's the directory to backup. %appdata% is per-user access privilege. Most new programs like Firefox store their settings files there, despite the headwind of Microsoft changing the directory name with every Windows release and being full of spaces and so long it runs off the screen. [question about what to backup] The directory is "%appdata%\Bitcoin" It has spaces in it so you need the quotes cd "%appdata%\bitcoin" On XP it would typically be: C:\Documents and Settings\[username]\Application Data\Bitcoin Backup that whole directory. All data files are in that directory. There are no temporary files. [question about what to backup] The 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. The 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. > > You know, I think there were a lot more people interested in the 90's, > > but after more than a decade of failed Trusted Third Party based systems > > (Digicash, etc), they see it as a lost cause. I hope they can make the > > distinction that this is the first time I know of that we're trying a > > non-trust-based system. > > Yea, that was the primary feature that caught my eye. The real trick > will be to get people to actually value the Bitcoins so that they become > currency. Hal sort of alluded to the possibility that it could be seen as a long-odds investment. 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. 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. [this next bit turned out to be very controversial. there is extreme prejudice against spam solutions, especially proof-of-work.] 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. [again, I don't know why I'm including this, as it's best to stay away from claims about spam. people automatically react violently against any suggestion of a spam solution.] > Spammer botnets could burn through pay-per-send email filters > trivially (as usual, the costs would fall on people other than the > botnet herders & spammers). Then you could earn a nice profit by setting up pay-per-send e-mail addresses and collecting all the spam money. You could sell it back to spammers who don't have big enough botnets to generate their own, helping bootstrap the currency's value. As more people catch on, they'll set up more and more phony addresses to harvest it. By the time the book "How I got rich exploiting spammers and you can too" is coming out, there'll be too many fake addresses and the spammers will have to give up. > > * Spammer botnets could burn through pay-per-send email filters > > trivially > If POW tokens do become useful, and especially if they become money, > machines will no longer sit idle. Users will expect their computers to > be earning them money (assuming the reward is greater than the cost to > operate). A computer whose earnings are being stolen by a botnet will > be more noticeable to its owner than is the case today, hence we might > expect that in that world, users will work harder to maintain their > computers and clean them of botnet infestations. One more factor that would mitigate spam if POW tokens have value: there would be a profit motive for people to set up massive quantities of fake e-mail accounts to harvest POW tokens from spam. They'd essentially be reverse-spamming the spammers with automated mailboxes that collect their POW and don't read the message. The ratio of fake mailboxes to real people could become too high for spam to be cost effective. The process has the potential to establish the POW token's value in the first place, since spammers that don't have a botnet could buy tokens from harvesters. While the buying back would temporarily let more spam through, it would only hasten the self-defeating cycle leading to too many harvesters exploiting the spammers. Interestingly, one of the e-gold systems already has a form of spam called "dusting". Spammers send a tiny amount of gold dust in order to put a spam message in the transaction's comment field. If the system let users configure the minimum payment they're willing to receive, or at least the minimum that can have a message with it, users could set how much they're willing to get paid to receive spam. > The last thing we need is to deploy a system designed to burn all > available cycles, consuming electricity and generating carbon dioxide, > all over the Internet, in order to produce small amounts of bitbux to > get emails or spams through. > > Can't we just convert actual money in a bank account into bitbux -- > cheaply and without a carbon tax? Please? Ironic if we end up having to choose between economic liberty and conservation. Unfortunately, proof of work is the only solution I've found to make p2p e-cash work without a trusted third party. Even if I wasn't using it secondarily as a way to allocate the initial distribution of currency, PoW is fundamental to coordinating the network and preventing double-spending. If it did grow to consume significant energy, I think it would still be less wasteful than the labour and resource intensive conventional banking activity it would replace. The cost would be an order of magnitude less than the billions in banking fees that pay for all those brick and mortar buildings, skyscrapers and junk mail credit card offers. Satoshi > BTW I don't remember if we talked about this, but the other day some > people were mentioning secure timestamping. You want to be able to > prove that a certain document existed at a certain time in the past. > Seems to me that bitcoin's stack of blocks would be perfect for this. Indeed, Bitcoin is a distributed secure timestamp server for transactions. A few lines of code could create a transaction with an extra hash in it of anything that needs to be timestamped. I should add a command to timestamp a file that way. From a thread on p2presearch which starts with my rant about trust being the root weakness of all conventional financial systems. http://listcultures.org/pipermail/p2presearch_listcultures.org/2009-February/thread.html 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: Download 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. It'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. One 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. Bitcoin'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 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. Satoshi Nakamoto http://www.bitcoin.org Martien van Steenbergen Martien at AardRock.COM Thu Feb 12 08:40:53 CET 2009 Very interesting. Is this akin to David Chaum's anonymous digital money? His concept makes sure money is anonymous unless it is compromised, i.e. the same money spent more than once. As soon as it's compromised, the ‘counterfeiter’ is immediately publicly exposed. Also, in bitcoin, is there a limited supply of money (that must be managed)? Or is money created exaclty at the moment of transaction? Succes en plezier, Martien. Martien van Steenbergen wrote: > Very interesting. Is this akin to David Chaum's anonymous digital money? > His concept makes sure money is anonymous unless it is compromised, i.e. > the same money spent more than once. As soon as it's compromised, the > ‘counterfeiter’ is immediately publicly exposed. It's similar in that it uses digital signatures for coins, but different in the approach to privacy and preventing double-spending. The recipient of a Bitcoin payment is able to check whether it is the first spend or not, and second-spends are not accepted. There isn't an off-line mode where double-spenders are caught and shamed after the fact, because that would require participants to have identities. To protect privacy, key pairs are used only once, with a new one for every transaction. The owner of a coin is just whoever has its private key. Of course, the biggest difference is the lack of a central server. That was the Achilles heel of Chaumian systems; when the central company shut down, so did the currency. > Also, in bitcoin, is there a limited supply of money (that must be > managed)? Or is money created exaclty at the moment of transaction? There is a limited supply of money. Circulation will be 21,000,000 coins. Transactions only transfer ownership. Thank you for your questions, Satoshi Martien van Steenbergen wrote: > Reminds me of: > > * AardRock » Wizard Rabbit Treasurer > ; and > * AardRock » Pekunio Indeed, it is much like Pekunio in the concept of spraying redundant copies of every transaction to a number of peers on the network, but the implementation is not a reputation network like Wizard Rabbit Treasurer. In fact, Bitcoin does not use reputation at all. It sees the network as just a big crowd and doesn't much care who it talks to or who tells it something, as long as at least one of them relays the information being broadcast around the network. It doesn't care because there's no way to lie to it. Either you tell it crypto proof of something, or it ignores you. > Are you familiar with Ripple? As trust systems go, Ripple is unique in spreading trust around rather than concentrating it. [I've been asked at least 4 other times "have you heard of Ripple?"] Michel Bauwens wrote: > how operational is your project? how soon do you think people will be > able to use it in real life? It's fully operational and the network is growing. If you try the software, e-mail me your Bitcoin address and I'll send you a few coins. We just need to spread the word and keep getting more people interested. Here's a link to the original introduction of the paper on the Cryptography mailing list. (Inflation issues were superseded by changes I made later to support transaction fees and the limited circulation plan. This link is a moving target, this archive page is just a certain number of days back and the discussion will keep scrolling off to the next page.) http://www.mail-archive.com/cryptography@metzdowd.com/mail3.html A little follow up when the software was released. http://www.mail-archive.com/cryptography@metzdowd.com/mail2.html My description of how Bitcoin solves the Byzantine Generals' problem: http://www.bitcoin.org/byzantine.html Martii Malmi (AKA Sirius) “COPA trial” email #5 Date: Mon, 04 May 2009 16:51:00 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi Oh crap, I got your sourceforge usernames mixed up, sorry about that. I clicked on the wrong e-mail when I was looking for your username. You now have access. Your FAQ looks good so far! You can create whatever you want on bitcoin.sourceforge.net. Something to get new users up to speed on what Bitcoin is and how to use it and why, and clean and professional looking would help make it look well established. The site at bitcoin.org was designed in a more professorial style when I was presenting the design paper on the Cryptography list, but we're moving on from that phase. You should probably change the part about "distribute them under several keys". When the paper says that it means for the software to do it, and it does. For privacy reasons, the software already uses a different key for every transaction, so every piece of money in your wallet is already on a different key. The exception is when using a bitcoin address, everything sent to the same bitcoin address is on the same key, which is a privacy risk if you're trying to be anonymous. The EC-DSA key size is very strong (sized for the future), we don't practically have to worry about a key getting broken, but if we did there's the advantage that someone expending the massive computing resources would only break one single transaction's worth of money, not someone's whole account. The details about how to backup your wallet files is in the Q&A dump and also it's explained in readme.txt and definitely belongs in the FAQ. Oh I see, you're trying to address byronm's concern on freedomainradio. I see what you mean about the password feature being useful to address that argument. Banks let anyone who has your name and account number drain your account, and you're not going to get it back from Nigeria. If someone installs a keylogger on your computer, they could just as easily get your bank password and transfer money out of your account. Once we password encrypt the wallet, we'll be able to make a clearer case that we're much more secure than banks. We use strong encryption, while banks still let anyone who has your account info draw money from your account. mmalmi@cc.hut.fi wrote: > Quoting Satoshi Nakamoto : > >> That would be great! I added you (dmp1ce) as a dev to the sourceforge >> project and gave you access to edit the web space and everything. > > Oh, that's not me but another guy who wanted to help. I've seen him on > the Freedomain Radio forum. My name is Martti Malmi and my Sourceforge > account is sirius-m. No problem! > > Thanks for your answered questions, I'll add them to the faq. Here's > what I've done so far: > > **** Bitcoin FAQ **** > > General Questions > > 1 What is bitcoin? > > Bitcoin is a peer-to-peer network based anonymous digital > currency. Peer-to-peer (P2P) means that there is no central > authority to issue new money or to keep track of the > transactions. Instead, those tasks are managed collectively by > the nodes of the network. Anonymity means that the real world > identity of the parties of a transaction can be kept hidden from > the public or even from the parties themselves. > > 2 How does bitcoin work? > > Bitcoin utilizes public/private key cryptography. When a coin is > transfered from user A to user B, A adds B's public key to the > coin and signs it with his own private key. Now B owns the coin > and can transfer it further. To prevent A from transfering the > already used coin to another user C, a public list of all the > previous transactions is collectively maintained by the network > of bitcoin nodes, and before each transaction the coin's > unusedness will be checked. > > For details, see chapter Advanced Questions. > > 3 What is bitcoin's value backed by? > > Bitcoin is valued for the things it can be exchanged to, just > like all the traditional paper currencies are. > > When the first user publicly announces that he will make a pizza > for anyone who gives him a hundred bitcoins, then he can use > bitcoins as payment to some extent - as much as people want pizza > and trust his announcement. A pizza-eating hairdresser who trusts > him as a friend might then announce that she starts accepting > bitcoins as payment for fancy haircuts, and the value of the > bitcoin would be higher - now you could buy pizzas and haircuts > with them. When bitcoins have become accepted widely enough, he > could retire from his pizza business and still be able to use his > bitcoin-savings. > > 4 How are new bitcoins created? > > New coins are generated by a network node each time it finds the > solution to a certain calculational problem. In the first 4 years > of the bitcoin network, amount X of coins will be created. The > amount is halved each 4 years, so it will be X/2 after 4 years, > X/4 after 8 years and so on. Thus the total number of coins will > approach 2X. > > 5 Is bitcoin safe? > > Yes, as long as you make backups of your coin keys, protect them > with strong passwords and keep keyloggers away from your > computer. If you lose your key or if some unknown attacker > manages to unlock it, there's no way to get your coins back. If > you have a large amount of coins, it is recommended to distribute > them under several keys. You propably wouldn't either keep all > your dollars or euros as paper in a single wallet and leave it > unguarded. > > 6 Why should I use bitcoin? > > • Transfer money easily through the internet, without having to > trust third parties. > > • Third parties can't prevent or control your transactions. > > • Be safe from the unfair monetary policies of the monopolistic > central banks and the other risks of centralized power over a > money supply. The limited inflation of the bitcoin system's > money supply is distributed evenly (by CPU power) throughout > the network, not monopolized to a banking elite. > > • Bitcoin's value is likely to increase as the growth of the > bitcoin economy exceeds the inflation rate - consider bitcoin > an investment and start running a node today! > > 7 Where can I get bitcoins? > > Find a bitcoin owner and sell her something - MMORPG equipement, > IT support, lawn mowing, dollars or whatever you can trade with > her. You can also generate new bitcoins for yourself by running a > bitcoin network node. > Martii Malmi (AKA Sirius) “COPA trial” email #8 Date: Tue, 05 May 2009 18:39:44 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: >> You can create whatever you want on bitcoin.sourceforge.net. Something >> to get new users up to speed on what Bitcoin is and how to use it and >> why, and clean and professional looking would help make it look well >> established. The site at bitcoin.org was designed in a more >> professorial style when I was presenting the design paper on the >> Cryptography list, but we're moving on from that phase. > > Ok. Could you set the project MySQL database passwords so that I can set > up a CMS on the site? I was thinking about WordPress, as it seems simple > and well maintained. I need a password for the read/write account and > one database (or the database admin pass to create it myself). This can > be done somewhere in the project admin pages, I think. They have Wordpress built in, you might not need to set up any database stuff manually. I enabled the Wordpress feature and added you as an admin, account sirius-m, e-mail sirius-m@users.sourceforge.net. I'm not sure how it works out the password for access, maybe it's just based on being logged in to sourceforge. https://apps.sourceforge.net/wordpress/bitcoin/wp-admin/ They also have support for MediaWiki if you want it. In case you still need it, here's the accounts and passwords for mysql. # Access this project's databases over the Internet https://apps.sourceforge.net/admin/Bitcoin # Documentation: Guide to MySQL Database Services http://p.sf.net/sourceforge/mysql # Hostname: mysql-b (exactly as shown, with no domain suffix) # Database name prefix: b244765_ -- i.e. "CREATE DATABASE b244765_myapp" as your ADMIN user. # RO user: b244765ro (SELECT) # RW user: b244765rw (SELECT, INSERT, DELETE, UPDATE) # ADMIN user: b244765admin (has RW account privileges, and CREATE, DROP, ALTER, INDEX, LOCK TABLES) # web-access URL: https://mysql-b.sourceforge.net/ passwords: b244765ro EaG3nHLL b244765rw sNKgyt4W b244765admin Mz589ZKf > ...the difference being, though, that not everyone can easily > transfer their regular bank money into an uncontrollable location. In > bitcoin anyone can do it. That's true. We shouldn't try to use security against identity theft as a selling point, since it leads into these counter arguments. The current banking model is already tested and the actual loss percentage is known. Even if ours is probably better, it's an unknown, so people can imagine anything. The uncertainty about what the average loss percentage will be is greater than the likely loss percentage itself. Martii Malmi (AKA Sirius) “COPA trial” email #11 Date: Thu, 07 May 2009 03:35:50 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi It's already an improvement, and like you say, there must be better themes to choose from. It would be good to make the download link go directly to the download area: https://sourceforge.net/project/showfiles.php?group_id=244765 I haven't found any way to gain admin control over the mediawiki feature. It thinks I'm a different S_nakamoto from the one that has admin access: User list * S nakamoto <- it thinks I'm this one * S nakamoto ‎(admin, editor) * Sirius-m I tried deleting and re-enabling the feature, no help. Oh well. mmalmi@cc.hut.fi wrote: > Quoting Satoshi Nakamoto : > >> They have Wordpress built in, you might not need to set up any database >> stuff manually. >> >> They also have support for MediaWiki if you want it. > > The built-in Wordpress comes with ads, and new plugins and themes need > to be installed by the Sourceforge staff, so I installed Wordpress at > http://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/, > with admin/Wubreches3eS as login. If there's something to add or change, > feel free to. > > The current layout is just a quickly applied free theme, but I'll see if > I can do something more visual myself. > > The MediaWiki might be quite useful for maintaining the FAQ, which could > be retrieved from there to the main site somehow. The wiki says I need > to be an editor or admin to create a new page, which is funny, because > https://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights > says that users can create pages. Martii Malmi (AKA Sirius) “COPA trial” email #15 Date: Sun, 24 May 2009 23:03:38 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi You're right, that was it. I went in and granted us access using the alternate account. I like your idea of at least moving the FAQ into the wiki. I've seen other projects that use the wiki for the FAQ or even the whole site. If you can figure out how to make it so regular users can edit things, then anyone who wants to can help. mmalmi@cc.hut.fi wrote: > Quoting mmalmi@cc.hut.fi: > >> Quoting mmalmi@cc.hut.fi: >> >>> Quoting Satoshi Nakamoto : >>> >>>> I haven't found any way to gain admin control over the mediawiki >>>> feature. It thinks I'm a different S_nakamoto from the one that has >>>> admin access: >>>> User list >>>> * S nakamoto <- it thinks I'm this one >>>> * S nakamoto ‎(admin, editor) >>>> * Sirius-m >>>> >>>> I tried deleting and re-enabling the feature, no help. Oh well. >>> >>> I think this has something to do with the underscore character in your >>> username; MediaWiki handles them as spaces. I could ask SF Support >>> about this. >> >> Or could you control the MediaWiki with your account nakamoto2? > > Oh, sorry for spamming with emails, but the problem is indeed with the > underscore character: > http://apps.sourceforge.net/trac/sourceforge/ticket/300 > Martii Malmi (AKA Sirius) “COPA trial” email #19 Date: Thu, 11 Jun 2009 22:24:25 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi The site layout is looking nicer. More impressive looking. There are a lot of things you can say on the sourceforge site that I can't say on my own site. Even so, I'm uncomfortable with explicitly saying "consider it an investment". That's a dangerous thing to say and you should delete that bullet point. It's OK if they come to that conclusion on their own, but we can't pitch it as that. A few details: the FAQ says "see section 2.3", but the sections aren't numbered. Also, could you delete the last sentence on the FAQ "They are planned to be hidden in v0.1.6, since they're just confusing and annoying and there's no reason for users to have to see them." -- that's not really something I meant to say publicly. The links to sites to help set up 8333 port forwarding is great. favicon is a nice touch. Someone came up with the word "cryptocurrency"... maybe it's a word we should use when describing Bitcoin, do you like it? Sourceforge is so slow right now I can't even get the login page to load. Maybe due to the site reorg they just did. I'll keep trying and try to get you that logo stats thing. mmalmi@cc.hut.fi wrote: > Now that the project web is up and running, do you think that setting up > a custom VHOST for the bitcoin.org domain would be a good idea? > Instructions: > http://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs > > Also, could you please send me a link to a SF Logo for statistics, as > instructed at: > http://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking > Martii Malmi (AKA Sirius) “COPA trial” email #21 Date: Sun, 14 Jun 2009 21:30:58 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > I made the changes. You could also register to the site or use the admin > account to make necessary changes yourself, since the pages are located > in the wiki. Thanks, I've been really busy lately. I registered username "satoshi". Since there's no SSL login, I want to mainly use that account with sub-admin powers and use the admin account as little as possible. I created a "Moderators" group to give my satoshi account as much editing control as possible without the ability to overthrow everything. There's something weird with the download bar on the right covering things up, like on the new account registration it covers up the entry fields unless you make the browser really wide, and the homepage it covers up the screenshots. (with Firefox) Martii Malmi (AKA Sirius) “COPA trial” email #24 Date: Tue, 21 Jul 2009 04:14:43 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi I know this sounds really retarded, but I still haven't been able to get the sourceforge login page to load, so I haven't been able to read it either. https://sourceforge.net/account/login.php Hal isn't currently actively involved. He helped me a lot defending the design on the Cryptography list, and with initial testing when it was first released. He carried this torch years ago with his Reusable Proof Of Work (RPOW). I'm not going to be much help right now either, pretty busy with work, and need a break from it after 18 months development. It would help if there was something for people to use it for. We need an application to bootstrap it. Any ideas? There are donors I can tap if we come up with something that needs funding, but they want to be anonymous, which makes it hard to actually do anything with it. mmalmi@cc.hut.fi wrote: > Hi, > > I made a post on the Bitcoin developer's forum at SF about a month ago > and sent you, David and Hal a notification about it to your > users.sourceforge.net emails. A few days ago I wondered why no one had > replied, and tried if the SF mail aliases even work - and they didn't, > at least in the case of my account. So could you please forward this > message to the others? > > Best regards, > sirius-m > Martii Malmi (AKA Sirius) “COPA trial” email #28 Date: Mon, 24 Aug 2009 23:00:35 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi That's a good point that since you know how many coins exist and how fast new ones are created, you could set a support price based on the amount of legacy currency you have and be sure you'll have enough to meet all demands. I had imagined an auction, but it would be far simpler and more confidence inspiring to back it at a specific exchange rate. Offering currency to back bitcoins would attract freebie seekers, with the benefit of attracting a lot of publicity. At first it would mostly be seen as a way to get free money for your computer's idle time. Maybe pitched like help support the future of e-commerce and get a little money for your computer's spare cycles. As people cash in and actually get paid, word would spread exponentially. It might help to keep the minimum transaction size above an amount which a typical user would be able to accumulate with one computer, so that users have to trade with each other for someone to collect enough to cash in. Aggregators would set up shop to buy bitcoins in smaller increments, which would add confidence in users ability to sell bitcoins if there are more available buyers than just you. People would obviously be sceptical at first that the backing will hold up against an onslaught of people trying to get the free money, but as the competition raises the proof-of-work difficulty, it should become clear that bitcoins stay scarce. People will see that they can't just get all the bitcoins they want. It would establish a minimum value under bitcoins enabling them to be used for other purposes if, hopefully, other purposes are waiting for something to use. >> It would help if there was something for people to use it for. We need >> an application to bootstrap it. Any ideas? > > I've been thinking about a currency exchange service that sells and > buys bitcoins for euros and other currencies. Direct exchangeability > to an existing currency would give bitcoin the best possible initial > liquidity and thus the best adoptability for new users. Everyone > accepts payment in coins that are easily exchangeable for common > money, but not everyone accepts payment in coins that are only > guaranteed to buy a specific kind of a product. That would be more powerful if there was also some narrow product market to use it for. Some virtual currencies like Tencent's Q coin have made headway with virtual goods. It would be sweet if there was some way to horn in on a market like that as the official virtual currency gets clamped down on with limitations. Not saying it can't work without something, but a ready specific transaction need that it fills would increase the certainty of success. > At its simplest this exchange service could be a website where > traders, who can be individual persons, can post their rates, and > random users can leave trade requests. Some kind of an average rate > estimate could be shown on the site. Small-scale trading by > individuals would be outside legal hassle in most countries, and > putting all the eggs in the same basket would be avoided. Basically like an eBay site with user reviews to try to establish which sellers can be trusted. The escrow feature will help but not solve everything. It would be far more work to set up such a site than just to set up a single exchange site of your own, and there won't be enough users to make it go until later. I'm thinking it wouldn't make sense to make an eBay type site until later. > Another idea, which could be additional to the previous one, would be > an automated exchange service. The service would automatically > calculate the exchange rate and perform the transactions. This would > be nicer to the user: completion of the transaction request would be > certain and instantaneous. Making this service might actually be quite > easy if there was a command line interface to Bitcoin: just take any > web application framework and use PayPal back-end integration to > automatically send euros when Bitcoins are received, and vice versa. > This kind of business would also work great on larger scale if you set > up a company and take care of all the bureaucracy needed to practice > currency exchange. (I actually have a registered company that I've > used for billing of some IT work, I could use that as a base.) Even if you had automation, you'd probably want to review orders manually before processing them anyway. It wouldn't be hard to process orders by hand, especially at first. You could always set a minimum order size to keep orders more infrequent. > This exchange business thing is something that I'd be interested in > doing, and I also have the sufficient technical skills to do it. > Although, before this can be done, there should be a non-alpha version > of Bitcoin (and the command line interface / API). > > If this gets started, donors / high-risk investors would be very > welcome to bring capital for the currency's backup. > > So, what do you think about the idea? Note that this is not something > that I'm asking you to do (unless you want to) if you're busy with > other things. I can do it myself, if I get positive reviews about the > plan. That's great, I could probably get a donor to send currency to you which you convert to euros and pay out through methods that are convenient for users. I don't want to do an exchange business myself, but it can be done independently of me. Like you say, there is more software development to be done first, and also I'd like to keep trying for a while to think of a bootstrap application to use bitcoins for. I've had some ideas that could only be done before an exchange exists. BTW, I tried to buy bitcoin.com before I started but there was no chance, it's owned by a professional domain speculator. It's normal for open source projects to have .org so it's not so bad. Martii Malmi (AKA Sirius) “COPA trial” email #29 Date: Mon, 24 Aug 2009 23:04:25 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi Glad that worked, it's a pain that the dependencies are so big and hard to build. Some of them give little attention to the Windows build. Next time I update to the latest versions, maybe I'll lay everything out in one directory tree and bundle the whole thing up into a giant archive. I'm not sure they had wxPack before. I'm glad they got that so everyone doesn't have to build wxWidgets themselves. OpenSSL is the harder one to build. I reduced the EXE size by running strip.exe on it to take out the debug symbols. That's with mingw. That's the better compiler, I only used VC for debugging. mmalmi@cc.hut.fi wrote: > I got it compile with MinGW + MSYS when I used wxPack instead of just > wxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize was > 52MB though, I should see how that can be fixed. > > Next I'm going to implement the "minimize to tray" feature and the > option to autostart Bitcoin with Windows, so the number of nodes online > would stay higher. After that I could see if I can do a Linux port or > the command line interface needed for web app frameworks. > > Drop by at #bitcoin-dev on FreeNode some time if you use IRC. > > And again, thanks for the great work you've done with Bitcoin. > > Quote mmalmi@cc.hut.fi: > >> I've had quite a few errors coming up when trying to build the >> third-party libraries and adding them to the Bitcoin build. Do you >> happen to have a ready-to-build package that you could upload to the >> CVS or somewhere else? I use mingw + msys, but I guess I could try >> Visual C++ also, if it's easier that way. > Martii Malmi (AKA Sirius) “COPA trial” email #31 Date: Sat, 29 Aug 2009 18:31:05 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi > Next I'm going to implement the "minimize to tray" feature and the > option to autostart Bitcoin with Windows, so the number of nodes online > would stay higher. Now that I think about it, you've put your finger on the most important missing feature right now that would make an order of magnitude difference in the number of nodes. Without auto-run, we'll almost never retain nodes after an initial tryout interest. Auto-running as a minimized tray icon by default was the key to success for the early file sharing networks. It wouldn't have been appropriate for v0.1.0 when stability wasn't a given yet, but now it's good and stable. This is a must-have feature for the next release so any users that come back to try the new version we hopefully retain this time. I think the most user friendly way of doing auto-run is putting an icon in the Startup folder. I see OpenOffice.org and a number of other things on my computer do it that way. The other way, creating a runas registry entry, is not easily visible or editable by users, I've never liked that much. I guess what we want is an auto-run option that's on by default, if the option is changed then it creates or deletes the startup icon. While it's tempting to do a Linux port, once we do it we have that extra work with every release from then on. I'd rather put it off a while longer. Auto-run might give us 300% more nodes while Linux might give us 3% more. Linux would help server farms, but actually we'd like to favour individual users. Someone reported that it works fine in WinE. Martii Malmi (AKA Sirius) “COPA trial” email #33 Date: Wed, 30 Sep 2009 19:12:29 +0100 From: Satoshi Nakamoto Subject: Re: Bitcoin To: mmalmi@cc.hut.fi That's great, that's a good step forward. Yes, I worked out the sourceforge login problem, it was some tricky thing on the login page that exposed a quirky bug in a browser add-in. mmalmi@cc.hut.fi wrote: > Just for information: I committed my working copy to the svn/branches. > There's the minimize to tray feature and some other changes. It's nicer > to run in the background now, but it's still incomplete and I'm working > on it. The bugs are listed in bugs.txt. > > Did you get your Sourceforge account work yet? > Martii Malmi (AKA Sirius) “COPA trial” email #35 Date: Fri, 16 Oct 2009 19:41:40 +0100 From: Satoshi Nakamoto Subject: Re: Setup, Autorun, v0.1.6 To: mmalmi@cc.hut.fi Thanks for that. I'm still merging in some changes I had that need to go in before any next release. Some things based on questions and feedback I've received that'll reduce confusion. I'll probably enable multi-proc generating support, and hopefully make it safe to just backup wallet.dat to backup your money. It's good to be coding again! I'm going to hide the transaction fee setting, which is completely not needed and only serves to confuse people. It was only there for testing and demonstration of a technical detail that can only be needed in the far away future, if ever, but was necessary to implement at the beginning to make it possible later. What was the problem with the shortcut in the startup folder? If you could send me the code, I'd like to take another look and see if I can see what the problem was. The first strcat in the registry code should be strcpy, otherwise it would fail intermittently. If the same code was in the shortcut one, maybe that was the problem. It's encouraging to see more people taking an interest such as that NewLibertyStandard site. I like his approach to estimating the value based on electricity. It's educational to see what explanations people adopt. They may help discover a simplified way of understanding it that makes it more accessible to the masses. Many complex concepts in the world have a simplistic explanation that satisfies 80% of people, and a complete explanation that satisfies the other 20% who see the flaws in the simplistic explanation. mmalmi@cc.hut.fi wrote: > I made a Windows installer for the latest version of Bitcoin, which > includes the autostart and minimize to tray features. The installer > makes a start menu shortcut and a startup registry entry. I first > implemented the autostart with a shortcut to the startup folder, but I > found out that it doesn't always work by default and ended up doing it > with a registry entry. The registry entry is removed by the uninstaller > and can be also disabled from the options menu, so I don't think it's > such a big menace to the user after all. > > I made the installer with NSIS, and the nsi script can be found in the SVN. > > Could you add the installer to the SF download page? Here's the file: > http://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe > > There are some new users registered to the bitcoin.sf.net site. One of > them just announced that he's trading Bitcoins for dollars. Here's his > site: http://newlibertystandard.wetpaint.com/. Making an exchange > service first seemed a bit premature for the time being, but on the > other hand it's good that people show interest towards the project, and > this might attract even more interested people (and hopefully more > developers). I just sent the guy an email. > Martii Malmi (AKA Sirius) “COPA trial” email #36 Date: Sun, 18 Oct 2009 18:59:42 +0100 From: Satoshi Nakamoto Subject: Re: Setup, Autorun, v0.1.6 To: Martti Malmi I got it, I see you checked in the startup folder code before changing it to registry. I don't see any visible problems in the code. I guess it depends what exactly the problem was with it not always working by default. Was there a Vista/UAC security problem? Martii Malmi (AKA Sirius) “COPA trial” email #38 Date: Mon, 19 Oct 2009 00:11:50 +0100 From: Satoshi Nakamoto Subject: Re: Setup, Autorun, v0.1.6 To: mmalmi@cc.hut.fi It's possible Bitcoin ran and bailed out because something was wrong. debug.log should tell something if that was the case. What OS are you using? I wonder if we need Admin privilege and don't realize it. Stuff that requires Admin can't start on startup on Vista. Program shortcuts have multiple tabs of settings with lots of little details. I'll try the startup folder code and see if I can reproduce the problem. Every other systray icon on my computer is in the startup folder, and it makes it easy for users to manage all their autoruns in one place. The things in the registry key tend to be devious hidden bloatware. I implemented the code to flush wallet.dat whenever it's closed so we'll be able to tell users they only need to backup wallet.dat. You can restore just wallet.dat and it'll re-download the rest. I'll have to do another stress test before release. mmalmi@cc.hut.fi wrote: > Well, the code worked and made a shortcut in the startup folder. For > some reason it didn't automatically start when booting, but worked fine > when you clicked on it in the menu. Now I tried making a shortcut > manually, and this time it works on autostart, don't know why. I could > try again with the older code. > >> I got it, I see you checked in the startup folder code before changing >> it to registry. I don't see any visible problems in the code. I guess >> it depends what exactly the problem was with it not always working by >> default. Was there a Vista/UAC security problem? >> Martii Malmi (AKA Sirius) “COPA trial” email #40 Date: Wed, 21 Oct 2009 18:58:49 +0100 From: Satoshi Nakamoto Subject: Re: Setup, Autorun, v0.1.6 To: mmalmi@cc.hut.fi Yeah, I put back your startup folder shortcut code and it started fine for me too on XP and Vista. For good measure, I changed it to make the shortcut settings look identical to one I manually created. I set the working directory to where the EXE is since that's where debug.log is created, otherwise windows puts it in some weird directory. I didn't change the setup script yet. I checked everything in to SVN (thanks for setting that up) - multi-proc generate - flush wallet.dat after every change so the DB doesn't leave that stuff in the transaction logs - view menu checkbox to hide all generated coins so you can see just your payment transactions - disabled transaction fee option - made the minimize to tray options similar to Firefox's MinimizeToTray - bunch of other misc changes since the 0.1.5 release I made it not show non-accepted generated coins. It won't show generated coins until they have at least one confirmation (one block linked after it), so usually they'll just never be seen. Occasionally a generated coin that was displayed might disappear because it became not accepted later. I don't think anyone would notice the occasional non-accepteds if we didn't point them out in the UI. People have told me they find it annoying to have to look at them, as they're permanently displayed in the transaction record. I still have more testing to do. I guess we gotta test Windows 7 now. mmalmi@cc.hut.fi wrote: >> It's possible Bitcoin ran and bailed out because something was wrong. >> debug.log should tell something if that was the case. What OS are you >> using? I wonder if we need Admin privilege and don't realize it. >> Stuff that requires Admin can't start on startup on Vista. > > I'm using XP. I recompiled the older revision and this time the startup > shortcut works. It also works when testing on Vista (non-admin). Maybe I > just missed something the previous time. > >> Program shortcuts have multiple tabs of settings with lots of little >> details. I'll try the startup folder code and see if I can reproduce >> the problem. Every other systray icon on my computer is in the startup >> folder, and it makes it easy for users to manage all their autoruns in >> one place. The things in the registry key tend to be devious hidden >> bloatware. > > Here it's the other way around, I have all my startup programs in the > registry. But maybe the shortcut method is nicer for the user, if it > works just as well > Martii Malmi (AKA Sirius) “COPA trial” email #41 Date: Sat, 24 Oct 2009 00:55:06 +0100 From: Satoshi Nakamoto Subject: Re: [bitcoin-list] Does Bitcoin Crash in Windows? To: Liberty Standard Cc: bitcoin-list@lists.sourceforge.net Liberty Standard wrote: > Do you Windows users experience occasional Bitcoin crashes? > Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was > just wondering whether this is a Wine issue or a Bitcoin issue. I haven't had any reports of crashes in v0.1.5. It's been rock solid for me on Windows. I think it must be Wine related. If you get another crash in Wine and it prints anything on the terminal, e-mail me and I may be able to figure out what happened, maybe something I can work around. Martti and I have been working on a new version to release soon and it would be nice to get any Wine fixes in there. > The following four lines print from the terminal when I start Bitcoin. > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub > fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot > fixme:toolhelp:Heap32ListFirst : stub Those don't look like anything to worry about. Probably functions unimplemented by Wine that are harmlessly stubbed out. > I previously wasn't starting Bitcoin from the terminal, so I don't know what > gets printed out when it crashes, but I'll reply with the results the next > time it crashes. > > While Bitcoin first downloads previously completed blocks, the file > debug.log grows grows to 17.4 MB and then stops growing. I imagine it will > continue to grow as more bitcoins are completed. You can delete debug.log occasionally if you don't want to take the disk space. It's just status messages that help with debugging. bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing some maintenance. Satoshi Martii Malmi (AKA Sirius) “COPA trial” email #42 Date: Mon, 26 Oct 2009 17:50:10 +0000 From: Satoshi Nakamoto Subject: Fw: bitcoin.sourceforge.net To: Martti Malmi Any idea what's going on with it? Every time I look, it's fine. Eugen Leitl wrote: On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote: > > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing Doesn't work right now. > > some maintenance. Liberty Standard wrote: > In case you weren't aware, the Bitcoin website is down. > > http://bitcoin.sourceforge.net/ > Martii Malmi (AKA Sirius) “COPA trial” email #44 Date: Tue, 27 Oct 2009 04:45:47 +0000 From: Satoshi Nakamoto Subject: Re: Fw: bitcoin.sourceforge.net To: mmalmi@cc.hut.fi Sourceforge is just so darn slow. I don't know what else to do though. It's such a standard, more often than not any given project has a projectname.sourceforge.net site. When I see whatever.sourceforge.net in a google search, I assume that's the official site. Is there a way to make Bitweaver allow users to edit (and maybe delete) their own messages in the forum? Getting antsy to port to Linux? It's not a decision to be taken lightly because once it's done, it doubles my testing and building workload. Although I am worried about Liberty's Wine crashes. I've tried to be as portable as possible and use standard C stuff instead of Windows calls. The threading is _beginthread which is part of the standard C library. wxWidgets has wxCriticalSection stuff we can use. The sockets code is send/recv stuff which I think is the same as unix because Microsoft ported sockets from BSD. We need direct control over sockets, it wouldn't be a good idea to get behind an abstraction layer. wxWidgets is a good place to look for cross-platform support functions. I want to avoid #ifdefing up the code if we can. Anything that's used more than once probably becomes a function in util.cpp that has the #ifdef in it. BTW, I have a lot of uncommitted changes right now because it includes some crucial protocol transitions that can't be unleashed on the network until I've tested the heck out of it. It shouldn't be too much longer. Can you make the setup uninstall the Startup folder icon? I figure it should install and uninstall an icon in a regular program group, and just uninstall the Startup folder one. I guess it doesn't matter that much whether it installs and uninstalls the Startup folder icon or just uninstalls it. Martii Malmi (AKA Sirius) “COPA trial” email #46 Date: Thu, 29 Oct 2009 02:05:30 +0000 From: Satoshi Nakamoto Subject: Re: Fw: bitcoin.sourceforge.net To: mmalmi@cc.hut.fi I'll convert the CriticalSection code to wxCriticalSection and upload it to SVN (it's a little tricky). I don't know what to do for TryEnterCriticalSection though. I think I'm almost ready to check everything in. You're probably right, it's about time to do a linux build. I've been working on getting my linux machine set up and building the dependencies. > Ok. I replaced the Windows thread and socket library includes with their > POSIX equivalents, and now it only gives a few errors, mostly from the > CriticalSections. If I make it work, I'll put it into svn/branches, it > doesn't need to be an official release yet. Martii Malmi (AKA Sirius) “COPA trial” email #48 Date: Thu, 29 Oct 2009 06:38:30 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: mmalmi@cc.hut.fi The easy solution I took was to look at the wxWidgets source code and see how they did it. They just mapped it to wxMutex on non-MSW, which does have TryEnter, so that mapped in perfectly. I checked in all my backlog of changes to SVN, including the overhaul of CCriticalSection in util.h and OpenSSL's mutex callback in util.cpp to do everything with wxWidgets when not on Windows. If we get it working on Linux, I'll run my test suite against it here off-network first, then we can give an unreleased build to LibertyStandard to test for a while before going public. Martii Malmi (AKA Sirius) “COPA trial” email #49 Date: Fri, 30 Oct 2009 01:05:45 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: Martti Malmi I fixed some non-portable stuff I came across: QueryPerformanceCounter %I64d in printf format strings Sleep CheckDiskSpace If there's any other unportable stuff you know of I should fix, let me know. I think I'll move debug.log and db.log into the same directory as the data files (%appdata%\Bitcoin), rather than whatever the current directory happens to be. Martii Malmi (AKA Sirius) “COPA trial” email #51 Date: Sat, 31 Oct 2009 20:09:58 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: mmalmi@cc.hut.fi heapchk() is just a MSVCRT debugging thing that's not being used. It can be a no-op on Linux. OpenSSL automatically uses /dev/urandom to seed on Linux, so RandAddSeedPerfmon can also be a no-op. Don't let it connect to the network before we've tested it thoroughly off-net. If you have two computers, unplug the internet and use "bitcoin -connect=" to connect to each other, one windows and one linux. -connect will allow you to connect to non-routable addresses like 192.168.x.x. We don't want to reflect badly on the reliability of the network if it throws off some malformed crud we hadn't thought to check for yet, or discovers something else anti-social to do on the network. I have time that I can do some testing when you've got something buildable to test. I can include it in the stress test I'm currently running on the changes so far. mmalmi@cc.hut.fi wrote: > I made an #ifdef to replace QueryPerformanceCounter with Linux's > gettimeofday in util.h. Some Unicode/ANSI errors were resolved without > code changes when I updated to wxWidgets 2.9. The only compile error I'm > getting in Linux at the moment is from heapchk() in util.h. > >> I fixed some non-portable stuff I came across: >> QueryPerformanceCounter >> %I64d in printf format strings >> Sleep >> CheckDiskSpace >> >> If there's any other unportable stuff you know of I should fix, let me >> know. >> >> I think I'll move debug.log and db.log into the same directory as the >> data files (%appdata%\Bitcoin), rather than whatever the current >> directory happens to be. > Martii Malmi (AKA Sirius) “COPA trial” email #53 Date: Tue, 03 Nov 2009 15:53:25 +0000 From: Satoshi Nakamoto Subject: Re: Linux build, proxy To: mmalmi@cc.hut.fi Great, I've been looking forward to working on the Linux build. If you connect to Freenode's hidden service, then they tell you they've also banned TOR from that due to abuse and it kicks you off. There's a several step procedure you can do to run a password utility on unix and e-mail request an account that you could login with, but that's getting pretty complicated. I wonder if we could get away with applying for one account and then everyone use the same account? I suppose the IRC server probably limits accounts to one login, or some admin might not like to see a dozen logins on the same account. Besides the IRC part, how did your test of proxy go? Since you've been connected before, your addr.dat contains known node addresses, but without IRC to know which ones are online, it takes a long time to find them. There are normally 1 to 3 other nodes besides you that can accept incoming connections, and existing nodes that already know you would eventually connect to you. How many connections did you get, and how long did it take? I guess to know whether it successfully connected outbound through TOR you'd need to search debug.log for "connected". To originally connect with TOR without connecting normally once to get seeded, you'd have to know the address of an existing node that can accept incoming connections and seed it like this: bitcoin -proxy=127.0.0.1:9050 -addnode= If some nodes that accept incoming connects were willing to have their IP coded into the program, it could seed automatically. Or some IP seed addresses posted on a Wiki page with the instructions. Another option is to search the world again for an IRC server that doesn't ban TOR nodes. Or if we could get someone to set one up. IRC servers ban TOR because they have actual text chat on them... if there was one with just bots and junk then it wouldn't care. Probably should post a question on the forum or the mailing list and see if anyone knows one. Another problem is that TOR users can't accept incoming connections, and we have so few that can. If everyone goes to TOR, there won't be any nodes to connect to. We have a shortage of nodes that can accept incoming connections. It generally ranges from 2 to 4 lately. We need to emphasize the importance to people of setting up port forwarding on their router. Every P2P file sharing program has instructions how to do it. We should have a paragraph on the bitcoin.sourceforge.net homepage urging people to set up port forwarding to accept incoming connections, and a link to a site that describes how to do it for each router. mmalmi@cc.hut.fi wrote: > I uploaded what I've ported so far to the svn/branches. Util, script, db > and the headers compile fully now and net.cpp partially, so there's > still work to do. > > _beginthread doesn't have a direct Linux equivalent, so I used Boost > threads instead. > > I couldn't get connected using the Tor SOCKS proxy. That might be > because of the Freenode Tor policy which requires connecting to their > hidden service: http://freenode.net/irc_servers.shtml#tor > Martii Malmi (AKA Sirius) “COPA trial” email #54 Date: Wed, 04 Nov 2009 05:38:17 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: mmalmi@cc.hut.fi It was almost there. I fixed a few things and got it to finish compiling but I don't know the system libraries to link to so there's undefined references galore. I changed the makefile to look for things under /usr/local and in their default "make install" locations. I wrote what I did and switches I used in build-unix.txt. I'm currently using wxWidgets 2.8.9 for now because it's the same version as on Windows and I don't want to wonder if there's version change issues at the same time as platform change. 2.8.10 or 2.9.0 are probably fine though. I went with the single-library compile of wxWidgets since we're linking to almost every library anyway. I added xpm files, which is what they use everywhere else but Windows instead of RC files. They're clever C files that define graphics in static arrays. The bitcoin icon has 5 different versions but I couldn't figure out how that works in xpm so I only put the biggest one. Maybe on GTK it scales it for you. I don't know if these are right or what, but they compile. mmalmi@cc.hut.fi wrote: > I uploaded what I've ported so far to the svn/branches. Util, script, db > and the headers compile fully now and net.cpp partially, so there's > still work to do. > > _beginthread doesn't have a direct Linux equivalent, so I used Boost > threads instead. > Martii Malmi (AKA Sirius) “COPA trial” email #55 Date: Wed, 04 Nov 2009 20:38:03 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: mmalmi@cc.hut.fi Just letting you know I'm still working on the Linux build so we don't duplicate work. I got it linked and ran it and working through runtime issues like getting it switched to load bitmaps from xpm instead of resources. There are debian packages available for some of the dependencies instead of having to compile them ourselves: apt-get install build-essential apt-get install libgtk2.0-dev apt-get install libssl-dev I need to see if Berkeley DB or Boost have packages. We'll shared-link OpenSSL, I'm pretty sure it's always preinstalled on Linux. GTK has to be shared linked. I'm not completely sure if it's preinstalled by default. Martii Malmi (AKA Sirius) “COPA trial” email #57 Date: Thu, 05 Nov 2009 05:31:03 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: Martti Malmi I merged the linux changes into the main trunk on SVN. It compiles and runs now. I think all the problems are in the UI. The menus quickly quit working and it doesn't repaint when it's supposed to unless I resize it, and the UI is getting some segfaults. Shouldn't be too hard to debug with gdb. I haven't tested if it plays nice with other nodes yet so keep it off-net. build-unix.txt and makefile.unix added Martii Malmi (AKA Sirius) “COPA trial” email #58 Date: Thu, 05 Nov 2009 15:25:27 +0000 From: Satoshi Nakamoto Subject: Re: Proxy To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > Enabling the proxy setting and restarting Bitcoin I got the first > connections in less than a minute and ultimately even 8 connections. I > wonder if they're all really through TOR. Netstat shows only 2 > connections to localhost:9050 and 7 connections from local port 8333 to > elsewhere. (Some of the shown connections may be already disconnected > ones.) For some reason there's no debug.log in the folder where I'm > running it. debug.log moved to the data directory "%appdata%/bitcoin/debug.log" 7 inbound and 2 outbound sounds about as expected. My last SVN commit included an overhaul of the code that selects the order of addresses to connect to, trying them in the order of most recently seen online, so it should get connected in a more reasonable amount of time if IRC is unavailable. IRC is really only needed to seed the first connection, but we've been using it as a crutch to get connected faster. >> If some nodes that accept incoming connects were willing to have their >> IP coded into the program, it could seed automatically. Or some IP >> seed addresses posted on a Wiki page with the instructions. > > The wiki page sounds like a good and quickly applicable solution. I > could keep my ip updated there and we could ask others to do the same. > When the Linux build works, it's easier to set up nodes on servers that > are online most of the time and have a static IP. A static ip list > shipped with Bitcoin and a peer exchange protocol would be cool. That > way there'd be no need for an IRC server. That would be great. It's only TOR users that need it, so in the instructions saying "bitcoin -proxy=127.0.0.1:9050 -addnode=", someip could be an actual static IP, with the wiki free-for-all add-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 if you're static. Do you think anonymous people are looking to be completely stealth, as in never connect once without TOR so nobody knows they use bitcoin, or just want to switch to TOR before doing any transactions? It's just if you want to be completely stealth that you'd have to go through the -proxy -addnode manual seeding. It would be very easy to fumble that up; if you run bitcoin normally to begin with it immediately automatically starts connecting. Martii Malmi (AKA Sirius) “COPA trial” email #59 Date: Thu, 05 Nov 2009 17:33:58 +0000 From: Satoshi Nakamoto Subject: Forum To: Martti Malmi Now that the forum on bitcoin.sourceforge.net is catching on, we really should look for somewhere that freehosts full blown forum software. The bitweaver forum feature is just too lightweight. I assume the "Forum" tab on the homepage can link out to wherever the forum is hosted. I've seen projects that have major following just from forum talk and pie-in-the-sky planning without even having any code yet. Having a lot of forum talk gives a project more presence on the net, more search hits, makes it look big, draws new users in, helps solve support questions, hashes out what features are most of wanted. It would be a big plus if it could support SSL, at least for the login page if not sitewide. Multiple people on the forum have expressed interest in TOR/I2P, and those users need SSL because a lot of TOR exit nodes are probably password scrapers run by identity thieves. A lot of the core interest in Bitcoin is going to be from the privacy crowd. Any ideas where we can get a free forum? Maybe we should look at where some other projects have their forums hosted for ideas where to look. Martii Malmi (AKA Sirius) “COPA trial” email #60 Date: Fri, 06 Nov 2009 06:20:15 +0000 From: Satoshi Nakamoto Subject: Re: Linux build To: Martti Malmi It works reliably on Linux now, except if it uses wxMessageBox() outside the GUI thread, it'll crash because non-GUI threads can't open a window on Linux. I haven't got to fixing that yet. I've been running my stress test on it and it's functioning normally. Most of wxWidgets is not thread-safe to use in threads other than the UI thread, but as a rule of thumb on Windows anything not UI related is OK. It turns out its more thread-unsafe on GTK. I replaced a bunch of stuff at once so I don't know if it was just one thing (probably Repaint), but I have to assume even any wx function that uses wxString is not safe to use outside the UI thread. So dang, there goes all the nice wxWidgets portability support functions. I left a few simple things like wxThread::GetCPUCount() that I checked the source and it's all numerical, and wxMutex has to be safe or it'd be useless. There's an issue that if you exit and run it again right away, it can't bind port 8333. The port frees up after about a minute. Unless I'm missing something, I am closing the socket before exit, so I don't know what else I can do. Maybe this is just something about Linux that it takes a minute to free up a port you had bound. Possibly a security feature so some trojan doesn't kill the web server and quickly jump into its place and pick up all the client retries. Still gotta figure out how to do the xpm version of the icon correctly. I wonder if the database dat files are interchangeable with Windows. Martii Malmi (AKA Sirius) “COPA trial” email #62 Date: Sun, 08 Nov 2009 05:23:13 +0000 From: Satoshi Nakamoto Subject: Linux build ready for testing (attached) To: Martti Malmi , Liberty Standard bitcoin-linux-0.1.6-test1.tar.bz2 attached Martii Malmi (AKA Sirius) “COPA trial” email #63 Date: Sun, 08 Nov 2009 05:52:11 +0000 From: Satoshi Nakamoto Subject: Linux build ready for testing To: Martti Malmi , Liberty Standard The Linux build is ready for testing on the network. It seems solid. I sent the executable as an attachment in the previous e-mail, but if the mail server didn't let it through (it's 12MB), you can download it here: http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html Martii Malmi (AKA Sirius) “COPA trial” email #66 Date: Sun, 08 Nov 2009 17:39:39 +0000 From: Satoshi Nakamoto Subject: Re: Linux build ready for testing To: Liberty Standard Cc: Martti Malmi In the debug.log, it requests the block list, receives the block list, then begins uploading the list of blocks requested. It doesn't receive the blocks, but it didn't run long enough for me to be sure it would have had time yet. Everything else looks normal. How long did you run it? It could take a few minutes to start downloading the blocks. Especially if you're on a cable modem, the uplink can be much lower bandwidth so it would take some time to upload the block request list. If you run it again and it still doesn't download blocks, keep it running for several hours at least and then send me the debug.log. That should give it time for my node to connect to you and I could see what it says on my side and correlate it with your debug.log. You're right about the minimize on close option, there's no reason that can't be separate. Martti originally had it separate and I made it a sub-option, my bad. I'll change it back. Liberty Standard wrote: > That is what I meant. The blocks displayed in the status bar did not > increase at all while i ran the program. I have attached my debug.log. > > A good way for you to test the tray icon in Gnome is to remove the > notification area and then add it back. If the icon is still displayed > after adding the notification back, then it's working correctly. > > I generally set application preferences to not minimize to the tray, but > to close to the tray. And I keep the application minimized. That way I > don't accidentally close the program and still have the convenience of > being able to open the application from the tray. (I don't display open > windows in the 'task bar' but I have an icon that if clicked displays > open windows as sub-menu items.) Then if the tray icon disappears, I go > into the settings disable and re-enable the tray icon setting to get it > to reappear. That's currently not possible with the bitcoin preferences > because the close to tray check mark can not be enabled without the > minimize to tray check box being enabled. > > > On Sun, Nov 8, 2009 at 9:08 AM, Satoshi Nakamoto > wrote: > > Liberty Standard wrote: > > I downloaded it and it runs. It and it is using plenty of CPU, > so I think it's working properly. It has not downloaded > previously generated blocks. Is that a bug or a new feature? > > > If you mean the blocks count in the status bar isn't working its way > up to around 26600, then that's a bug, you should send me your > debug.log. (which is at ~/.bitcoin/debug.log) > > > The system tray in Gnome is not very reliable. Sometimes an icon > will disappear leaving no way to get back to the program. I have > verified that this can happen with bitcoin. It would be nice if > starting bitcoin while it's already running would just bring up > the GUI of the already running bitcoin process. > > > We haven't figured out how to find and bring up the existing running > program yet on Linux like it does on Windows. Given what you say, I > should at least turn off the minimize to tray option initially by > default. > Martii Malmi (AKA Sirius) “COPA trial” email #67 Date: Sun, 08 Nov 2009 18:48:38 +0000 From: Satoshi Nakamoto Subject: Re: Forum To: mmalmi@cc.hut.fi I'm not really a fan of that type of forum layout. The thread list only fits about 4 threads on a page, posts are treated like news articles or blog posts with reply comments at the bottom. It's more of a social networking site, not really conducive to technical discussion. I'm thinking phpBB or IPB or similar. One line of text per thread, small fonts, efficient use of vertical space. Most people are already familiar with the interface. mmalmi@cc.hut.fi wrote: > I made a ning.com site for testing: bitcoin.ning.com. At least it's > there to get Google hits, even if we didn't use it. > Martii Malmi (AKA Sirius) “COPA trial” email #68 Date: Mon, 09 Nov 2009 01:23:59 +0000 From: Satoshi Nakamoto Subject: Re: Linux build ready for testing To: Liberty Standard Cc: Martti Malmi Liberty Standard wrote: > Ok, blocks have now started to increase. It definitely takes longer for > them to start increasing than with the Windows version. Also, I think > they might be increasing at a slower rate than in with the Windows > version. Is there perhaps debugging enabled in the Linux build that you > sent me? Block are increasing at about 15 blocks per second (eyeball > estimate while looking at a clock). I didn't time how fast they > increased in the Windows version, but it seems like it was much faster. About how long did it take to start? It could be the node that you happened to request from is slow. The slow start is consistent with the slow download speed. I'd like to look at your current debug.log file and try to understand what's going. It might just be a really slow connection on the other side, or maybe something's wrong and failed and retried. Taking too long could confuse other users. Martti, how long did it take to start downloading blocks when you ran it, and how fast did it download? > When I launch bitcoin and the bitcoin port is not available, I get > the following messages to the command line. I don't get those > messages when the bitcoin port is available. Would it be possible > for bitcoin to pick another port if the default port is taken? The > same think sometimes happens to me with my BitTorrent client. When I > restart it, my previously open port is closed. All I have to do is > change the port and it starts working again. > > /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64 > Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so > /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF > class: ELFCLASS64 > Failed to load module: > /usr/lib/gio/modules/libgioremote-volume-monitor.so > /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64 > Failed to load module: /usr/lib/gio/modules/libgiogconf.so It already uses SO_REUSEADDR so it can bind to the port if it's in TIME_WAIT state after being closed. The only time it should fail to bind is when the program really is already running. It's important that two copies of Bitcoin not run on the same machine at once because they would be modifying the database at the same time. There is never any need to run two on one machine as coin generation will now use multiple processors automatically. I'm not sure what those lib errors are, I'll do some searching. Martii Malmi (AKA Sirius) “COPA trial” email #69 Date: Mon, 09 Nov 2009 05:42:59 +0000 From: Satoshi Nakamoto Subject: Re: Linux build ready for testing To: Liberty Standard Cc: Martti Malmi Thanks for that, I see what happened. Because the first one was slow, it ended up requesting the blocks from everybody else, which only bogged everything down. I can fix this, I just need to think a while about the right way. There's no risk in shutting down while there are unconfirmed. When you make a transaction or new block, it immediately broadcasts it to the network. After that, the increasing #/confirmed number is just monitoring the outcome. There's nothing your node does during that time to promote the acceptance. Now that I think about it, when you close Bitcoin, it closes the main window immediately but in the background continues running to finish an orderly flush and shutdown of the database. Before I implemented that, it was annoying having a dead hung unresponsive window hanging around. Until it finishes the orderly shutdown in the background, the port would be locked, and this is an important protection to make sure another copy can't touch the database until it's done. I haven't seen the shutdown take more than a few seconds. In Wine, there's no way for the Windows version to do SO_REUSEADDR, so that would add 60 seconds (on my system) of TIME_WAIT after the port is closed. If you need to transfer between two copies, you could send it to the other's bitcoin address. The receiving copy doesn't have to be online at the time. The command line to use a different data directory is bitcoin -datadir= For example, on Linux, the default directory is (don't use ~) bitcoin -datadir=/home/yourusername/.bitcoin You shouldn't normally have any need to use this switch. It still won't let you run two instances at once. Liberty Standard wrote: > On Mon, Nov 9, 2009 at 3:23 AM, Satoshi Nakamoto > wrote: > > Liberty Standard wrote: > > Ok, blocks have now started to increase. It definitely takes > longer for them to start increasing than with the Windows > version. Also, I think they might be increasing at a slower rate > than in with the Windows version. Is there perhaps debugging > enabled in the Linux build that you sent me? Block are > increasing at about 15 blocks per second (eyeball estimate while > looking at a clock). I didn't time how fast they increased in > the Windows version, but it seems like it was much faster. > > > About how long did it take to start? It could be the node that you > happened to request from is slow. The slow start is consistent with > the slow download speed. > Martii Malmi (AKA Sirius) “COPA trial” email #71 Date: Mon, 09 Nov 2009 19:30:53 +0000 From: Satoshi Nakamoto Subject: Re: Linux build ready for testing To: Liberty Standard Cc: Martti Malmi You really don't want to keep running in Wine, you're getting database errors (db.log). You probably developed these rituals of transferring to a fresh install to cope with database corruption. If there is a way to lose unconfirmed blocks, it would have to be the database errors. Any problems you find in the Linux build can be fixed. The Wine incompatibility deep inside Berkeley DB is unfixable. I think GCC 4.3.3 on the Linux build optimized the SHA-256 code better than the old GCC 3.4.5 on Windows. When I was looking for the best SHA-256 code, there was a lot of hand tuned highly optimized SHA1 code available, but not so much for SHA-256 yet. I should see if I can upgrade MinGW to 4.3.x to get them on a level playing field. Liberty Standard wrote: > Everyone that contributed to making this Linux build really did a great > job! Thanks for the hard work. It has started maturing some bitcoins, so > I'm going to continue to run the Linux client for the time being until I > decide whether it's at least as good or better at generating coins than > the Windows version running in Wine. > > > On Mon, Nov 9, 2009 at 8:59 AM, Liberty Standard > > wrote: > > Another instance when I would like to run multiple instances is when > I upgrade bitcoin. I will uncheck the generate coin check box in the > outdated bitcoin, launch and start generating coins in the new > bitcoin using a separate data directory, then when the old > application's coins have matured I will send them to the new > application and then close the old application. I prefer do do clean > installs rather than upgrading while maintaining old data. > Martii Malmi (AKA Sirius) “COPA trial” email #72 Date: Mon, 09 Nov 2009 19:41:11 +0000 From: Satoshi Nakamoto Subject: Re: Linux build ready for testing To: mmalmi@cc.hut.fi Cc: Liberty Standard You got a lot done with the Linux build, autostart, minimize to tray, setup and everything, it's really appreciated. Good luck on your C++ project. mmalmi@cc.hut.fi wrote: > I'll have to focus on a school project (coincidentally C++ coding) for > about a month now, so I don't have that much time for active developing > until December. Let's keep contact anyway. > Martii Malmi (AKA Sirius) “COPA trial” email #73 Date: Tue, 10 Nov 2009 16:46:04 +0000 From: Satoshi Nakamoto Subject: Re: Linux - dead sockets problem To: Liberty Standard Cc: Martti Malmi I see what happened. All your sockets went dead somehow. You had no communication with the network, but because you had 8 zombie connections, it thought it was still online and kept generating blocks. You can tell this is happening when your blocks are numbered sequentially, without other people's blocks interspersed, like: 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 blocks 7 blocks It's implausible that you would be the only one to find blocks for 6 blocks in a row like that. When you exited and restarted, it connected and downloaded 45 blocks that the network found in your absence. Since your blocks were not broadcast to the network immediately, the network went on without them. It sounds like you had exactly the same problem on Wine. There's clearly something about socket handling on Linux that's effecting it either way. I'll start researching this. Ultimately if I can't find the root of the problem, I'll have to make some kind of mechanism to watch for an absence of messages and disconnect. The only workaround for you right now would be to exit and restart more often. All but one of your node connections went dead at the same time, one shortly after. IRC was still working, so it wasn't that you were offline from the internet. I wonder if the status of blocks should say "#/unconfirmed" all the way up to maturity (119/unconfirmed then 120 blocks) instead. The meaning of the number isn't as strong for blocks as for transactions. I think it would be an improvement not to count one's own blocks as confirmations. A drawback would be that the status numbers shown by different nodes would not match. The status number would no longer be coordinated with the maturity countdown on blocks either. A lighter option would be a special case only if all confirmations are your own. Liberty Standard wrote: > I just lost 6 sets of maturing coins! I had 10 sets of bitcoins > maturing. The last set was generated at about 0:22. It got to > 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was > generated at 0:22 was still only at 2/unconfirmed. Since you had told me > that I wasn't going to lose coins, I shutdown and restarted bitcoin. On > the bright side, it shutdown and started up very smoothly. But > unfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four > sets were still unconfirmed, but two sets were confirmed. And there's no > trace of them now. Perhaps now that you have the 'Show Generated Coins' > option available, you can put back in failed bitcoin generations. I just > don't like that those bitcoins just disappeared into thin air. I'm still > running the Linux build at the moment, but the Wine version is suddenly > looking much more attractive now that 6 out of the 10 sets of bitcoins I > generated in the past 24 hours just vanished. I've included my debug.log. > Martii Malmi (AKA Sirius) “COPA trial” email #74 Date: Wed, 11 Nov 2009 00:39:19 +0000 From: Satoshi Nakamoto Subject: Re: Linux - linux-0.1.6-test2 To: Liberty Standard Cc: Martti Malmi I fixed a few places I found where it was possible for a socket to get an error and not get disconnected. If your connections go dead again, it should disconnect and reconnect them. I also implemented an inactivity timeout as a fallback. This also includes a partial fix for the slow initial block download. You should run with the "-debug" switch to get some additional debug.log information I added that'll help if there are more problems. linux-0.1.6-test2.tar.bz2 12,134,012 bytes Download: http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html Martii Malmi (AKA Sirius) “COPA trial” email #75 Date: Wed, 11 Nov 2009 00:41:06 +0000 From: Satoshi Nakamoto Subject: Re: Linux - linux-0.1.6-test2 attachment To: Liberty Standard Cc: Martti Malmi linux-0.1.6-test2.tar.bz2 attached Martii Malmi (AKA Sirius) “COPA trial” email #76 Date: Thu, 12 Nov 2009 05:36:06 +0000 From: Satoshi Nakamoto Subject: Linux - linux-0.1.6-test3 To: Liberty Standard Cc: Martti Malmi Right now (04:50 GMT) my node is connecting to yours and getting zombie connections each time. The socket isn't returning an error, just zombie without notice. If you're running the linux build right now, it would be interesting to see what the log says on your side. test3: I've added specific code to detect zombie sockets. It'll detect if the socket hasn't sent or received any data within 60 seconds of connecting, and detect if data is queued to send and hasn't sent for 3 minutes. I think I may have weakened the reconnect speed in test2. In test3 I'm making it more determined to reconnect quickly. I added checking to track whether other nodes received your generated blocks. If none did, it'll warn you in the description: "Generated - Warning: This block was not received by any other nodes and will probably not be accepted!" The status can go to "#/offline?" for blocks or transactions you create if they don't get out to any other nodes. With all this, it should be impossible not to notice as soon as it screws up. It should hopefully disconnect all the zombie sockets. After that, whether it's able to make some good connections, or sockets is completely hosed and it stays at 0 connections, I don't know. If this doesn't work, I guess I'll look at the sourcecode of some other P2P apps like BitTorrent and see how they deal with this stuff. Maybe there's some magic flag or procedure to bash the sockets system back to life. File linux-0.1.6-test3.tar.bz2 attached in the next message. Liberty Standard wrote: > On Wed, Nov 11, 2009 at 8:08 AM, Liberty Standard > > wrote: > > My network connection is direct to my computer. My ISP requires that > I run VPN to connect to the Internet. I then have a second NIC that > shares my Internet with other devices. My IP address while using my > computer is my actual IP address, but the devices connected through > my second NIC use NAT. When I connect through a virtual machine, > that also uses NAT. All this requires very little configuration. > NetworkManager in Ubuntu has an option to share my Internet > connection through the second NIC and VirtualBox has the option to > use NAT. > > I lost a couple packs of bitcoins again, so that problem is not yet > fixed. It's a bit more bearable now that I have an idea of what is > going on. I figure for now I'll just restart bitcoin whenever I see > a pack of bitcoins starting to mature. I may go back and forth a bit > between Linux and Wine, but I'll definitely test every new version > that comes out. At the moment I'm still running the Linux build. > Martii Malmi (AKA Sirius) “COPA trial” email #77 Date: Thu, 12 Nov 2009 05:37:58 +0000 From: Satoshi Nakamoto Subject: linux-0.1.6-test3.tar.bz2 attached To: Liberty Standard Cc: Martti Malmi File linux-0.1.6-test3.tar.bz2 attached linux-0.1.6-test3.tar.bz2 12,143,473 bytes Martii Malmi (AKA Sirius) “COPA trial” email #78 Date: Thu, 12 Nov 2009 23:39:44 +0000 From: Satoshi Nakamoto Subject: linux-0.1.6-test5 fix for zombie sockets To: Liberty Standard Cc: Martti Malmi test 5: I added MSG_DONTWAIT to the send and recv calls in case they forgot the socket is non-blocking. If that doesn't work, there's now the catch-all solution: another thread monitors the send/recv thread and terminates and restarts it if it stops. It prints "*** Restarting ThreadSocketHandler ***" in debug.log, and an error message displays on the status bar for a while. Before terminating, it tries closing the socket that's hung. If that works, it doesn't have to resort to terminating. I ran a test where it terminated the thread about 1000 times without trouble, so it should be safe. The terminate on linux is pthread_cancel, which throws it into C++'s exception handler. The thread calls we were using didn't have terminate, so I created our own wrappers in util.h to use CreateThread on windows and pthread_create on linux, instead of: _beginthread is windows only and lacks terminate boost::thread is really attractive, but lacks terminate wxThread requires you to create a class for every function you might call (yuck) File attached in the next e-mail Martii Malmi (AKA Sirius) “COPA trial” email #79 Date: Thu, 12 Nov 2009 23:42:29 +0000 From: Satoshi Nakamoto Subject: linux-0.1.6-test5.tar.bz2 attached To: Liberty Standard Cc: Martti Malmi 12,033,918 linux-0.1.6-test5.tar.bz2 Martii Malmi (AKA Sirius) “COPA trial” email #80 Date: Sat, 14 Nov 2009 05:46:22 +0000 From: Satoshi Nakamoto Subject: Zetaboards forum To: Martti Malmi I created a forum on Zetaboards, InvisionFree's new site that they're migrating to. http://s1.zetaboards.com/Bitcoin/index/ I made an admin account you can use to upgrade your own account to admin: u: admin pw: B98VzUUA BTW, the admin pages have a huge blank space at the top, you have to scroll down. It doesn't support SSL, but none of them do. I replaced the ugly default orange and blue theme with the Frostee theme, which was the only decent looking theme I could find after extensive searching. Searching for themes is futile, there are thousands of rubbish themes. It turns out the solution is to look at button sets instead (http://resources.zetaboards.com/forum/1000328/) I only created two subforums to begin with. I'll create new ones as the need arises. I like to start with a flat namespace until there's enough items to justify subsections. Technical Support makes sense as a separate section to get that stuff out of the main spotlight so our dirty laundry isn't in everyone's face, and to make people feel more free to report bugs there. Mostly only devs and people checking on a bug need read the Technical Support section. Martii Malmi (AKA Sirius) “COPA trial” email #81 Date: Sun, 15 Nov 2009 15:40:29 +0000 From: Satoshi Nakamoto Subject: Linux update To: Martti Malmi linux-0.1.6-test5 solved Liberty's zombie socket problem. The MSG_DONTWAIT fixed the root cause, it's not having to terminate and restart the thread. The sockets are marked non-blocking already, so I don't understand why. Maybe it forgot. I suppose if a socket fails and the OS closes it then there's nothing left to remember it was non-blocking, but then accessing a closed handle should return immediately with an error. There's no MSG_DONTWAIT on Windows, marking the socket as nonblocking is the only way, so if anyone runs the Windows version in Wine it will have to rely on terminating the thread. The only problem now is the DB exceptions he's getting. ************************ EXCEPTION: 11DbException Db::open: Bad file descriptor bitcoin in ThreadMessageHandler() ************************ EXCEPTION: 11DbException Db::close: Bad file descriptor bitcoin in ThreadMessageHandler() I had expected those to be a Wine problem, but he's getting them on Linux just the same. He tried moving the datadir to a different drive, no help. I've never gotten them. I'm running a stress test that continuously generates a lot of activity and DB access and never got it. He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the difference. Is your Linux machine 64-bit or 32-bit? Have you ever had a DB exception? (see db.log also) Now that the zombie problem is fixed in test5, could you start running it on your Linux machine? We could use a 3rd vote to get a better idea of what we're dealing with here. The DB exception is uncaught, so it'll stop the program if you get it. BTW, zetaboards insists on displaying "Member #", so you better sign up soon and grab a good account number. Martii Malmi (AKA Sirius) “COPA trial” email #83 Date: Sun, 15 Nov 2009 19:15:42 +0000 From: Satoshi Nakamoto Subject: Re: Linux update To: mmalmi@cc.hut.fi I'd better install 64-bit then. I imagine it's something about the 32-bit version of Berkeley DB on 64-bit Linux. BTW, in things like the feature list credits, do you want me to refer to you as sirius-m or Martti Malmi? I think most projects go by real names for consistency. Martii Malmi (AKA Sirius) “COPA trial” email #85 Date: Sun, 15 Nov 2009 20:25:26 +0000 From: Satoshi Nakamoto Subject: Re: Linux update To: mmalmi@cc.hut.fi At first glance, bitcoinshop.com looks better. bitcoinexchange.com might be better than bitcoinx.com. Be careful where you search domain names, many will front-run you. Even network solutions, although they've said they won't if you use their whois page not the homepage. The only safe place is http://www.internic.com/whois.html mmalmi@cc.hut.fi wrote: > Perhaps the real name is better. > > Another name question: I've been thinking of a name for the exchange > service, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop > (bitcoinshop.com). Which one do you find better? > Martii Malmi (AKA Sirius) “COPA trial” email #86 Date: Mon, 16 Nov 2009 06:20:52 +0000 From: Satoshi Nakamoto Subject: Re: Db::open/Db::close "Bad file descriptor" exception To: Liberty Standard Cc: Martti Malmi I have an idea for a workaround, but it depends on what files the errors are on. If you've accumulated several errors in db.log, could you send it to me? (even if it's rather simple and boring) Is the file listed always blkindex.dat, or does it include addr.dat or wallet.dat too? Liberty Standard wrote: > I moved the data directory back to my SSD card and started bitcoin test > 6. It encountered a segmentation fault today with Db::open in the log. I > had changed the settings to only use one processor/core while I watched > a 720p mkv movie. I noticed the segmentation fault after the film had ended. > > On Sun, Nov 15, 2009 at 12:45 AM, Satoshi Nakamoto > wrote: > > Here's one where I linked Berkeley DB a different way. It's worth a > try. Otherwise identical to test5. > > (Keep the datadir on the hard drive at least until you get it to > fail the same way there. That has a fair chance of success.) > Martii Malmi (AKA Sirius) “COPA trial” email #88 Date: Mon, 16 Nov 2009 19:34:56 +0000 From: Satoshi Nakamoto Subject: Re: Forum To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently > enabled with a self-signed certificate. Admin password is the same as in > the Bitweaver. How about using this as the site platform? Maybe we can > make bitcoin.org or at least bitcoin.sf.net point there? What do you see as the benefits of switching the wiki? Some I can think of: SSL get away from sourceforge's unreliable hosting everything not logged by sourceforge The forum feature is about as weak as bitweaver. We need a full blown forum software for that. My priority right now is to get a forum going, either phpBB or similar. What do you think of the zetaboards option? Should we go ahead with that? Martii Malmi (AKA Sirius) “COPA trial” email #90 Date: Mon, 16 Nov 2009 21:10:22 +0000 From: Satoshi Nakamoto Subject: Re: Forum To: mmalmi@cc.hut.fi That's a good idea to go in a more web-publishing CMS type direction like Drupal. That's a better fit and can produce a better looking website than a wiki. I think I was wrong about wiki. Only a few specific people will do any website design work and those people can go ahead and have a separate login. In that case, login integration with the forum doesn't matter much. For security, I'd almost rather have a different login than be constantly checking the forum with the same login that could pwn the website. Drupal's forum is less bad than the wikis, but still a long way from something I would want to use. zetaboards pros and cons: pros: - we don't have to worry about bandwidth - they handle the backend management and security patches con: - lack of SSL - lack of privacy, everything is logged - lack of control over the php code for customization - no CAPTCHA, and if they add one later it might be unacceptable flash - ads (could pay to get rid of them later if we care enough) - there's always the risk they abruptly cancel the site for some petty reason mmalmi@cc.hut.fi wrote: >> What do you see as the benefits of switching the wiki? >> Some I can think of: >> SSL >> get away from sourceforge's unreliable hosting >> everything not logged by sourceforge > > I think the biggest advantage is having a single site so you don't need > a separate account for the wiki and the forum, and the functionalities > are also nicely integrated with the main site itself. Also being ad-free > is a plus. > >> The forum feature is about as weak as bitweaver. We need a full blown >> forum software for that. > > How about Drupal's forum functionality? Address: > https://174.143.149.98/drupal/. The CMS in general looks better and > simpler than TikiWiki. If the forum's not good enough, then we can of > course use a specialized forum software like phpBB. > >> My priority right now is to get a forum going, either phpBB or similar. >> What do you think of the zetaboards option? Should we go ahead with >> that? > > Otherwise fine, but the ads and the lack of SSL are a minus. > Martii Malmi (AKA Sirius) “COPA trial” email #91 Date: Tue, 17 Nov 2009 03:41:26 +0000 From: Satoshi Nakamoto Subject: linux-0.1.6-test7 To: Liberty Standard Cc: Martti Malmi test 7: Backup your data directory before running this, just in case. Workaround for the Db::open/Db::close "Bad file descriptor" exception. Might also make the initial block download faster. The workaround is to open the database handles and keep them open for the duration of the program, which is actually the more common thing to do anyway. If we're not closing and opening all the time, the error shouldn't get a chance to happen. The one exception is wallet.dat, which I still close after writing is finished so I can flush the transaction logs into the dat file, making the dat file standalone. That way if someone does a backup while Bitcoin is running, they'll get a wallet.dat that is valid by itself without the database transaction logs. This is a restructuring of the database handling, so we might find some new deadlocks. Usually if it deadlocks, either the UI will stop repainting, or it'll stop using CPU even though it still says Generating. Martii Malmi (AKA Sirius) “COPA trial” email #92 Date: Tue, 17 Nov 2009 16:57:26 +0000 From: Satoshi Nakamoto Subject: Re: Forum To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > How about Drupal's forum functionality? Address: > https://174.143.149.98/drupal/. The CMS in general looks better and > simpler than TikiWiki. If the forum's not good enough, then we can of > course use a specialized forum software like phpBB. Another issue I thought of with zetaboards: most free forum sites won't let you export the user account database if you want to move. I don't know why I don't see any other software projects using a free forum, but I have to assume there might be a reason we would discover later. If you can install phpBB3 on your VPS, that's probably the better option. From what I've seen on other forums, if the cost of bandwidth becomes an issue, a small Google Adwords (text links) at the top generates more than the cost of bandwidth even for very low value traffic like gaming. This would be much higher value traffic well targeted for high paying gold merchant keywords and VPN hosts. It could eventually be a valuable revenue stream you wouldn't want to give away to some free site. I want to pre-announce some of the features in version 0.2 on the forum and try to get some anticipation going. Even if hardly anyone else is posting, I have seen project forums where most of the posts are the author announcing what's going on with the latest changes. Users can see progress going on, see that it's improving and supported and not abandonware. It's a little like a blog in that case, but easier for users to use it as a searchable FAQ and better organized. Whenever I google search software questions, most of the hits are forum posts. Martii Malmi (AKA Sirius) “COPA trial” email #95 Date: Wed, 18 Nov 2009 04:35:32 +0000 From: Satoshi Nakamoto Subject: Re: linux-0.1.6-test7 To: Liberty Standard Cc: Martti Malmi Finally an easy one. I see a way that could happen on a long operation such as the initial download. The TryLock bug is unrelated to the db stuff. Fix will be in test8. I've been able to reproduce the db::open/close exception 3 times now on 32-bit linux by hitting it with a continuous flood of non-stop requests. It looks like even periodically closing the wallet.dat database to flush it gets the db::close exceptions. I'm disabling the wallet flush feature on Linux. On Linux we'll never close a database handle until we're ready to exit. So far with this disabled, no exceptions. I'm also implementing the orderly initial block download. Instead of naively requesting all the blocks at once, it'll request batches of 500 at a time. This way, it'll receive the blocks before the retry timeout, so it shouldn't go requesting it from other nodes unless it actually doesn't receive them or it's too slow. The change is in the requestee's side, so this functionality won't be visible until your initial block download is coming from a node that has the new version. I'm going to test this some more before sending test8. Liberty Standard wrote: > I started with a fresh data directory with test7. Blocks started to > download much faster. It only took about 15 seconds where it took a few > minutes previously with the Linux build. It crashed once while it was > downloading blocks with the following message in the terminal. > > ../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock(): > wxMutex::TryLock(): not initialized [in child thread] > Trace/breakpoint trap > > I've included my log file, but I forgot to back it up before restarting > bitcoin, so I'm not sure at what point in the log file the crash occurred. > > Fortunately I haven't encountered the segmentation fault yet. The > frequency of segmentation faults in the previous builds varied quite a > bit, so I'll keep running it and let you know if i run into any problems. > Martii Malmi (AKA Sirius) “COPA trial” email #96 Date: Wed, 18 Nov 2009 05:14:45 +0000 From: Satoshi Nakamoto Subject: Re: Db::open/Db::close "Bad file descriptor" exception To: mmalmi@cc.hut.fi Thanks. The db::open/close errors confirm the pattern. More interesting is the zombie sockets activity towards the end, and the socket thread monitor tripped but didn't get it going again. Was the machine disconnected from the net? MSG_DONTWAIT in test5 solved the zombie problem for Liberty. What test version were you running? (I should print the test version in the log) mmalmi@cc.hut.fi wrote: > Here's the logs in case they're still useful. > >> I have an idea for a workaround, but it depends on what files the >> errors are on. If you've accumulated several errors in db.log, could >> you send it to me? (even if it's rather simple and boring) Is the file >> listed always blkindex.dat, or does it include addr.dat or wallet.dat >> too? > Martii Malmi (AKA Sirius) “COPA trial” email #97 Date: Wed, 18 Nov 2009 05:32:22 +0000 From: Satoshi Nakamoto Subject: Re: Forum To: mmalmi@cc.hut.fi That's great, this is going to fun! I'll research what people say about the two. mmalmi@cc.hut.fi wrote: > I installed both phpBB3 and Simple Machines Forum, which are kind of > the market leaders among the open source forums. SMF's interface looks > better on the first look, especially the admin panel. What do you > think, shall we go with SMF or phpBB3? > Martii Malmi (AKA Sirius) “COPA trial” email #99 Date: Fri, 20 Nov 2009 05:14:56 +0000 From: Satoshi Nakamoto Subject: SMF forum, need a mod installed To: Martti Malmi I've been configuring the SMF forum. They're saying SMF is better written than phpBB and more reliable, so if I can get SMF to look right, that's the preferable choice. Most forums run vBulletin (big-boards.com lists 1376 vBulletin, 275 Invision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or Invision, it looks like you compromised because you couldn't afford vBulletin. SMF's UI started out further away from the standard look, but I've been able to use CSS to make it look more like the others. I've done as much as I can with CSS, the rest requires editing PHP files and uploading images. The forum doesn't have a built in file upload/edit admin feature, it's added separately as the SMF File Manager mod. I uploaded the mod but some files need to be chmod 777 so it can install. If you go to Admin->Packages->Browse Packages and click on Apply Mod, it offers to do it automatically if you enter an ftp login. Someone says you might also have to mkdir /var/www/bitcoin/smf/packages/temp The error in the error log is: failed to open stream: Permission denied File: /var/www/bitcoin/smf/Sources/Subs-Package.php (I'm sure that's just the first file) Is it OK to go live with this SMF installation when I'm finished configuring it? I should be able to point forum.bitcoin.org to it. Liberty reports that linux-test8 has been running smoothly. My tests have been running fine as well. The Linux version looks fully stabilized to me. Good news: he says he made his first sale of bitcoins. Someone bought out all he had. I had been wondering whether it would be buyers or sellers. Martii Malmi (AKA Sirius) “COPA trial” email #102 Date: Fri, 20 Nov 2009 22:09:41 +0000 From: Satoshi Nakamoto Subject: Re: SMF forum, need a mod installed To: mmalmi@cc.hut.fi > It's okay to go live. Are you setting up a redirect or a dns entry? In > case of dns entry I could set up an Apache vhost so that the forum > address would be http://forum.bitcoin.org/. DNS entry. I'm thinking of merging the bitcoin.org information with your site content so I can switch the whole bitcoin.org domain over. We need to replace the current bitcoin.org site with a user-oriented site before the release. If the website and forum switch at the same time, then forum.bitcoin.org isn't necessary unless we want it that way for looks. Have you decided on the CMS to use? I should research Drupal and other CMSes and see what's the most popular. > Great that the Linux build works now. It's exciting to see how things > will start rolling with the new release and the forum. Not too long > until I can set up my own exchange and start promoting the currency to > (web) business people. The linux version, setup exe, tor option and better website/forum will all increase the percentage of visitors who can use it, and the autostart and minimize to tray will increase how many keep running it. All those factors multiply together. > NewLibertyStandard should perhaps change his pricing to the market price > (i.e. what people are willing to buy and sell for) so that he doesn't > run out of coins. It's good to start low and only have the price go up. I really like that he explains the concept that the cost of electricity is a minimum floor under the price. At a minimum you either have to pay the cost in electricity or pay someone the cost of production to make them for you. Martii Malmi (AKA Sirius) “COPA trial” email #103 Date: Sat, 21 Nov 2009 07:02:20 +0000 From: Satoshi Nakamoto Subject: Re: SMF forum, need a mod installed To: mmalmi@cc.hut.fi Thanks, that worked, I got File Manager installed with SSH. I also uploaded a few themes into Drupal. I haven't thoroughly gone through all the available themes yet. Looked around at CMSes, Drupal and Joomla are popular. Consensus is Joomla has a better selection of themes and is easier to learn, though Drupal may be more intuitive for programmers and customization. Joomla better for CMS, Drupal better for blogs. Drupal's URLs are search engine friendly, Joomla not. Both have SMF bridge modules available. For future reference, Drupal's is named "SMFforum Integration". mmalmi@cc.hut.fi wrote: > I don't have the time to configure it today, but I made a temporary > account "" with password "" and full permissions to > /var/www/bitcoin. You can access it via ssh or sftp at port 30000. Martii Malmi (AKA Sirius) “COPA trial” email #105 Date: Sat, 21 Nov 2009 21:46:52 +0000 From: Satoshi Nakamoto Subject: Re: SMF forum, need a mod installed To: mmalmi@cc.hut.fi I'll go ahead with setting up Drupal then. I don't think we should make the site https by default. It's still very unusual for the public part of sites to be https, probably because it introduces potential technical complications, delays and greater server load. As a user I'm a little annoyed when it takes time to verify the identity of some no-name site I casually came across. For me it seems like https sites fail to load a lot more often. The important thing is to have SSL available for those who need it. Those who need SSL I think know to try inserting an "s" after http and see if it works. SMF has code that changes all the links to https if the URL handed in is https. We could add a note on the registration page that if you want SSL, you can change http to https at any time and approve the self-signed certificate, or a link that does it, and the TOR page can mention it too. We can look into getting a certificate later when things have settled down. With Class 1, no changes are allowed for a year, which is a risk if we find issues with the current host and have to change IP. mmalmi@cc.hut.fi wrote: > I've done a Joomla site for a customer, and I must say I like Drupal > better, mostly for the admin interface which is easier to use and > integrated into the main site. > > Images aren't loading properly over https, I'll check it out when I can. > > It's easier to just change the bitcoin.org DNS entry, forum.bitcoin.org > is not necessary. > > We could see if we can get a free SSL certificate somewhere, like > http://www.startssl.com/?app=1, so the users wouldn't get a security > warning from a self-signed certificate. However I don't know if they > give certificates for anonymously registered domains. > Editor’s note Satoshi’s first post on the new https://bitcointalk.org forum was a brief welcome message with the following timestamp: November 22, 2009, 06:04:28 PM. After this message board was set up, Satoshi began using it frequently. This is witnessed in the records that follow. Satoshi’s first bitcointalk message can be read at https://bitcointalk.org/index.php?topic=5.msg28#msg28 BitcoinTalk 2009-11-22 18:04:28 UTC -  -  Welcome to the new Bitcoin forum! The old forum can still be reached here: http://bitcoin.sourceforge.net/boards/index.php I'll repost some selected threads here and add updated answers to questions where I can. FAQ http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ Download http://sourceforge.net/projects/bitcoin/files/ BitcoinTalk Repost: Bitcoin Maturation 2009-11-22 18:31:44 UTC -  -  -------------------- bitcoinbitcoin: Bitcoin Maturation Posted:Thu 01 of Oct, 2009 (14:12 UTC) From the user's perspective the bitcoin maturation process can be broken down into 8 stages. 1. The initial network transaction that occurs when you first click Generate Coins. 2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list. 3. The change of the bitcoin entry from outside the All Transaction field to inside it. 4. 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). 5. The change of the Description to Generated (50.00 matures in x more blocks). 6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated. 7 The change of the Description to Generated. 8. The time after the Description has changed to Generated. Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names? -------------------- sirius-m: Re: Bitcoin Maturation Posted:Thu 22 of Oct, 2009 (02:36 UTC) As 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. In 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. BitcoinTalk Repost: Request: Make this anonymous? 2009-11-22 18:32:00 UTC -  -  -------------------- anonguy54: Request: Make this anonymous? Posted:Thu 15 of Oct, 2009 (19:58 UTC) Are there any plans to make this service anonymous? e.g; Being able to route BitCoin through Tor. Martii Malmi (AKA Sirius) “COPA trial” email #106 Date: Sun, 22 Nov 2009 19:47:56 +0000 From: Satoshi Nakamoto Subject: SEO friendly site transition To: Martti Malmi We need to do a continuity transition with bitcoin.org so the search engines don't think this is a new site and reset the site start date and PR data. Google allows a certain number of properties like IP address or content of the site to change without deleting your site history. To play it safe, when the IP address changes, the content better stay the same and vice versa. Even though not much rank has accumulated yet, the original start date becomes extremely important if the site gets popular later. Steps: 1) copy the current bitcoin.org index.html to the new server exactly as-is. 2) switch the bitcoin.org DNS entry. 3) keep working on the drupal site behind the scenes. 4) after google has had time to update its records, we can switch over to the drupal site. The timing works out well because we can switch to the new forum now and release the drupal site later when we're ready. I'll see if I can figure out how to temporarily move drupal aside to drupal.php or /drupal/ or something where we can still easily get in and work on it. Martii Malmi (AKA Sirius) “COPA trial” email #108 Date: Mon, 23 Nov 2009 05:48:19 +0000 From: Satoshi Nakamoto Subject: Access permissions required to fix Drupal To: Martti Malmi Drupal's .htaccess file which uses mod_rewrite to allow clean URLs without the ? parameter is not working because its changes are rejected because Apache is not configured with "AllowOverride All". This is needed to make Drupal coexist with the other site the way we want. I need access to change these files to fix it: /etc/apache2/sites-available/default /etc/apache2/sites-available/default-ssl /etc/apache2/httpd.conf Here's the planned fix. If you do it yourself, please still give me access to httpd.conf in case I need to change it again later. In /etc/apache2/sites-available/default change the 2nd instance of "AllowOverride None" to "AllowOverride All" and in /etc/apache2/sites-available/default-ssl change the 2nd instance of "AllowOverride AuthConfig" to "AllowOverride All" replace /etc/apache2/httpd.conf with /home/maintenance/httpd.conf This probably requires Apache to be restarted after. (apache2ctl graceful) BitcoinTalk Repost: How anonymous are bitcoins? 2009-11-25 18:15:57 UTC -  -  -------------------- bitcoinbitcoin: How anonymous are bitcoins? Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from? 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)? BitcoinTalk Re: Repost: How anonymous are bitcoins? 2009-11-25 18:17:23 UTC -  -  > Can nodes on the network tell from which and or to which bitcoin  > address coins are being sent? Do blocks contain a history of where  > bitcoins have been transfered to and from? Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information. When 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.  Blocks 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. The 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. For 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. > Can nodes tell which bitcoin addresses belong to which IP addresses? No. > Is there a command line option to enable the sock proxy the first > time that bitcoin starts? In the next release (version 0.2), the command line to run it through a proxy from the first time is: bitcoin -proxy=127.0.0.1:9050 The 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: bitcoin -proxy=127.0.0.1:9050 -addnode= If 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. > What happens if you send bitcoins to an IP address that has multiple > clients connected through network address translation (NAT)? Whichever one you've set your NAT to forward port 8333 to will receive it.  If your router can change the port number when it forwards, you could allow more than one client to receive.  For instance, if port 8334 forwards to a computer's port 8333, then senders could send to "x.x.x.x:8334"  If 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. Martii Malmi (AKA Sirius) “COPA trial” email #110 Date: Thu, 26 Nov 2009 00:26:33 +0000 From: Satoshi Nakamoto Subject: bitcoin.org DNS change went through To: Martti Malmi The bitcoin.org DNS change went through about 12 hours ago. I'll wait another 12 hours and then change the Forum tab on bitcoin.sourceforge.net to go to http://www.bitcoin.org/smf/ For future reference, the changes in SMF to update the base url were: server settings->Forum URL themes and layout->attempt to reset all themes there's a path in smileys and message icons Martii Malmi (AKA Sirius) “COPA trial” email #111 Date: Thu, 26 Nov 2009 17:45:42 +0000 From: Satoshi Nakamoto Subject: Bitweaver menu editor broken To: Martti Malmi The Bitweaver menu editor is broken, I can't change the Forum link. The "create and edit menu items" page comes up blank for me: http://bitcoin.sourceforge.net/nexus/menu_items.php?menu_id=2 You try it, I'm stumped. The Forum link should be changed to: http://www.bitcoin.org/smf/ BitcoinTalk Repost: Linux/UNIX compile 2009-11-27 17:17:22 UTC -  -  -------------------- scott: Linux/UNIX compile Posted:Thu 08 of Oct, 2009 (05:49 UTC) Can we get instructions or modifications to compile and install BitCoin on Linux? A command line version would be great. BitcoinTalk Re: Repost: Linux/UNIX compile 2009-11-27 17:27:09 UTC -  -  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. Command line is on the to-do list after 0.2. BitcoinTalk [OLD THREAD] Bitcoin version 0.2 development status 2009-11-27 22:48:39 UTC -  -  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:  - Minimize to system tray option  - Autostart on boot option so you can keep it running in the background automatically  - New options dialog layout  - Setup EXE for Windows, in addition to the archive download I'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:  - Multi-processor support for coin generation  - Proxy support Martii Malmi (AKA Sirius) “COPA trial” email #117 Date: Mon, 30 Nov 2009 20:34:20 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin.org To: mmalmi@cc.hut.fi Thanks, I haven't settled on a theme yet. My first experiment was to try something besides yet another blue site. Another line of thought is that it should be like a bank website, stately, professional and official looking to support confidence in financial matters. The logo's a little too Disco/web-1990's. I still like your bitweaver one better, I recreated it with text as a placeholder for now. When the theme is more settled, I'll think about a matching logo. Good idea about the Sourceforge tag, we can use all the graphics we can get. I have more to do before we go live, and we need to give the search engines more time. mmalmi@cc.hut.fi wrote: > I autogenerated the new logo at http://cooltext.com/, it's a good quick > solution. You can try a wide variety of different logo styles there if > you have the patience for the slow user interface. > >> It would be also great if you can get the Sourceforge logo from the SF >> project admin and add it to the site footer. >> >>> The current site layout looks nice and simple. The logo just should be >>> changed. If we want to go live quickly, we can just replace it with the >>> site title and make a better logo later. >>> >>> If we need help with site administration or contacts to professional >>> web graphic artists, we can ask Dave. He does Drupal stuff for work. > Martii Malmi (AKA Sirius) “COPA trial” email #119 Date: Wed, 02 Dec 2009 17:47:48 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin.org To: mmalmi@cc.hut.fi What Windows version/browser doesn't font anti-aliasing work on? IE 6 on XP anti-aliases, and versions below that have less than 1% market share. There's a transaction fee of 0.01 per KB after the first 1KB for oversized transactions. The first 1KB is free, small transactions are typically 250 bytes. Doubleclick on the transaction. Think of it like postage by weight. The solution is an extra dialog when sending, something like "This is an oversized transaction and requires a transaction fee of 0.20bc. Is this OK?" (is that text good enough or any improvements?) I have the code already, I'll put it in. Then we wouldn't have to explain the 10,000.20bc transaction, but may still have to explain who the transaction fee goes to. mmalmi@cc.hut.fi wrote: > The text logo looks quite good actually, except on Windows when the font > antialiasing doesn't work. I turned it into a png. > > I just made a 10,000bc transaction from one account to another, but it > ended up sending 10,000.20bc. Any idea why that could be? > Martii Malmi (AKA Sirius) “COPA trial” email #121 Date: Fri, 04 Dec 2009 04:24:41 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin.org To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: >> What Windows version/browser doesn't font anti-aliasing work on? IE 6 >> on XP anti-aliases, and versions below that have less than 1% market >> share. > > Firefox on XP doesn't, and IE also doesn't produce as good quality as I > have on Linux. Screenshots from browsershots.org attached. That's strange, I've seen Firefox 3.5 on XP anti-alias large fonts. Well anyway, your way is safer. I changed it back to text for now though so I can keep tweaking the colours. Drupal puts the tags and junk in the browser title but that's fine for testing. I added some instruction text on the homepage below the screenshots. > Is there no transaction fee then, if you send the same amount in > multiple small packages? True. I suppose the dialog could make it worse by giving people a chance to experiment with breaking it up. I'm making some changes. The largest free transaction will be 60KB, or about 27,000bc if made of 50bc inputs. I hope that's high enough that the transaction fee should rarely ever come up. v0.2 nodes will take free transactions until the block size is over 200K, with priority given to smaller transactions. It's best if you don't talk about this transaction fee stuff in public. It's there for flood control. We don't want to give anyone any ideas. > Where should it go btw? Here it went to the receiver along with all the > other coins. Transaction screenshot attached. You found an infrequent bug in CreateTransaction. It wrote the transaction for 10000.20 with a fee of 0.22. If you look at the transaction on the sender's side, it'll be a debit 10000.42 with transaction fee 0.22. The bug was that it had to make a rare third pass on calculating the fee, and incorrectly added the first pass' fee to the amount being sent. Will fix. Martii Malmi (AKA Sirius) “COPA trial” email #122 Date: Sun, 06 Dec 2009 03:21:00 +0000 From: Satoshi Nakamoto Subject: Re: Sourceforge tracker To: mmalmi@cc.hut.fi I added the sourceforge tracker to bitcoin.sourceforge.net. The complete selection of links is below if you want a different one. I had it on bitcoin.org for a minute, but took it off. It breaks the lock in SSL mode with a mixed content warning, "partially encrypted" and "contains unauthenticated content". Anyway, do we really want sourceforge tracking everyone? It's more privacy friendly without it. --- The available logos and the correct HTML to use for the Bitcoin project are: Logo 1 (Dimensions: 80 x 15; Background: Black) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 2 (Dimensions: 80 x 15; Background: Silver) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 3 (Dimensions: 80 x 15; Background: White) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 4 (Dimensions: 120 x 30; Background: Black) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 5 (Dimensions: 120 x 30; Background: Silver) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 6 (Dimensions: 120 x 30; Background: White) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 7 (Dimensions: 150 x 40; Background: Black) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 8 (Dimensions: 150 x 40; Background: Silver) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads Logo 9 (Dimensions: 150 x 40; Background: White) HTML Code: Get Bitcoin at SourceForge.net. Fast, secure and Free Open Source software downloads mmalmi@cc.hut.fi wrote: > It would be also great if you can get the Sourceforge logo from the SF > project admin and add it to the site footer. > >> The current site layout looks nice and simple. The logo just should be >> changed. If we want to go live quickly, we can just replace it with the >> site title and make a better logo later. >> >> If we need help with site administration or contacts to professional >> web graphic artists, we can ask Dave. He does Drupal stuff for work. > Martii Malmi (AKA Sirius) “COPA trial” email #124 Date: Tue, 08 Dec 2009 05:43:33 +0000 From: Satoshi Nakamoto Subject: Drupal site online To: Martti Malmi I went ahead and put the new Drupal site online. Enough time has passed for a safe transition, and the site looks good. There's more work I should do on the theme, but it's good enough so far. This is a huge improvement over the old bitcoin.org page. Martii Malmi (AKA Sirius) “COPA trial” email #126 Date: Fri, 11 Dec 2009 03:30:10 +0000 From: Satoshi Nakamoto Subject: custom3 theme To: Martti Malmi I wasn't satisfied with my custom2 theme. It felt crowded, the header/logo seemed wrong and the heavy left margin stationery style is outdated. custom3 online now is a more standard layout similar to a lot of commercial software homepages. Maybe it's just me, but I really like the random blue squares. BitcoinTalk Re: A few suggestions 2009-12-09 18:45:10 UTC -  -  Helpful suggestions, thanks. Quote from: madhatter on December 09, 2009, 05:34:46 AM - 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. 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.  Quote - 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. 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.   Quote - 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. That's one of the main things on the agenda after 0.2. Quote - 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). Yeah, the other stealth stuff would be kinda pointless if it's always the same port number. Quote - UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu. I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default? Quote - 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). 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? BitcoinTalk Re: A few suggestions 2009-12-10 19:31:49 UTC -  -  Quote from: madhatter2 on December 10, 2009, 02:00:17 PM Front ends can also be ran on clients with very low cpu power such as mobile phones.  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. Quote 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. 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. Quote 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). 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. The 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. Quote Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.  It's SVN on sourceforge.  PM or e-mail me your sourceforge account and I'll give you access. Quote I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas. 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. BitcoinTalk Re: Questions about Bitcoin 2009-12-10 20:49:02 UTC -  -  1-3: For that level of anonymity you need to connect through TOR, which will be possible with version 0.2, which is only a few weeks away.  I'll post TOR instructions at that time. 4: Version 0.1.5: backup the whole %appdata%\Bitcoin directory. Version 0.2: you can backup just wallet.dat. 5: Nope.  The whole design is all about preventing that from working. 6: 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. 7: It's currently 29,296 blocks.  The circulation is the number of blocks times 50, so the current circulation is 1,464,800 bc.   If 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. 8: Typically a few hundred right now.  It's easy now but it'll get harder as the network grows. 9: Good question, it's TCP.  The website needs to be updated to say TCP port 8333. The 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. 10: No, the other nodes won't accept that. 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. 11: Slower machines produce fewer coins.  It's proportional to CPU speed. 12: There are more coming. 13: It uses a transactional database called Berkeley DB.  It will not lose data in a system crash.  Transactions are written to the database immediately when they're received. 14: For now, you can just multiply the total blocks by 50.  The Bitcoin network has been running for almost a year now.  The design and coding started in 2007. BitcoinTalk Re: Questions about Bitcoin 2009-12-11 17:58:57 UTC -  -  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. The 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. BitcoinTalk Re: A few suggestions 2009-12-11 19:27:55 UTC -  -  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. Quote from: madhatter2 on December 11, 2009, 04:59:19 AM 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. 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. It 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) To only run a seed: bitcoin -min -gen=0 You could sort of monitor it by looking at debug.log.  To stop it, kill the process, the database won't mind. To generate: bitcoin -min -gen To 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. Quote 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). 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.   Quote In any event, I would like to help. I have a lot of time and a project like this one is very exciting. That's great, any help is really appreciated! BitcoinTalk Re: A few suggestions 2009-12-12 17:52:44 UTC -  -  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. BitcoinTalk Re: A few suggestions 2009-12-12 18:17:10 UTC -  -  Quote from: madhatter2 on December 12, 2009, 06:34:21 AM I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST!  I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next. Mac support would be nice.  wxWidgets really pays off for cross platform. Please 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. Considered 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. Quote 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. 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. I'd rather have command line control, that would get us remote admin and batch automation. BitcoinTalk Re: A few suggestions 2009-12-13 16:51:25 UTC -  -  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. Then a separate command line utility to communicate with it to do things.  Not sure what it should be named. "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. BitcoinTalk Re: A few suggestions 2009-12-14 17:15:56 UTC -  -  Quote from: madhatter2 on December 14, 2009, 03:01:39 PM Can anyone shed some light here? g++ -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 ... ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string, std::allocator >&)' /usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&) It looks like the implicit conversion from std::string to wxString isn't working. \u00a0That's used everywhere, the conversion needs to work. wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. \u00a0You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char. It's probably some wxWidgets compile defines or build configuration. \u00a0What "configure" options did you use? I'm not sure __WXMAC__ is the right define. \u00a0It may be the Mac Classic support that's complicating wxString, and we only want OSX. \u00a0Try __WXOSX__ (or see below) http://docs.wxwidgets.org/stable/wx_cppconst.html "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: \u00a0\u00a0 \u00a0* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__. \u00a0\u00a0 \u00a0* If you want to test for any GUI Mac port under OS X, use __WXOSX__. \u00a0\u00a0 \u00a0* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__" BitcoinTalk Re: A few suggestions 2009-12-15 20:37:32 UTC -  -  Quote from: madhatter2 on December 15, 2009, 05:21:09 AM It is also throwing the same std::string issue on the latest version of Ubuntu Linux. Then it must be something you're doing differently with building or configuring wxWidgets. What options did you use on the wxWidgets "configure" script?\u00a0 The options I used are in build-unix.txt. Quote 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? Never heard of that happening.\u00a0 Is there anything in debug.log?\u00a0 If you touched the file, that sounds like something is there.\u00a0 Does the program have write access to the file? Martii Malmi (AKA Sirius) “COPA trial” email #129 Date: Wed, 16 Dec 2009 04:57:36 +0000 From: Satoshi Nakamoto Subject: Re: RC2 To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > The first time I tried it on Windows, the initial download took a few > minutes to start, even though it got many connections quickly. I tried > again twice, and didn't have the same problem again. I don't know > whether it's related to your latest update or not. Most of the fixes are on the sender's side, so if you were downloading the network upgrades to 0.2. How long did the initial download take? Martii Malmi (AKA Sirius) “COPA trial” email #131 Date: Wed, 16 Dec 2009 16:54:46 +0000 From: Satoshi Nakamoto Subject: Planned release announcement text To: Martti Malmi Here's the planned release announcement text. Probably releasing shortly. Bitcoin version 0.2 is here! Download links: Windows Setup Program Windows Zip File Linux (tested on Ubuntu) New features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download - Various refinements to keep the network running smoothly We also have a new forum at http://www.bitcoin.org/smf/ if you have any questions. Thanks to Martti Malmi (sirius-m) for his coding work and for hosting the new site and forum, and thanks to New Liberty Standard for testing the Linux version. Satoshi Nakamoto BitcoinTalk Bitcoin 0.2 released! 2009-12-16 22:45:36 UTC -  -  Bitcoin version 0.2 is here! Download links: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download New Features Martti Malmi  - Minimize to system tray option  - Autostart on boot option so you can keep it running in the background automatically  - New options dialog layout for future expansion  - Setup program for Windows  - Linux version (tested on Ubuntu) Satoshi Nakamoto  - Multi-processor support for coin generation  - Proxy support for use with TOR  - Fixed some slowdowns in the initial block download Major 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. Martii Malmi (AKA Sirius) “COPA trial” email #132 Date: Thu, 17 Dec 2009 06:49:02 +0000 From: Satoshi Nakamoto Subject: [bitcoin-list] Bitcoin 0.2 released To: bitcoin-list@lists.sourceforge.net Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto bitcoin-list [bitcoin-list] Bitcoin 0.2 released 2009-12-17 06:52:09 UTC -  -  Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the  background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to  New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto BitcoinTalk Re: A few suggestions 2009-12-17 18:38:06 UTC -  -  That's good, is it running fine on FreeBSD? I committed the changes to headers.h.\u00a0 For consistency, I used __BSD__.\u00a0 The complete list of defines is at http://docs.wxwidgets.org/stable/wx_cppconst.html #ifdef __BSD__ #include #endif malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble. BitcoinTalk Re: A few suggestions 2009-12-18 17:37:48 UTC -  -  What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized. \u00a0The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. \u00a0Note: 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. We 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. \u00a0I figured Linux people wouldn't mind doing that manually anyway. \u00a0I guess they need to know about the -min switch to do it right. You can locate the data directory where you want with the "-datadir=" switch. \u00a0I know someone is already doing that to put it on a TrueCrypt USB drive. Martii Malmi (AKA Sirius) “COPA trial” email #134 Date: Tue, 22 Dec 2009 19:00:41 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin stuff To: mmalmi@cc.hut.fi Thanks for creating the maintenance account, it would have been impossible to do all that without it. I'm really always going to need it. OK, I changed the password to a 20 character random password. That's a good domain. People rarely type domain names anymore, they use autocomplete or click links on search engines. I need to make a way for you to programmatically get new generated bitcoin addresses. Either that or you could have them send to your IP address, but then you have to rely on them to put the order number in the comment. When generating the new address, there can be an option to add an entry to the address book associated with the address, so the received transaction will be labelled. I kinda hid the labels after early users found them confusing, but it would be very helpful for this application. You have to widen up the comment column to see them. Are you going to manually review and enter orders, at least to begin with? I sure would. I'm thinking I should move the UI in the direction of having the user ask for their bitcoin address when they want one. "give me a bitcoin to receive a payment with". I suppose next to the send button, there would by a receive button, you press it and it says "here's a new address to use, here's the button to copy it to the clipboard, do you want to label it?" and maybe some explanation about why you shouldn't reuse addresses. Or maybe just a "New Address" button next to the address box that you should hit each time to change it. mmalmi@cc.hut.fi wrote: > I have registered the domain name bitcoinexchange.com and will start > coding the service sometime soon as a nice leisure activity. I'm > envisioning a simple Google-like interface with no registration and only > two texts fields on the front page, where you insert the amount of money > you wish to trade, and either your PayPal address to buy dollars or > bitcoin address to buy bitcoins. On the next page you'll get a new > bitcoin address for sending the coins or a check code for the PayPal > transaction text. > > PayPal is good for the beginning - it's simple and has no startup costs, > but later on I might accept credit cards also. > > Do you still need the maintenance account? It's ok if you do, but change > the password to something else. > Martii Malmi (AKA Sirius) “COPA trial” email #136 Date: Wed, 23 Dec 2009 17:53:18 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin stuff To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > I'd also need at least the command line tools to check if coins have > been received and to send coins. It would require some way to > communicate with the Bitcoin process running in the background. I don't > know how that should be done, maybe with something RPC related. > > It would also be great if the background process was non-graphical - the > VPS on the current service level doesn't have enough memory to run the X > Windowing environment, unless I come up with some ways to free memory. I had been wondering why everyone keeps harping on no-UI, when already you can run it with only a small icon on the tray, which is common for server services on Windows. So I guess this is why. I had chalked it up to unix snobbery if they couldn't abide a tiny little icon on a desktop they never see. Not opening any windows is easy, but it may fail because the gtk libraries aren't there. wxWidgets has __WXBASE__ for "Only wxBase, no GUI features". You could try building for that instead of __WXGTK__ and see what happens. It would be preferable if there's any way to do it as a command line switch on the same executable, rather than yet another build variation to release. How much memory do you have to work with? Bitcoin necessarily takes a fair bit of memory; about 75MB on Windows. Is that a problem? Command line control is one of the next things on the list. I want to design the API carefully. Receiving payments is the part that has a lot of design choices to be made. The caller needs to identify the transactions of interest, that's where the one-bitcoin-address-per-transaction model helps. Searching the comments text for an order number is another possibility. There's polled, asking what has been received to the given bitcoin address, and event driven. I guess in event driven, bitcoin would be told to run a command line when a certain amount is received to a certain bitcoin address. Martii Malmi (AKA Sirius) “COPA trial” email #138 Date: Fri, 25 Dec 2009 16:11:14 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin stuff To: mmalmi@cc.hut.fi You're right, I was looking at a test run with 250,000 blocks... duh. A normal one shows 17MB memory usage and 10MB VM size. mmalmi@cc.hut.fi wrote: >> How much memory do you have to work with? > The VPS has 320MB RAM, 50MB of which is currently free. There's also > 500MB swap space. > >> Bitcoin necessarily takes a >> fair bit of memory; about 75MB on Windows. Is that a problem? > > Sure about that? Windows task manager shows about 13MB memory usage here. > BitcoinTalk Re: Is my second Transaction working correctly? +Transfer Question 2010-01-05 20:00:46 UTC -  -  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.   Also, 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". Quote from: sirius-m on January 05, 2010, 01:20:06 AM Quote 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? 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. Would it be clearer if the status said "x confirmations", like: 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 confirmations 7 confirmations 8 confirmations Each block essentially means another node has confirmed that it agrees with all transactions up to that point. BitcoinTalk Re: 64bit support 2010-01-14 20:17:20 UTC -  -  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. You 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. BitcoinTalk Re: Number of connections? 2010-01-20 20:07:15 UTC -  -  Coins generate at the same speed with any number of connections >= 1. More 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. BitcoinTalk Re: TOR and I2P 2010-01-20 22:05:28 UTC -  -  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. There 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. BitcoinTalk Re: Bitcoin crash when sending coins 2010-01-27 21:52:27 UTC -  -  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. Now 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."  You 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. This 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. BitcoinTalk Re: A newb's test - anyone want to buy a picture for $1? 2010-01-28 01:01:48 UTC -  -  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. 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. Unfortunately, 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. BitcoinTalk Re: 64bit support 2010-01-29 00:42:49 UTC -  -  I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0. There 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. wxWidgets 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. I compiled and ran on 64-bit Ubuntu 9.10 Karmic. I 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. build-unix.txt is updated and two makefiles on SVN: makefile.unix.wx2.8 makefile.unix.wx2.9 Unfortunately 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. Martii Malmi (AKA Sirius) “COPA trial” email #143 Editor’s note: this email appears timestamped PRIOR to emails #141 and #142, however it was listed AFTER emails #141 and #142 in Martii Malmi’s COPA trial email documents. Date: Wed, 03 Feb 2010 20:25:53 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin API To: mmalmi@cc.hut.fi Is there any way to find out what the missing shared libraries are? It would help to know. It probably needs the gtk libraries, in which case you'll have the same problem with the 64-bit version. I would like to have a single executable that can also run on a UI-less system, but I'm not sure how on linux to link to things but still be able to run and not use them if the library is not present. Maybe we should statically link the GTK. Licensewise, it's LGPL, but since it's only used on unix, that would be OK. (we can't link LGPL stuff on windows because we provide the OpenSSL DLL, but on linux OpenSSL comes with the OS) My 64-bit (debug stripped) executable is attached. It includes untested changes that are not in SVN yet: UI changes and the wallet fSpent flag resync stuff. I've been researching options for interprocess calling. I want something that will be easy for a variety of server side languages to call, particularly PHP. Cross-platform to windows is a plus. I'm not sure if I want it to be something that can be accessed across the network. That would introduce security issues. If it can only be accessed on the local system, then local security authentication covers it, and it is incapable of being hacked remotely. At surface level, not looking into any details yet, the current front runners are: D-Bus: local system only used by qt, gnome and skype bindings: c, python, java, c++, php listed as "in progress" .net listed as unmaintained not sure how ready it is on windows XML-RPC: widely used, built in libraries on PHP it's more for web clients to talk to server, transport is http, so its a security question Is it possible to open a socket that can only be accessed locally? mmalmi@cc.hut.fi wrote: > Have you decided upon the inter-process calling method of the Bitcoin > API yet? An easy solution would be the socket interface provided by > wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The > Bitcoin program running a wxServer could be then accessed by calling the > bitcoin executable from the command line or by coding your own wxClient > app. > > Another option would be to just use the plain BSD sockets. > > Can you send me a 64-bit Linux binary of Bitcoin if you have one? I > tried compiling on the VPS, but it ran out of memory. Tried the 32-bit > version (with ia32-libs) also, but it didn't find the shared libraries. > BitcoinTalk Re: Bitcoin crash when sending coins 2010-02-03 23:29:57 UTC -  -  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. If 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). BitcoinTalk Re: Win32 CPU Cycles vs 'Live Protection' Engines ? 2010-02-03 23:36:54 UTC -  -  Thanks for that.  Which version of Windows? BitcoinTalk Re: Questions about Addresses 2010-02-04 00:07:07 UTC -  -  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. If 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. Someone should post their static IP so people can try out sending by IP and also give that user free money. There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address. If 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". BitcoinTalk Re: TOR and I2P 2010-02-04 00:30:50 UTC -  -  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. As 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. Since 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. Martii Malmi (AKA Sirius) “COPA trial” email #142 Editor’s note: this email appears timestamped PRIOR to email #141, however it was listed AFTER email #141 in Martii Malmi’s COPA trial email documents. Date: Thu, 04 Feb 2010 01:32:50 +0000 From: Satoshi Nakamoto Subject: Exchange options To: Martti Malmi Don't rush ahead and get yourself rejected from all the payment options before you've had time to see if there's a better approach. I suggest you wait before contacting any more payment processors. You may get ideas from things other users come up with and try. Just some random incomplete ideas: There may be a way to position it as an intermediate credit for micropayments for some virtual good or something. Or maybe if the payments are only in one direction. If you only buy bitcoins, then you're only sending money out not taking people's money, that would still be useful to peg the currency. That might be payment for computer time. Credit card is only one way. Don't even talk about the idea of returning money to customer's credit cards. Credit card companies hate that. In any case, any payment processor is going to expect you to be selling something real. Do you have electronic transfer or paper cheque in your country? (even if only within Europe) Martii Malmi (AKA Sirius) “COPA trial” email #141 Date: Thu, 04 Feb 2010 02:20:10 +0000 From: Satoshi Nakamoto Subject: Exchange ideas To: Martti Malmi You could always exchange for Liberty Reserve. It's an online currency similar to e-Bullion, Pecunix or Webmoney that allows exchanges no questions asked and with privacy. LR and the others are hard to buy but easy to cash out. Hard to buy because exchangers are very cautious about getting ripped off by reversed payments, so they require more details and holding time. Cashing out is very easy. LR is non-reversible, so there are oodles of exchanges eager to turn LR into any kind of payment. Bitcoin is the reverse, in that it's easy to get Bitcoins just by generating them. It would be easy for customers to go bitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they just want to save the money, then just bitcoin->LR. There's also the idea BTC2PSC had to sell paysafecards for bitcoins. Either online delivery by sending the card number by e-mail, or delivery of the unopened physical card in the mails. There are many variations of these cards. In some countries, they're called Gift Cards, and can be used wherever credit cards are accepted. I think they're used more by people who don't have the credit history to get a real credit card, so they buy gift cards themselves to pay for things that require a credit card. Martii Malmi (AKA Sirius) “COPA trial” email #145 Date: Thu, 04 Feb 2010 18:50:35 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin API To: mmalmi@cc.hut.fi I must have accidentally typed j instead of z. It's bz2 format. Rename to .tar.bz2 or just do tar -jxvf > The package doesn't open, it says "not in gzip format". > Martii Malmi (AKA Sirius) “COPA trial” email #146 Date: Thu, 04 Feb 2010 19:33:26 +0000 From: Satoshi Nakamoto Subject: UTF-8 to ANSI hack in CAboutDialog To: Martti Malmi What was the reason for this change? #if !wxUSE_UNICODE ... if (str.Find('Â') != wxNOT_FOUND) str.Remove(str.Find('Â'), 1); to: if (str.Find('�') != wxNOT_FOUND) str.Remove(str.Find('�'), 1); wxFormBuilder turns the (c) symbol into UTF-8 automatically. On wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash character, which this hack fixes up for the non-unicode (ansi) case. Martii Malmi (AKA Sirius) “COPA trial” email #147 Date: Thu, 04 Feb 2010 19:59:48 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin API To: mmalmi@cc.hut.fi Good, then no need to consider d-bus. Is there something like IPC sockets on Windows? I guess we could look how wx does it, or maybe the XML-RPC library will already know what to do. Windows has named pipes, maybe that's the best analogue. I don't think I want to invent my own RPC protocol, I want to use an existing standard. PHP, Java, Python or anything will be able to talk to the server directly the same way the command line commands do. I'm going to start reading on XML-RPC. It's coming up in searches as the most widely used protocol and widely supported. PHP includes it in its standard libraries. >> Is it possible to open a socket that can only be accessed locally? > > Yes, you can use IPC sockets ("Unix domain sockets") which are local > only. That's done in the wx-api by using a filename in place of a port > number. I committed an example of how the wxServer-Client communication > is used, you can revert if you want to. Now there's the -blockamount > command line option which asks the running instance for the block chain > length. > > I think this command line method could already be used from PHP, but it > might be lighter if php itself could call the socket server directly. > The wx's IPC overview mentions wxSocketEvent, wxSocketBase, > wxSocketClient and wxSocketServer as being "Classes for the low-level > TCP/IP API", which might be easier to use from php than what I used now > (wxServer, wxClient, wxConnection). I'll look more into it. > Martii Malmi (AKA Sirius) “COPA trial” email #148 Date: Fri, 05 Feb 2010 04:08:54 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoin API research status To: Martti Malmi I noticed this in the docs for wxSocketServer::Accept(bool wait = true): "If wait is true and there are no pending connections to be accepted, it will wait for the next incoming connection to arrive. **Warning: This will block the GUI." wxWidgets is pathologically single-threaded. Not only single-threaded, but must-be-the-GUI-thread-ed. Even for something as non-UI as wxStandardPaths I got nailed. All this is fine for UI code, since this is the same constraint placed by Windows anyway, but for UI-less server daemon code, wx calls are uncertain. Status of my research currently: For PHP, Python, etc to access the server, we need to use regular sockets. I think we can make it local-only by binding to localhost only, so it can only be accessed through the loopback. They say it's also watertight to simply check the IP of connections received and disconnect anything not 127.0.0.1. May as well do both. XML-RPC is a bit fat. There are 4 libraries for C++ but they're all big and hard to build, dependencies, license issues. Some posters complain all the C++ and PHP XML-RPC libraries are buggy. JSON-RPC is a simpler more elegant standard. It's simple enough I could use a generic JSON parser. PHP, Python and Java all have good implementations of JSON-RPC. I'm currently leaning towards JSON-RPC. Martii Malmi (AKA Sirius) “COPA trial” email #151 Date: Fri, 05 Feb 2010 18:29:12 +0000 From: Satoshi Nakamoto Subject: Re: Exchange options To: mmalmi@cc.hut.fi Maybe the current difficulty of buying LR is already the limit of how easy it can get in that direction. Every conventional payment method has refutability as their way to cope with their lack of passwords and crypto. The system is wide open to copying plaintext credit card numbers and account numbers, and they deal with it by reversing the transaction after the fact. The system works for physical goods that have to be delivered somewhere, and services which can't be resold. It's a problem when it interfaces with precious metals and currency conversion. The first step of being easy in one direction, bitcoin->LR or anything of established value, goes a long way. Even those who don't use the conversion still benefit from knowing that they could. Trading bitcoin becomes an easier way to trade the ability to claim LR, similar to how paper money was once the right to claim gold. Nobody has to ever actually claim the LR to get the benefit of having the option that they could if they wanted to. A lot of times you just need a minuscule amount of online currency. The hassle of buying the other online currencies is too much for buying a small amount. The ease of getting a small amount of bitcoin may help bootstrap an ecosystem of sellers of micropayment sized online goods selling to that market. If the sellers can get LR for bitcoins, they're happy, and that may be subsidized at first by investors who want to buy bc in large lots. The main thing holding online currencies back is the lack of an easy way to get a small amount of currency. Bitcoin opens that up. It'll be the only online currency that's both easy to cash out and easy to get a small amount. It'll just be the usual harder difficulty to buy a large amount. mmalmi@cc.hut.fi wrote: > Liberty Reserve sounds good. I could first make a service that only > accepts LR, and add more options later. The weakness is that buying LR > is an extra step of inconvenience when the customer just wants to get > Bitcoins. But maybe I don't have too much choice here. > >> Do you have electronic transfer or paper cheque in your country? (even >> if only within Europe) > > Yes, electronic bank transfer is available. During 2010 most European > countries will become a part of SEPA (Single Euro Payments Area), which > means that all payments within Europe are to be considered domestic. > Banks will have to apply the same fees and standards to all domestic > transfers, so they'll probably all be free of charge and complete in one > bank day. For international transfers there's the SWIFT/IBAN system, > which usually costs some extra. > > A longer term project for my exchange service would be to see what kinds > of integration options the banks have to offer. Bank transfers would > reach nearly as many customers as credit cards do. > Martii Malmi (AKA Sirius) “COPA trial” email #152 Date: Fri, 05 Feb 2010 18:39:18 +0000 From: Satoshi Nakamoto Subject: Re: UTF-8 to ANSI hack in CAboutDialog To: mmalmi@cc.hut.fi Right, I'll change it to this so it doesn't get broken again: if (str.Find('\xC2') != wxNOT_FOUND) str.Remove(str.Find('\xC2'), 1); mmalmi@cc.hut.fi wrote: > I didn't change it knowingly, must have been some encoding problem. > >> What was the reason for this change? >> >> #if !wxUSE_UNICODE >> ... >> if (str.Find('Â') != wxNOT_FOUND) >> str.Remove(str.Find('Â'), 1); >> to: >> if (str.Find('�') != wxNOT_FOUND) >> str.Remove(str.Find('�'), 1); >> >> wxFormBuilder turns the (c) symbol into UTF-8 automatically. On >> wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra >> trash character, which this hack fixes up for the non-unicode (ansi) >> case. > BitcoinTalk Proof-of-work difficulty increasing 2010-02-05 19:19:12 UTC -  -  We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.   The 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. The 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. The 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. For 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.  minimum    00000000ffff0000000000000000000000000000000000000000000000000000 30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000 11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000 25/01/2010 00000000be710000000000000000000000000000000000000000000000000000 04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000 14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000 08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000 21/03/2010 0000000038137500000000000000000000000000000000000000000000000000 01/04/2010 000000002a111500000000000000000000000000000000000000000000000000 12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000 21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000 04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000 19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000 29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000 11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000 24/06/2010 000000000d314200000000000000000000000000000000000000000000000000 06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000 13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000 16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000 27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000 05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000 15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000 26/08/2010 0000000000692000000000000000000000000000000000000000000000000000 date, difficulty factor, % change 2009           1.00 30/12/2009     1.18   +18% 11/01/2010     1.31   +11% 25/01/2010     1.34    +2% 04/02/2010     1.82   +36% 14/02/2010     2.53   +39% 24/02/2010     3.78   +49% 08/03/2010     4.53   +20% 21/03/2010     4.57    +9% 01/04/2010     6.09   +33% 12/04/2010     7.82   +28% 21/04/2010    11.46   +47% 04/05/2010    12.85   +12% 19/05/2010    11.85    -8% 29/05/2010    16.62   +40% 11/06/2010    17.38    +5% 24/06/2010    19.41   +12% 06/07/2010    23.50   +21% 13/07/2010    45.38   +93% 16/07/2010   181.54  +300% 27/07/2010   244.21   +35% 05/08/2010   352.17   +44% 15/08/2010   511.77   +45% 26/08/2010   623.39   +22% BitcoinTalk Re: Questions about Addresses 2010-02-05 19:44:46 UTC -  -  Quote from: Sabunir on February 05, 2010, 05:31:30 PM 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? That's not possible.  You've handed control of the money over to the recipient's keypair.  Only that key can control it. It's similar to if you encrypt a file with AES and a strong password, and you lose the password.  The data is lost. BitcoinTalk Re: Repost: Request: Make this anonymous? 2010-02-06 21:06:32 UTC -  -  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. If you send by IP, the recipient sees you because you connect to their IP.  You could use TOR to mask that. You could use TOR if you don't want anyone to know you're even using Bitcoin. Bitcoin is still very new and has not been independently analysed.  If you're serious about privacy, TOR is an advisable precaution. BitcoinTalk Re: How divisible are bitcoins and other market/economic questions 2010-02-06 23:25:53 UTC -  -  Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge. But 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. Martii Malmi (AKA Sirius) “COPA trial” email #153 Date: Sun, 07 Feb 2010 06:12:04 +0000 From: Satoshi Nakamoto Subject: JSON-RPC status To: Martti Malmi The JSON-RPC implementation is going well. I'm using boost::asio for sockets. JSON-RPC can be plain socket or HTTP, but it seems most other implementations are HTTP, so I made my own simple HTTP headers. For JSON parsing I'm using JSON Spirit, which makes full use of STL and has been really nice to use. It's header-only so it's no added build work, and small enough to just add it to our source tree. MIT license. This should all be working in a few more days. The forum sure is taking off. I didn't expect to have so much activity so fast. BitcoinTalk Re: Make your "we accept Bitcoin" logo 2010-02-08 01:22:29 UTC -  -  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. The best 16x16 with full alpha channel is in src/rc/bitcoin.ico.  I don't like the 32x32 version. I'm attaching bitcoin20x20.png, the 20x20 version with full transparency. BitcoinTalk Bitcoin client and website translation 2010-02-08 01:27:02 UTC -  -  Thank you for the offer to help translate.  That is probably the best way you could help. I 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.  What operating system are you using?  Windows, Linux 32-bit or 64 bit? Split from another thread. sirius-m Martii Malmi (AKA Sirius) “COPA trial” email #155 Date: Mon, 08 Feb 2010 15:28:52 +0000 From: Satoshi Nakamoto Subject: Translation To: Martti Malmi Does Drupal have any special multi-language support, or do you just create copies of pages by hand? BlueSky offered to do translation on the forum. If you create a www.bitcoin.org/zh/ copy of the site and give him an account with just the ability to create new pages and edit text, he'll probably translate the site into Chinese for you and maybe maintain it. BitcoinTalk Bitcoin client and website translation 2010-02-08 16:10:37 UTC -  -  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. wxWidgets 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. On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located. Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next. BitcoinTalk Re: Simple to implement feature requests 2010-02-08 16:37:24 UTC -  -  There are command line options: bitcoin -addnode=1.2.3.4    to tell bitcoin about a node to connect to bitcoin -connect=1.2.3.4    connect only to the specified node(s) You can use more than one of these, for instance bitcoin -connect=(first to try) -connect=(next to try) ... You 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. In 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: bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216 Martii Malmi (AKA Sirius) “COPA trial” email #158 Date: Thu, 11 Feb 2010 22:58:29 +0000 From: Satoshi Nakamoto Subject: Re: Translation To: mmalmi@cc.hut.fi I didn't make any changes to Drupal code. The only thing other than installing themes was the .htaccess file (which really is needed, it didn't work in the global config file). It was only SMF where I made some PHP changes. You might find it preferable not to translate it into your own language. Often the standard answer about legalities is that it's only intended for people in other countries. Translating it into your home language weakens that argument. mmalmi@cc.hut.fi wrote: > I got the translations working correctly, now it should automatically > detect the language from the browser settings. Choosing manually is of > course also possible. I asked the translators to send me their > translations as pm or e-mail. I guess I'll make a Finnish translation > myself at some point. Multiple translations add to the site's credibility. > > Drupal is asking to do a security update. Do we have other customized > files we need to backup than those located in the "sites" directory? > BitcoinTalk Re: DEB Package? 2010-02-12 02:33:02 UTC -  -  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". http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download I 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. Unfortunately 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. I know you said you didn't want VM, but as a last resort, last I checked the Windows version runs fine in Wine. BitcoinTalk Re: Repost: Request: Make this anonymous? 2010-02-12 17:28:32 UTC -  -  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. Best 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. Martii Malmi (AKA Sirius) “COPA trial” email #160 Date: Sat, 13 Feb 2010 01:08:42 +0000 From: Satoshi Nakamoto Subject: Re: JSON-RPC status To: mmalmi@cc.hut.fi I uploaded my JSON-RPC and command line implementation to SVN. I'm waiting to post on the forum when I've had more time to think about the commands. At least some method names are going to change. To enable the RPC server, add the switch -server. It's not on by default. Client commands are without any switches, as such: bitcoin getblockcount bitcoin getdifficulty bitcoin getnewaddress somelabel bitcoin sendtoaddress 1DvqsbZ... 1.00 bitcoin getallpayments 0 bitcoin stop Applications would normally use JSON-RPC directly, not command line. I haven't tested my JSON-RPC server with anything else yet. If you do, please tell me how it goes. You're using Python, right? Getting the Linux version to run without the GTK installed will be a separate task. mmalmi@cc.hut.fi wrote: > That's great! I'll start familiarizing myself with Liberty Reserve and > its api. > BitcoinTalk Re: DEB Package? 2010-02-13 01:38:37 UTC -  -  I couldn't get wxWidgets 2.8.9 to compile on Karmic 64-bit either. I 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)   -- fixed The 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. The SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010. Hopefully they'll have a wxWidgets 2.9.0 debian package someday. BitcoinTalk Re: What's with this odd generation? 2010-02-14 06:28:03 UTC -  -  Quote from: theymos on February 12, 2010, 08:31:52 AM Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)? Yes. Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?! 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. The average transaction, and anything up to 500 times bigger than average, is free. It'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. BitcoinTalk Re: What's with this odd generation? 2010-02-14 15:52:23 UTC -  -  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. Martii Malmi (AKA Sirius) “COPA trial” email #163 Date: Sun, 14 Feb 2010 21:48:31 +0000 From: Satoshi Nakamoto Subject: Re: JSON-RPC status To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: >> I haven't tested my JSON-RPC server with anything else yet. If you do, >> please tell me how it goes. You're using Python, right? >> >> Getting the Linux version to run without the GTK installed will be a >> separate task. > > Yes, using Python. I didn't test the JSON-RPC yet as I don't have > Bitcoin running on the vps yet. It doesn't work without a window manager > even if GTK libraries are installed. I asked about it at wxWidgets forum > (http://wxforum.shadonet.com/viewtopic.php?t=26954) but they didn't have > much clue. Maybe we'll just need to make two different binaries. I will probably relent and do that. I can move init and shutdown into init.cpp or start.cpp or something, link only wxbase and not link ui.o and uibase.o. wxWidgets is mostly Windows people, they wouldn't know much about GTK. Don't you have an Ubuntu laptop you can test and compile on so you don't have to toy with the vps? BitcoinTalk Re: Proof-of-work difficulty increasing 2010-02-15 06:28:38 UTC -  -  14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 2009        1.00 30/12/2009  1.18   +18% 11/01/2010  1.31   +11% 25/01/2010  1.34    +2% 04/02/2010  1.82   +36% 14/02/2010  2.53   +39% Another 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. Martii Malmi (AKA Sirius) “COPA trial” email #165 Date: Mon, 15 Feb 2010 18:11:53 +0000 From: Satoshi Nakamoto Subject: Re: JSON-RPC status To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: >> Don't you have an Ubuntu laptop you can test and compile on so you >> don't have to toy with the vps? > > Yes. Tested with Python's JSON-RPC, and seems to work fine! Really easy > to use. Hurray, I got it on the first go. Could you send me the Python code you used? So if I do some testing later I don't have to figure it out myself. BitcoinTalk Re: Setting up multiple bitcoin machines behind NAT 2010-02-16 01:34:56 UTC -  -  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) If you want, as a small optimization, you could run the rest of your computers as: bitcoin -connect= so 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. For 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: bitcoin -connect= -connect= BitcoinTalk Re: Proof-of-work difficulty increasing 2010-02-17 17:58:03 UTC -  -  Quote from: Sabunir on February 16, 2010, 08:51:51 AM . Perhaps it has to do with my connection's very high latency (2000ms or more on average)  2 seconds of latency in both directions should reduce your generation success by less than 1%. Quote from: Sabunir on February 16, 2010, 08:51:51 AM and/or my high packet loss (sometimes up to 10% loss)? 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. BitcoinTalk Re: Bitcoin client and website translation 2010-02-17 19:19:43 UTC -  -  I updated the SVN with changes to support translation.  Translatable strings are all enclosed in _(""), and we're using UTF-8 on all platforms. When the program runs, it looks in the directory of the EXE for the file: locale\\LC_MESSAGESitcoin.mo is the two letter code of the language your OS is set to, like "de" or "nl". On Linux, it also looks for: /usr/share/locale//LC_MESSAGES/bitcoin.mo /usr/local/share/locale//LC_MESSAGES/bitcoin.mo (are there other standard places it should look on linux?) Here's a quick walkthrough using poedit to make a .po and .mo file: - Download the bitcoin sourcecode from SVN - In the trunk directory, mkdir locale\\LC_MESSAGES - In poedit, File->New catalog->Paths tab - Click the "New item" dotted rectangle button - Put "../../.." and MAKE SURE TO PRESS ENTER to add the path - Click OK - Save the file as "bitcoin.po" in the LC_MESSAGES directory you made - It should then scan the sourcecode and find about 170 strings - If it didn't find anything, check Catalog->Settings->Path tab, make sure the "../../.." was added When you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program). BitcoinTalk Re: Number of connections 2010-02-21 03:43:48 UTC -  -  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. I don't know if there's any reason to have 15 connections.  Maybe it should be 10. Since 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. The 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). Block 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. BitcoinTalk Post your static IP 2010-02-21 04:19:53 UTC -  -  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! Anything sent to these IPs should be considered a donation.   If 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. BitcoinTalk Re: Current Bitcoin economic model is unsustainable 2010-02-21 05:44:24 UTC -  -  Excellent analysis, xc. 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. In 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. In 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. At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production. BitcoinTalk UI improvements 2010-02-21 21:48:01 UTC -  -  Uploaded some UI changes to SVN as version 0.2.5. Instead of View->Show Generated, we now have tabs: - All Transactions - Sent/Received - Sent - Received Makes it a lot easier to flip to received and check for payments. Moved the "Your Addresses" book inside the main address book.  It was confusing having two address books. I 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. Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0. I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing. Martii Malmi (AKA Sirius) “COPA trial” email #168 Date: Mon, 22 Feb 2010 20:17:42 +0000 From: Satoshi Nakamoto Subject: Re: Non-GUI option To: mmalmi@cc.hut.fi mmalmi@cc.hut.fi wrote: > Just a few clues I've found about running the same binary without a GUI: > > 1) GTK supports running a program without display: > http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check. > This doesn't tell if it's possible in wxWidgets though. I see it calls gtk-init-check in wxApp::Initialize. I can subclass Initialize, call the original one while suppressing the error message and ignore the return value. It seems to be working. Any suggestions what to name the command line switches and how to describe them? Is there any traditional standard? I'm currently using: -daemon (or -d) (Enables RPC and runs in the background) -server (Enables RPC) BitcoinTalk Re: generation slowed down dramatically 2010-02-23 00:49:56 UTC -  -  Just a random streak of bad luck.  It looks steady to me. Competition doesn't have an effect until the next automatic retarget adjustment, and we haven't reached the next one yet. The 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.   My 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. BitcoinTalk Re: UI improvements 2010-02-23 01:16:28 UTC -  -  There are now "Sending" and "Receiving" tabs in the Address Book.  Your addresses are referred to as "receiving addresses". madhatter 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. I think he had it working on FreeBSD, but he wanted a non-UI version. I have the command line and JSON-RPC daemon version working now.  Will SVN it in a day or two. I 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. Martii Malmi (AKA Sirius) “COPA trial” email #169 Date: Tue, 23 Feb 2010 01:41:01 +0000 From: Satoshi Nakamoto Subject: Re: Non-GUI option To: Martti Malmi >> Just a few clues I've found about running the same binary without a GUI: >> >> 1) GTK supports running a program without display: >> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check. >> This doesn't tell if it's possible in wxWidgets though. > > I see it calls gtk-init-check in wxApp::Initialize. > > I can subclass Initialize, call the original one while suppressing the > error message and ignore the return value. It seems to be working. This is working. A few more things and I'll upload it. We'll need to tell people to install the GTK libraries. Do you remember the apt-get command to install GTK, and can you install it without having a GUI installed? BitcoinTalk Re: Bitcoin Address Collisions 2010-02-23 16:26:09 UTC -  -  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. If there was a collision, the collider could spend any money sent to that address.  Just money sent to that address, not the whole wallet. If 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. The 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. BitcoinTalk Re: UI improvements 2010-02-23 16:53:27 UTC -  -  Quote from: Xunie on February 23, 2010, 12:28:27 PM /etc/init.d/gdm start and it will start gdm! Ah yes, there we go, back to normal again. The ctrl+alt+F[1-8] thing never worked on this computer.  The screen just goes haywire. BitcoinTalk Command Line and JSON-RPC 2010-02-23 22:15:41 UTC -  -  Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC. On 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. The command to start as a daemon is: bitcoin -daemon [switches...] Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the "-server" switch. bitcoin -server [switches...] With 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. To control it from the command line, the interface is a command name without any switches, followed by parameters if any. bitcoin [params...] For example: bitcoin getinfo bitcoin getdifficulty bitcoin setgenerate true bitcoin stop It's a simple JSON-RPC client and prints the JSON result.  Look at rpc.cpp for the list of commands. Web 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. BitcoinTalk Re: Bitcoin Address Collisions 2010-02-23 22:24:00 UTC -  -  Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window? No, each generated transaction uses a new, single-use address. Nothing 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. BitcoinTalk Re: URI-scheme for bitcoin 2010-02-24 05:57:43 UTC -  -  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. BitcoinTalk Re: Command Line and JSON-RPC 2010-02-24 06:17:23 UTC -  -  Quote from: theymos on February 24, 2010, 03:07:37 AM Quote from: satoshi on February 23, 2010, 10:15:41 PM On Linux it needs libgtk2.0-0 installed Will this requirement be removed sometime? I'd rather not have to deal with GTK. 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.   It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK. Martii Malmi (AKA Sirius) “COPA trial” email #172 Date: Wed, 24 Feb 2010 06:34:52 +0000 From: Satoshi Nakamoto Subject: Re: Non-GUI option To: mmalmi@cc.hut.fi > I'll give Drupal accounts to the bitcoin.org translators, so they can > keep the translations up to date. Good, that gives them a little sense of ownership and responsibility. I hope we get at least one .mo file for the software translation in time to put into the 0.3 release. BitcoinTalk New icon/logo 2010-02-24 21:24:23 UTC -  -  New icons, what do you think?  Better than the old one?        Full size 530x529 image for scaling down to custom sizes: http://www.bitcoin.org/download/bitcoin530.png The perspective shadow was too thick on the larger sizes.  I updated 32, 48 and the full size. I release these images into the public domain (copyright-free).  I request that derivative works be made public domain. BitcoinTalk Re: Make your "we accept Bitcoin" logo 2010-02-24 21:53:52 UTC -  -  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. BitcoinTalk Re: Command Line and JSON-RPC 2010-02-24 22:08:55 UTC -  -  When and how fast did memory usage increase?  Right away, slowly over a long time, or starting at some later event? I have -daemon running on ubuntu 9.10 64-bit and memory usage is steady. It 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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-02-24 22:42:24 UTC -  -  The automatic adjustment happened earlier today. 24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000 24/02/2010  3.78  +49% I updated the first post. BitcoinTalk Re: New icon/logo 2010-02-25 01:56:24 UTC -  -  Quote from: Sabunir on February 25, 2010, 01:47:56 AM I like them. Do they come in higher resolutions? Yes, the original is 546x531 pixels. It 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. BitcoinTalk Re: Command Line and JSON-RPC 2010-02-25 22:54:17 UTC -  -  OK, I made a build target bitcoind that only links wxBase and does not link GTK.  Version 0.2.7 on SVN. I 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. Quote from: sirius-m on February 25, 2010, 04:32:17 PM It started increasing right away. I'll see if valgrind can help me. 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. Another 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. I suspect bitcoind will probably work fine, but I hope you can still debug the problem. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-02-25 23:06:29 UTC -  -  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.  I don't know what you're talking about accepting easier difficulties. BitcoinTalk Re: Command Line and JSON-RPC 2010-02-26 16:29:21 UTC -  -  wx/clipbrd.h isn't used, move it inside the #if wxUSE_GUI. Updated headers.h on SVN. Sorry, I linked to wxbase but I had full wxWidgets on my computer. The 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? Db::exists() http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html I suppose they might have added exists recently, using get before that. BitcoinTalk Re: New icon/logo 2010-02-26 23:17:19 UTC -  -  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. It'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. It's slightly wider than tall because the dark perspective under it goes more to the right than down. I finished and posted the 32x31 and 48x47 versions in the first message.  I like the 48 a lot. How does everyone feel about the B symbol with the two lines through the outside?  Can we live with that as our logo? BitcoinTalk Re: Command Line and JSON-RPC 2010-02-26 23:48:44 UTC -  -  Are you using wxWidgets 2.9.0?  I don't recommend using anything other than 2.9.0. It looks like they've got a reference in the wx headers (arrstr.h) to something outside of wxBase. Removing -D__WXDEBUG__ from bitcoin's makefile would probably solve it. If 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. BitcoinTalk Re: New icon/logo 2010-02-27 04:28:29 UTC -  -  Quote from: Cdecker on February 27, 2010, 03:24:07 AM How about an SVG version? That way we could automatically generate smaller and larger versions as needed. 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. I 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. BitcoinTalk Re: wxWidgets 2.9.0 2010-02-27 21:22:53 UTC -  -  Quote from: Cdecker on February 27, 2010, 05:09:59 PM Looking through the source of 2.8.10 it appears that unicode is possible with that version too. In the Windows world, "unicode" means UTF-16 (wchar). 2.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. 2.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. Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given. Curious, why is it incredibly hard to provide wxWidgets 2.9.0?  If you mean for users, that's why we static link it. It'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. Martii Malmi (AKA Sirius) “COPA trial” email #174 Date: Sun, 28 Feb 2010 14:47:01 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi I put it at bitcoin.org/download/linux64-0.2.7.1.tar.gz. You can delete it when you've got it. I thought about what might cause the problem you're having and made a change that this build includes. This might have been unsafe code, although it would probably always get lucky. in util.cpp, old: const char* wxGetTranslation(const char* pszEnglish) { // Wrapper of wxGetTranslation returning the same const char* type as was passed in static CCriticalSection cs; CRITICAL_BLOCK(cs) { // Look in cache static map mapCache; map::iterator mi = mapCache.find(pszEnglish); if (mi != mapCache.end()) return (*mi).second; // wxWidgets translation const char* pszTranslated = wxGetTranslation(wxString(pszEnglish, wxConvUTF8)).utf8_str(); // We don't cache unknown strings because caller might be passing in a // dynamic string and we would keep allocating memory for each variation. if (strcmp(pszEnglish, pszTranslated) == 0) return pszEnglish; // Add to cache, memory doesn't need to be freed. We only cache because // we must pass back a pointer to permanently allocated memory. char* pszCached = new char[strlen(pszTranslated)+1]; strcpy(pszCached, pszTranslated); mapCache[pszEnglish] = pszCached; return pszCached; } return NULL; } new: const char* wxGetTranslation(const char* pszEnglish) { // Wrapper of wxGetTranslation returning the same const char* type as was passed in static CCriticalSection cs; CRITICAL_BLOCK(cs) { // Look in cache static map mapCache; map::iterator mi = mapCache.find(pszEnglish); if (mi != mapCache.end()) return (*mi).second; // wxWidgets translation wxString strTranslated = wxGetTranslation(wxString(pszEnglish, wxConvUTF8)); // We don't cache unknown strings because caller might be passing in a // dynamic string and we would keep allocating memory for each variation. if (strcmp(pszEnglish, strTranslated.utf8_str()) == 0) return pszEnglish; // Add to cache, memory doesn't need to be freed. We only cache because // we must pass back a pointer to permanently allocated memory. char* pszCached = new char[strlen(strTranslated.utf8_str())+1]; strcpy(pszCached, strTranslated.utf8_str()); mapCache[pszEnglish] = pszCached; return pszCached; } return NULL; } If you still suspect this code, for testing you could change it to: const char* wxGetTranslation(const char* pszEnglish) { return pszEnglish; } mmalmi@cc.hut.fi wrote: > I tried debugging my build of bitcoind with ddd debugger, but didn't > have much success yet. It always ends up taking all the system's memory > and finally crashes. Could you please send me again the latest 64 bit > build of bitcoind, so I can see if the problem is about my build? > Martii Malmi (AKA Sirius) “COPA trial” email #175 Date: Sun, 28 Feb 2010 20:09:07 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi Could you send me the debug.log? mmalmi@cc.hut.fi wrote: > I tried debugging my build of bitcoind with ddd debugger, but didn't > have much success yet. It always ends up taking all the system's memory > and finally crashes. Could you please send me again the latest 64 bit > build of bitcoind, so I can see if the problem is about my build? > BitcoinTalk Re: New icon/logo 2010-03-02 02:33:05 UTC -  -  We have the standard icon sizes, and the full size scales nicely to anything else. I added the full size to the first post. Martii Malmi (AKA Sirius) “COPA trial” email #178 Date: Tue, 02 Mar 2010 22:27:22 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi Does it still do it if you didn't do getinfo? You could comment out the CreateThreads listed below, then re-enable them one at a time until it does it again. Then we would know which thread the problem is in. net.cpp, under // Start threads CreateThread(ThreadIRCSeed, NULL) CreateThread(ThreadSocketHandler, NULL, true) CreateThread(ThreadOpenConnections, NULL) CreateThread(ThreadMessageHandler, NULL) init.cpp: CreateThread(ThreadRPCServer, NULL); mmalmi@cc.hut.fi wrote: > Here goes. I forgot to mention the crash error message: > > terminate called after throwing an instance of 'std::bad_alloc' > what(): std::bad_alloc > Martii Malmi (AKA Sirius) “COPA trial” email #180 Date: Wed, 03 Mar 2010 03:54:52 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi That narrows it down a lot. It didn't print any IRC activity in debug.log, so I guess it couldn't have gotten past the RecvUntil. Eyeballing it I don't see anything obvious. I guess it would have to be either in ConnectSocket or RecvUntil. Try it with the attached irc.cpp and net.cpp and send me the debug.log. Or you could run it in gdb and step through ThreadIRCSeed gdb --args bitcoin [switches] b ThreadIRCSeed run step or u to step over and up out of routines. mmalmi@cc.hut.fi wrote: > I get the error regardless of the getinfo. Commenting out ThreadIRCSeed > fixed the problem. > BitcoinTalk Re: Money Transfer Regulations 2010-03-03 04:28:56 UTC -  -  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. To 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. This 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. Martii Malmi (AKA Sirius) “COPA trial” email #182 Date: Wed, 03 Mar 2010 17:15:28 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi It's in RecvUntil, but I still can't see anything wrong with it. The only thing I can think of is if the socket is receiving a spew of characters. Try this irc.cpp. debug.log may grow rapidly so be ready to kill it. mmalmi@cc.hut.fi wrote: > debug.log attached > Martii Malmi (AKA Sirius) “COPA trial” email #185 Date: Fri, 05 Mar 2010 00:42:16 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi It's in util.c ParseString. I'm guessing the problem is incompatibility between the type "unsigned int" and the type of str.npos, which is size_type. Try changing the two "unsigned int"s to "size_type". old: void ParseString(const string& str, char c, vector& v) { unsigned int i1 = 0; unsigned int i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); } new: void ParseString(const string& str, char c, vector& v) { size_type i1 = 0; size_type i2; do { i2 = str.find(c, i1); v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } while (i2 != str.npos); } mmalmi@cc.hut.fi wrote: > Here's another test run debug.log I got when debugging with gdb. The > program started eating memory after the debug line "irc 8" and within a > few seconds crashed with "terminate called after throwing an instance of > 'std::bad_alloc'". > Martii Malmi (AKA Sirius) “COPA trial” email #186 Date: Fri, 05 Mar 2010 00:54:40 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi Actually, please try this instead, this is more correct: void ParseString(const string& str, char c, vector& v) { string::size_type i1 = 0; string::size_type i2; loop { i2 = str.find(c, i1); if (i2 == str.npos) { v.push_back(str.substr(i1)); return; } v.push_back(str.substr(i1, i2-i1)); i1 = i2+1; } } Martii Malmi (AKA Sirius) “COPA trial” email #188 Date: Fri, 05 Mar 2010 01:42:00 +0000 From: Satoshi Nakamoto Subject: Re: Bitcoind To: mmalmi@cc.hut.fi I confirmed that ParseString has this problem, and uploaded the fixed util.cpp to SVN. string::npos == -1 Comparing unsigned int -1 (0xffffffff) with long unsigned int -1 (0xffffffffffffffff) results in the unsigned int being promoted to 64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff. mmalmi@cc.hut.fi wrote: > Here's another test run debug.log I got when debugging with gdb. The > program started eating memory after the debug line "irc 8" and within a > few seconds crashed with "terminate called after throwing an instance of > 'std::bad_alloc'". > BitcoinTalk Re: Command Line and JSON-RPC 2010-03-05 01:46:25 UTC -  -  Quote from: sirius-m on February 24, 2010, 06:17:35 PM 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. sirius-m debugged this, it was 64-bit related.   The fix is now available on SVN, file util.cpp. Martii Malmi (AKA Sirius) “COPA trial” email #189 Date: Sat, 06 Mar 2010 06:39:53 +0000 From: Satoshi Nakamoto Subject: Blog To: Martti Malmi There's a blog writer who wants to write a story about Bitcoin, but I don't have time right now to answer his questions. Would you be interested in answering his questions if I refer him to you? We might get a good link out of it. The blog is http://themonetaryfuture.blogspot.com BitcoinTalk Re: bitcoin auto-renice-ing 2010-03-15 18:44:12 UTC -  -  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. #define THREAD_PRIORITY_LOWEST          PRIO_MIN #define THREAD_PRIORITY_BELOW_NORMAL    2 #define THREAD_PRIORITY_NORMAL          0 The priorities converted from Windows priorities were probably from a table like this:    "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. nice value    Win32 Priority -20 to -16    THREAD_PRIORITY_HIGHEST -15 to -6    THREAD_PRIORITY_ABOVE_NORMAL -5 to +4    THREAD_PRIORITY_NORMAL +5 to +14    THREAD_PRIORITY_BELOW_NORMAL +15 to +19    THREAD_PRIORITY_LOWEST" If you have better values, suggestions welcome. Also, 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.     // threads are processes on linux, so PRIO_PROCESS affects just the one thread     setpriority(PRIO_PROCESS, getpid(), nPriority); BitcoinTalk Idea for file hosting and proxy services 2010-03-15 19:16:56 UTC -  -  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. It'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. It 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. Services like this would be great for anonymous users, who have trouble paying for things. BitcoinTalk Re: On IRC bootstrapping 2010-03-16 19:48:47 UTC -  -  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. We 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. Bitcoin can get the list of IPs from any bitcoin node.  In that sense, every node serves as a directory server. When 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. How 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? BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC?  IRC is a good directory server (I've heard it has other uses too), and there are mature IRC server implementations available that anyone can run.   Bitcoin's IRC client implementation is already thoroughly tested. BitcoinTalk Re: Idea for file hosting service 2010-03-16 20:17:34 UTC -  -  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. Would 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. I 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? BitcoinTalk Re: who is bitcoin.com 2010-03-23 15:22:41 UTC -  -  It's unrelated.  There wasn't anything there when I started. 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. BitcoinTalk Re: Exchange Methods 2010-03-23 17:35:34 UTC -  -  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. Bitcoin 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. Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it. BitcoinTalk Re: Idea for file hosting and proxy services 2010-03-24 18:01:57 UTC -  -  Title changed. It 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) BitcoinTalk Re: Idea for file hosting and proxy services 2010-03-24 18:02:55 UTC -  -  Mihalism Multi Host is a popular open source PHP file hosting server. It'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. It doesn't have a bunch of client side scripting or anti-embedding junk to rip out.  It generates standard links that work normally. There'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. An example of a site running the software: http://www.imagez.ws/ Forum: http://www.mihalism.net/ Download: http://code.google.com/p/mihalismmh/ What 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. Martii Malmi (AKA Sirius) “COPA trial” email #192 Date: Sun, 16 May 2010 20:12:21 +0100 From: Satoshi Nakamoto Subject: Re: Status update To: mmalmi@cc.hut.fi I've also been busy with other things for the last month and a half. I just now downloaded my e-mail since the beginning of April. I mostly have things sorted and should be back to Bitcoin shortly. Glad that you've been handling things in my absence. Congrats on your first transaction! As I recall, the code was nearly ready for a 0.3 release. I think all it needed was a little testing time and to install the new icon xpm. The JSON API functions are complete. I wanted to take another fresh look at them in case I think of any better function names before committing. I ought to write some sample code showing the proper way to use them, particularly with polling for received transactions. When I left off, I was thinking about bolting a payment mechanism onto a free upload server software as an example. It would make sense to actually build one practical application with the API before releasing it. You don't realise the problems with an API until you actually try to use it. mmalmi@cc.hut.fi wrote: > Hi! > > How are you doing? Haven't seen you around in a while. > > I've been at full-time work lately, and will be until the end of June, > so I haven't had that much time to work with Bitcoin or my exchange > service. I have a working beta of my service though, and a few weeks ago > made my first transaction: sold 10,000 btc for 20 euros via EU bank > transfer. Maybe I can make it public soon. > > I divided the forum into 6 boards, which are Bitcoin Discussion, > Development & Technical Discussion, Technical support, Economics, > Marketplace and Trading Discussion. Hope this is ok? > > I also added a page "Trade" on the bitcoin.org site, where btc-accepting > services are listed. It's nice to see that there are already useful > services that accept btc. > > The community has been growing nicely. We've had around 10-20 people and > active discussion at #bitcoin-dev lately. > > It would be nice to get the daemon-able binaries to SF.net. We have some > skilled programmers in the community now, so maybe we can finish the > JSON API functions if you don't have time to. > > Best regards. > BitcoinTalk Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add 2010-05-16 21:01:44 UTC -  -  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. BitcoinTalk Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? 2010-05-16 21:37:36 UTC -  -  Quote from: Xunie on May 14, 2010, 09:52:53 PM I suggest we disable IP transactions while the user uses a Proxy! Just to be on the safe side. 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. BitcoinTalk Re: Exception: 9key_error error 2010-05-16 22:53:59 UTC -  -  Does it happen every time you run it, or just happened once at some random time? I'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. The code is: key.h:     EC_KEY* pkey;         pkey = EC_KEY_new_by_curve_name(NID_secp256k1);         if (pkey == NULL)             throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name failed"); NID_secp256k1 is a constant. BitcoinTalk Re: removing bitcoin addresses 2010-05-16 23:34:40 UTC -  -  SheriffWoody: 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. sirius-m: Thousands 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. It 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:     // Keep giving the same key to the same ip until they use it     if (!mapReuseKey.count(pfrom->addr.ip))         mapReuseKey[pfrom->addr.ip] = GenerateNewKey();          ...sends the key mapReuseKey[pfrom->addr.ip] ...later...     // Received something with this key     mapReuseKey.erase(pfrom->addr.ip); If it's not convenient to know when you've received, just clear the cached keys every 20 minutes. I want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address. BitcoinTalk Re: Setting up multiple bitcoin machines behind NAT 2010-05-16 23:56:03 UTC -  -  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. I'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. If you have many computers, then using the -connect switch on most of them to connect locally makes more sense. BitcoinTalk Re: Is there a way to automate bitcoin payments for a website? 2010-05-18 02:58:11 UTC -  -  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: Quote obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const': /usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler' obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const': /usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)' 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. bitcoind runs as a daemon and can either be controlled by command line or JSON-RPC. Thanks madhatter and generica for detailing the instructions for building on freebsd. BitcoinTalk Re: Ummmm... where did my bitcoins go? 2010-05-18 20:06:46 UTC -  -  It's not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time. How long is the initial block download typically taking?  Does it slow down half way through or is about the same speed the whole way? I'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. 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. SPV is not implemented yet, and won't be implemented until far in the future, but all the current implementation is designed around supporting it. In the meantime, sites like vekja.net and www.mybitcoin.com have been experimenting with account-based sites.  You create an account on a website and hold your bitcoins on account there and transfer in and out.  Creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people.  The only disadvantage is that you have to trust the site, but that's fine for pocket change amounts for micropayments and misc expenses.  It's an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software. BitcoinTalk Re: We accept Bitcoins 2010-05-20 21:43:42 UTC -  -  Quote from: DataWraith on May 19, 2010, 07:52:42 PM 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. 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. BitcoinTalk JSON-RPC programming tips using labels 2010-05-26 18:27:25 UTC -  -  I added label related functions to help with managing multiple addresses per user.  New or renamed functions are:  getreceivedbyaddress -- amount received on a single address  getreceivedbylabel -- amount received by all addresses with this label  listreceivedbyaddress -- list addresses and amounts they've received  listreceivedbylabel -- list labels and amounts they've received  setlabel -- misc label functions for completeness  getlabel  getaddressesbylabel For 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. The 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. A 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: // Get a new address whenever the current one has received anything if (strAddr == "" || getreceivedbyaddress(strAddr) > 0)    strAddr = getnewaddress(strUsername); // Label the address with username Display(strAddr); // Display their current receiving address // Get total received by all the user's addresses getreceivedbylabel(strUsername, 0) // unconfirmed getreceivedbylabel(strUsername, 1) // available balance If 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). You 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. If 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. It's mostly only if you were selling gold or currency that you'd need multiple confirmations. BitcoinTalk Re: Tracing a coin's lineage 2010-05-26 18:51:04 UTC -  -  Quote from: Xunie on May 26, 2010, 12:50:04 AM Can't we force a user to use a new address for receiving payments? Every 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?) The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address. This is on my list.  I will soon make the "Your Bitcoin Address:" window automatically change whenever you receive anything to the address displayed. I'm also recommending this approach for the implementation of web apps.  I just posted some sample code showing a suggested way of implementing this. Versions on SVN since 0.2.4 already have a "New..." button next to the address bar to encourage changing it manually too. @theymos: If nothing else, we can fall back on that solution in the future. BitcoinTalk Re: CLI bitcoin generation 2010-05-26 20:09:34 UTC -  -  Quote from: molybdenum on May 22, 2010, 06:44:20 PM 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)? 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. listreceivedbyaddress [minconf=1] [includeempty=false] [minconf] is the minimum number of confirmations before payments are included. [includeempty] whether to include addresses that haven't received any payments. Returns an array of objects containing:   "address" : receiving address   "label" : the label of the receiving address   "amount" : total amount received by the address   "confirmations" : number of confirmations of the most recent transaction included or listreceivedbylabel if you're labelling addresses with their username. So far I've concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet. BitcoinTalk Re: Share database blocks ? 2010-05-26 20:34:34 UTC -  -  It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks. The 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. How long is the initial block download taking for you? BitcoinTalk Re: Website translations 2010-05-26 21:16:34 UTC -  -  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. All you have to do is get poedit and translate the po file I'm attaching to this post.  It's less than 750 words. Updated bitcoin.po attachment for 0.3.1 BitcoinTalk Re: Odd amount of generated coins 2010-05-26 21:34:32 UTC -  -  In the SVN version, if a transaction requires a transaction fee, it says "This transaction is over the size limit.  You can still send it for a fee of #, which goes to the nodes that process your transaction and helps to support the network. Do you want to pay the fee?" If you don't have enough money with the fee added, it says "Total exceeds your balance when the # transaction fee is included  " BitcoinTalk Re: Website translations 2010-05-27 14:18:22 UTC -  -  Hurray!  We have our first language.  I uploaded it to SVN to go in with the 0.3 release. BitcoinTalk Re: Hostnames instead of IP Addresses 2010-06-02 18:18:15 UTC -  -  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. The future plan for sending to an IP is to make it a bitcoin address plus IP, like: 1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h1.2.3.4 or 1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4hdomain.com I 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. I 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. Since 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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-06-02 18:45:38 UTC -  -  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. Every node and each processor has a different public key in its block, so they're guaranteed to be scanning different territory. Whenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer. BitcoinTalk Re: Website translations 2010-06-02 22:18:09 UTC -  -  I uploaded the 93% complete Dutch translation to SVN.  Thanks! BitcoinTalk Re: On IRC bootstrapping 2010-06-14 18:13:21 UTC -  -  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. What do you think, should I go ahead with adding the seeds? It'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. Is there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us? BitcoinTalk Re: Hostnames instead of IP Addresses 2010-06-14 19:53:44 UTC -  -  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. Instead 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. The user would send to domain.com (or www.domain.com is ok too).  That would be very natural and users could see and verify that what they entered is who they intend to pay. The SSL also makes it safe for TOR users. Problem 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.  Just 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. The 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. BitcoinTalk Re: Dealing with SHA-256 Collisions 2010-06-14 20:39:50 UTC -  -  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. If 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. BitcoinTalk Re: Technical clarifications 2010-06-14 22:21:55 UTC -  -  3) Nothing, if sending by bitcoin address 5) It is decentralised.  After you have connected to the network the first time, you no longer need IRC. BitcoinTalk Re: Can't Build r80 from SVN 2010-06-14 22:40:14 UTC -  -  Sorry, I didn't test compile on linux the last few revisions. Reverted makefile.unix. BitcoinTalk Re: What is the incentive to collect transactions? 2010-06-15 23:41:29 UTC -  -  Quote from: theymos on June 05, 2010, 04:26:09 PM Adding transactions to the block you're working on will slow down your generation rate 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. If 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. BitcoinTalk Re: URI-scheme for bitcoin 2010-06-16 00:15:47 UTC -  -  http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345 or http://127.0.0.1:8330/?to=1.2.3.4&amount=200.00 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. What would be nice about sending by domain is you could visually verify who it's going to. A more crucial issue is what if the browser isn't allowed to connect to 127.0.0.1: http://BitcoinTalk.org/index.php?topic=63.msg1589#msg1589 and if that's true, then what about that example freenet link that had 127.0.0.1 in it? BitcoinTalk Re: Website translations 2010-06-16 16:53:34 UTC -  -  Thanks DataWraith!  The German translation is uploaded to SVN. This is great, we've already got 3 major languages. BitcoinTalk Re: new binary release? 2010-06-17 17:07:56 UTC -  -  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!). BitcoinTalk Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG 2010-06-17 18:46:08 UTC -  -  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 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. The 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. 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. 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. BitcoinTalk Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG 2010-06-18 16:17:14 UTC -  -  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. I know, most developers don't like their software forked, but I have real technical reasons in this case. Quote from: gavinandresen on June 17, 2010, 07:58:14 PM 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. That'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... That's one of the reasons for transaction fees.  There are other things we can do if necessary. Quote from: laszlo on June 17, 2010, 06:50:31 PM 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  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. Fortunately, so far all the issues raised have been things I previously considered and planned for. BitcoinTalk Re: On IRC bootstrapping 2010-06-18 17:28:18 UTC -  -  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. This means TOR users won't need to -addnode anymore, it'll get connected automatically.   BitcoinTalk Re: Get 5 free bitcoins from freebitcoins.appspot.com 2010-06-18 23:08:34 UTC -  -  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. You 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. BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-21 17:20:21 UTC -  -  Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM 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. This is now fixed in the SVN version. 1) Menu bar default color. 2) Balance bar not a different color. 3) Background behind bitcoin address and balance now the same color as toolbar. I checked all the standard themes and it seems reasonable with all of them. Ubuntu minimize,maximize,close buttons to the right: gconf-editor apps->metacity->general button_layout=menu:minimize,maximize,close They've got it awfully buried considering 9 out of 10 users are used to having it on the right. BitcoinTalk Re: Dying bitcoins 2010-06-21 17:48:26 UTC -  -  Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone. Quote from: laszlo on June 21, 2010, 01:54:29 PM 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.. 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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-06-21 18:09:17 UTC -  -  I integrated the hashmeter idea into the SVN version.  It displays khash/s in the left section of the status bar. Two new log messages: 21/06/2010 01:23 hashmeter   2 CPUs    799 khash/s 21/06/2010 01:23 generated 50.00 grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance.  On windows, use:  findstr "hashmeter generated" "%appdata%itcoin\debug.log" I have the hashmeter messages once an hour.  How often do you think it should be? BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-22 03:45:56 UTC -  -  On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there. But 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. Updated SVN. Thanks for testing. BitcoinTalk 0.3 almost ready -- please test the Mac version! 2010-06-22 04:01:53 UTC -  -  I finished everything on my list to do for version 0.3.  The code on SVN is about ready to release. Testing at this point is much appreciated. BitcoinTalk Re: How fast do the fastest computers generate bitcoins? 2010-06-22 04:35:26 UTC -  -  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. I 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. The latest SVN version has a khash/s display.  Around 400 khash/s per processor is typical. BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-22 16:39:43 UTC -  -  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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-06-22 16:51:14 UTC -  -  Agree.  Certainly too trivial to clutter the user's attention with. I changed it to every 30 minutes. If 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. BitcoinTalk Re: 0.3 almost ready 2010-06-22 17:02:07 UTC -  -  Quote from: lachesis on June 22, 2010, 06:20:02 AM It would be nice if the listtransactions RPC method were finished before the next release, though.  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. We shouldn't delay forever until every possible feature is done.  There's always going to be one more thing to do. BitcoinTalk Re: 0.3 almost ready 2010-06-22 17:37:08 UTC -  -  Here's RC1 for windows for testing: (removed, see RC2 below) Please 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 filesitcoin" Martii Malmi (AKA Sirius) “COPA trial” email #193 Date: Tue, 22 Jun 2010 18:36:22 +0100 From: Satoshi Nakamoto Subject: 0.3.0 rc1 quickie download link To: Martti Malmi If bandwidth is a problem, delete my link in the "0.3 almost ready" thread. I just don't want to upload it to sourceforge for a quickie share for a day or two, possibly taking it down immediately if there's a bug. Sourceforge has a policy of not allowing removal of files once they're added, and it's a pain to upload to. I'll delete the file once the release is ready. BTW, it's looking like I may be able to get us some money soon to cover web host costs, back your exchange service, etc, in the form of cash in the mail. Can you receive it and act as the project's treasurer? BitcoinTalk Re: 0.3 almost ready 2010-06-22 19:11:41 UTC -  -  Quote from: davidonpda on June 22, 2010, 06:23:26 PM EXCEPTION: 22DbRunRecoveryException DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery C:\Program Files\Bitcoinitcoin.exe in OnInit() What operating system? Normally when it does that it's because the directory where the data directory should go doesn't exist.  See if the "%appdata%" directory exists. Do 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. BitcoinTalk Re: 0.3 almost ready 2010-06-22 19:25:13 UTC -  -  davidonpda, were you also running laszlo's build previously? Check if the "%appdata%" directory exists, and "%appdata%itcoin" Try:  rename "%appdata%itcoin" bitcoin2  does it work then? BitcoinTalk Re: 0.3 almost ready 2010-06-22 19:46:23 UTC -  -  You figured it out faster than I could post a reply.   It 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. When you copied the directory except log.0000000002, that's the best solution.  You should be good now. The 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. Please keep running v0.3 if at all possible, don't go back to v0.2.10. Anyone else who hits this problem, move the database\log.000000000* files somewhere else.  (if it works fine after that, you can delete them later) I'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. BitcoinTalk Re: 0.3 almost ready 2010-06-22 22:23:39 UTC -  -  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. 30khash increase to what total rate?  (to figure the % increase) Martii Malmi (AKA Sirius) “COPA trial” email #195 Date: Wed, 23 Jun 2010 21:33:57 +0100 From: Satoshi Nakamoto Subject: Re: donation To: mmalmi@cc.hut.fi >> BTW, it's looking like I may be able to get us some money soon to cover >> web host costs, back your exchange service, etc, in the form of cash in >> the mail. Can you receive it and act as the project's treasurer? > > That would be nice, I can do it. Sending cash in the mail may have its > risks, but maybe it's still the best anonymous option. We can also ask > for donations in BTC on the forum. I got a donation offer for $2000 USD. I need to get your postal mailing address to have him send to. And yes, he wants to remain anonymous, so please keep the envelope's origin private. BitcoinTalk Re: 0.3 almost ready 2010-06-24 17:40:05 UTC -  -  Here's RC1 for linux for testing: (link removed, see below) It contains both 32-bit and 64-bit binaries. Recent changes: build-unix.txt: - Added instructions for building wxBase, which is needed to compile bitcoind. - The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev. - Updated version numbers. makefile.unix: - 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. BitcoinTalk Re: 0.3 almost ready 2010-06-25 02:17:41 UTC -  -  I don't know.  Maybe someone with more Linux experience knows how to install the library it needs. I 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? 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. We 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. I'm also curious if it's a little faster on linux than windows. Do you think I should make the directories: /bin32/ /bin64/ instead of /bin/32/ /bin/64/ BitcoinTalk Re: 0.3 almost ready 2010-06-25 14:10:06 UTC -  -  Thanks virtualcoin, that's a perfect comparison. The 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). The 15% speedup from 32-bit to 64-bit Linux is more of a mystery.  The code is completely 32-bit. Hmm, 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. BitcoinTalk Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel 2010-06-25 21:15:15 UTC -  -  We need more details about what happened MadHatter. Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected. 0.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. 0.3 can also seed without IRC.  It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy. BitcoinTalk Re: On IRC bootstrapping 2010-06-25 22:40:47 UTC -  -  Quote from: laszlo on June 14, 2010, 06:30:58 PM 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. My box is a dedicated irc server:  2:28PM  up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08 You can use irc.lfnet.org to connect. This seems like a good idea. What does everyone think, should we make the switch for 0.3? BitcoinTalk Re: 0.3 almost ready 2010-06-26 00:32:09 UTC -  -  Lets try using Laszlo's irc.lfnet.org instead of freenode.  Here's RC2, that's the only change in it: (see below for download links) BitcoinTalk Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel 2010-06-26 14:28:06 UTC -  -  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. I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over: http://BitcoinTalk.org/index.php?topic=199.msg1787#msg1787 BitcoinTalk Re: 0.3 almost ready 2010-06-26 15:10:10 UTC -  -  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. BitcoinTalk Beta? 2010-06-26 17:02:43 UTC -  -  Is it about time we lose the Beta?  I would make this release version 1.3. BitcoinTalk Re: 1.3 almost ready 2010-06-26 19:21:05 UTC -  -  Changed the version number to 1.3 and removed "Beta". (links removed, see below) Uses irc.lfnet.org. BitcoinTalk Re: Bitcoin mobile. 2010-06-26 20:58:26 UTC -  -  Quote from: sirius-m on June 10, 2010, 01:51:16 PM 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.  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. They 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. If 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. A 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. BitcoinTalk Re: Building BitCoin Client completely Headless 2010-06-26 21:06:06 UTC -  -  The linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind. BitcoinTalk Re: Bitcoin Faucet changes 2010-06-26 21:39:52 UTC -  -  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. If you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha. BitcoinTalk Re: Beta? 2010-06-27 12:43:50 UTC -  -  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) BitcoinTalk Re: IPv6, headless client, and more 2010-06-27 13:02:38 UTC -  -  Welcome, Harry. I hadn't thought about starting out using bitcoind without using bitcoin first.  I guess for now, this thread serves as the tutorial.   The 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. BitcoinTalk Re: 1.3 almost ready 2010-06-27 15:30:13 UTC -  -  MinGW still only has good old stable 3.4.5.  There's not much reason for them to update it.  When 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? BitcoinTalk Re: Major Meltdown 2010-06-27 19:06:09 UTC -  -  Here's an answer to a similar question about how to recover from a major meltdown. https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585 Quote from: satoshi on June 14, 2010, 08:39:50 PM 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. If 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.  BitcoinTalk Re: Feature Request: Limiting Connections 2010-07-02 19:21:36 UTC -  -  Thanks for the feedback on this. One 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. It 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. I will implement a feature to stop accepting inbound connections once you hit a certain number. Which version are you running? Anyone know how many connections typical P2P software like BitTorrent can get up to? BitcoinTalk Re: 1.3 almost ready 2010-07-02 20:37:17 UTC -  -  Quote from: dkaparis on June 27, 2010, 10:02:25 PM 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. It is, but generating is more than twice as slow. BitcoinTalk Re: 0.3 almost ready 2010-07-02 21:57:45 UTC -  -  (reverted to rc2) Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it. BitcoinTalk Re: Beta? 2010-07-02 22:03:41 UTC -  -  OK, back to 0.3 then. Please download RC4 and check it over as soon as possible.  I'd like to release it soon. http://BitcoinTalk.org/index.php?topic=199.msg1927#msg1927 Other 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. BitcoinTalk Re: Feature Request: Limiting Connections 2010-07-02 22:20:20 UTC -  -  I reduced max outbound connections from 15 to 8 in RC4. 15 was way more than we needed for redundancy.  8 is still plenty of redundancy. As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get. If anyone wants more than 8 connections, they can open port 8333 on their firewall. BitcoinTalk Re: 0.3 almost ready -- please test the Mac version! 2010-07-04 21:52:28 UTC -  -  Laszlo's build is going to be our first Mac release so please test it! BitcoinTalk Re: Slashdot Submission for 1.0 2010-07-05 21:31:14 UTC -  -  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. I really appreciate the effort, but there are a lot of problems. We don't want to lead with "anonymous".  (I've been meaning to edit the homepage) "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.  It'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.  Sorry to be a wet blanket.  Writing a description for this thing for general audiences is bloody hard.  There's nothing to relate it to. Martii Malmi (AKA Sirius) “COPA trial” email #197 Date: Tue, 06 Jul 2010 03:59:57 +0100 From: Satoshi Nakamoto Subject: Anonymous, homepage changes To: Martti Malmi I think we should de-emphasize the anonymous angle. With the popularity of bitcoin addresses instead of sending by IP, we can't give the impression it's automatically anonymous. It's possible to be pseudonymous, but you have to be careful. If someone digs through the transaction history and starts exposing information people thought was anonymous, the backlash will be much worse if we haven't prepared expectations by warning in advance that you have to take precautions if you really want to make that work. Like Tor says, "Tor does not magically encrypt all of your Internet activities. Understand what Tor does and does not do for you." Also, anonymous sounds a bit shady. I think the people who want anonymous will still figure it out without us trumpeting it. I made some changes to the bitcoin.org homepage. It's not really crucial to update the translations. I tend to keep editing and correcting for some time afterwards, so if they want to update, they should wait. I removed the word "anonymous", and the sentence about "anonymity means", although you worded it so carefully "...CAN be kept hidden..." it was a shame to remove it. Instead, I added Tor instructions at the bottom, with instructions for how to stay anonymous (pseudonymous) directly after the Tor instructions: "If you want to remain anonymous (pseudonymous, really), be careful not to reveal any information linking your bitcoin addresses to your identity, and use a new bitcoin address for each payment you receive." It helps that it can now seed automatically through Tor. Even though it doesn't say anonymous until the bottom, I think anonymous seekers would already suspect it based on all the other attributes like no central authority to take your ID info and the way bitcoin addresses look. BitcoinTalk Bitcoin 0.3 released! 2010-07-06 18:32:35 UTC -  -  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. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at http://www.bitcoin.org or read the forum to find out more. Martii Malmi (AKA Sirius) “COPA trial” email #198 Date: Tue, 06 Jul 2010 19:03:50 +0100 From: Satoshi Nakamoto Subject: 0.3.0 released To: Martti Malmi I uploaded 0.3.0 beta to sourceforge and updated the links on bitcoin.org. I still need to post the announcement message on the forum and mailing list. Here's what I've prepared: 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 being released to the networks nodes based on the CPU power they contribute. You can get a share of them just by installing the software and contributing your idle CPU time. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Tabs for sent and received transactions - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Martii Malmi (AKA Sirius) “COPA trial” email #199 Date: Tue, 06 Jul 2010 19:40:11 +0100 From: Satoshi Nakamoto Subject: Re: 0.3.0 released To: Martti Malmi Actually, "tabs for sent and received transactions" sounds really immature if it doesn't have that already. "Transaction filter tabs" sounds better. I'm still editing it a little more and then I'll e-mail it to bitcoin-list and send it to the cryptography list. "Get it at http://www.bitcoin.org or read the forum to find out more." BitcoinTalk Re: 0.3 almost ready -- please test the Mac version! 2010-07-06 19:43:18 UTC -  -  0.3 released http://BitcoinTalk.org/index.php?topic=238.msg2004#msg2004 BitcoinTalk Re: 0.3 almost ready -- please test the Mac version! 2010-07-06 19:43:18 UTC -  -  0.3 released http://BitcoinTalk.org/index.php?topic=238.msg2004#msg2004 Martii Malmi (AKA Sirius) “COPA trial” email #200 Date: Tue, 06 Jul 2010 22:53:07 +0100 From: Satoshi Nakamoto Subject: [bitcoin-list] Bitcoin 0.3 released! To: bitcoin-list@lists.sourceforge.net 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. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at www.bitcoin.org, and read the forum to find out more. bitcoin-list [bitcoin-list] Bitcoin 0.3 released! 2010-07-06 21:53:53 UTC -  -  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. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie  and Joozero) Get it at http://www.bitcoin.org, and read the forum to find out more. BitcoinTalk Re: On IRC bootstrapping 2010-07-07 01:31:07 UTC -  -  Everybody needs to connect to the same IRC server and channel so they can find each other. Quote from: Vasiliev on June 25, 2010, 11:50:15 PM You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's. It might not be good if we suddenly rushed freenode with a ton of users all at once. The fallback is our own seed system.  irc.lfnet.org is pretty old and has impressive uptime.  I think it's going to be fine. We 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. BitcoinTalk Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username 2010-07-08 18:24:19 UTC -  -  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. Just 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? BitcoinTalk Re: Anonymity 2010-07-08 19:12:00 UTC -  -  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. Any 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. If 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. If 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. It 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. You 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. BitcoinTalk Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username 2010-07-09 03:01:35 UTC -  -  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. BitcoinTalk Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?) 2010-07-09 03:28:46 UTC -  -  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. The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979: "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]" http://en.wikipedia.org/wiki/Cornering_the_market BitcoinTalk Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username 2010-07-09 15:37:05 UTC -  -  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. BitcoinTalk Re: Security 2010-07-10 12:58:02 UTC -  -  I'll start thinking about how to do this. At 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. With -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. void ThreadIRCSeed(void* parg) {     if (mapArgs.count("-connect"))         return; BitcoinTalk Re: Major Meltdown 2010-07-10 13:36:17 UTC -  -  Quote from: llama on July 01, 2010, 10:21:47 PM 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. 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) BitcoinTalk Re: No blocks downloaded... why? 2010-07-14 16:22:03 UTC -  -  So that was responsible for keeping blocks from downloading? The link: "Win32 CPU Cycles vs 'Live Protection' Engines" For 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? BitcoinTalk Re: resource hog 2010-07-14 16:29:39 UTC -  -  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. If 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. It 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. BitcoinTalk Re: stopped prodicing coins 2010-07-14 17:04:02 UTC -  -  Thanks for making that calculator. The difficulty doubled a day or two ago, plus it's just random and you can have surprisingly long dry spells. BitcoinTalk Re: Building Bitcoin 0.3 2010-07-14 17:34:50 UTC -  -  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. BitcoinTalk Re: bitcoin auto-renice-ing 2010-07-14 17:38:31 UTC -  -  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. The 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. BitcoinTalk Re: Stuck on 513 blocks 2010-07-14 18:02:28 UTC -  -  This is the second time I've seen this "Live Protection" problem reported. It 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. We need to understand this problem better. Can 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. Martii Malmi (AKA Sirius) “COPA trial” email #202 Date: Wed, 14 Jul 2010 22:52:46 +0100 From: Satoshi Nakamoto Subject: Fwd: Re: bitcoin!!!! To: Martti Malmi I see the interior pages of the old sourceforge wiki are still up, though the homepage forwards. -------- Original Message -------- Subject: Re: bitcoin!!!! Date: Wed, 14 Jul 2010 10:56:21 -0400 From: Sam To: Satoshi Nakamoto References: <201004111508.52168.samm@sammaloney.com> <201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com> It was an old FAQ on sourceforge that had been linked from slashdot (on a highly visible comment). people were going there because bitcoin.org was down for a while. http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ Probably not an issue anymore, but might be a good idea to delete or update that wiki page. > I don't see any 0.1.5 download links on the FAQ. Do you mean > bitcoin.org/faq? Is it on one of the other languages? Or maybe someone > else fixed it already. > BitcoinTalk Re: Error on Ubuntu 10.04 2010-07-14 18:25:41 UTC -  -  What language is your computer set to?  Is it set to German, Dutch or Italian?  Is it one of those sub-languages like "nl-??"? It'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. Can someone test each language on Ubuntu and see if there's a problem with just one of them or maybe all three? BitcoinTalk Re: Runaway CPU usage for 64bit BitCoin (Linux Client) 2010-07-14 18:45:53 UTC -  -  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. There 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. Quote from: knightmb on July 12, 2010, 10:39:13 PM On a side note, I've tracked down the other GUI issue. 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. This only seems to affect the 64 bit Client, as the 32 bit Clients I have don't seem to be affected by this. 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?   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. BitcoinTalk Re: Warning this block was not received by any other nodes 2010-07-14 18:56:29 UTC -  -  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. You need to make bitcoin.exe an excluded process in Live Protection. This is becoming a common problem.  Someone should write this up in a pegged thread. The 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. BitcoinTalk Re: Hash/sec Throttling for Democracy 2010-07-14 20:25:06 UTC -  -  Quote from: knightmb on July 14, 2010, 07:17:43 PM So if your computer was only 1% towards solving block 68000 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. It'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. The 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. BitcoinTalk Re: Scalability 2010-07-14 21:10:52 UTC -  -  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.  The 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. BitcoinTalk Re: Runaway CPU usage for 64bit BitCoin (Linux Client) 2010-07-15 00:18:23 UTC -  -  OK, the undocumented switch "-minimizetotray" which re-enables the option. I uploaded the change to SVN. BitcoinTalk Re: [Bitcoin 0.3.0] Runtime error 2010-07-15 14:05:20 UTC -  -  More directly, this: http://BitcoinTalk.org/index.php?topic=246.0 I 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. BitcoinTalk Re: Static Linux x86_64 bins for those having libcrypto troubles 2010-07-15 14:33:04 UTC -  -  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. BitcoinTalk Re: resource hog 2010-07-15 14:59:00 UTC -  -  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%. BitcoinTalk Bitcoin 0.3.1 released 2010-07-15 17:05:54 UTC -  -  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. The download links are on bitcoin.org Changes: - Added Portuguese translation by Tiago Faria Windows - Fix for 22DbRunRecoveryException if your username has non-ascii characters in it Linux - Laszlo's fix for lowering generate thread to lowest priority  - Fix for if you're having trouble with libcrypto linkage - Gavin Andresen's implementation of "start on windowing system startup" option BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-15 17:23:48 UTC -  -  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. BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-15 17:56:43 UTC -  -  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. BitcoinTalk Re: Website and software translations 2010-07-15 18:30:22 UTC -  -  Quote from: aidos on July 15, 2010, 12:49:11 AM Ok here is the .po file for French. While I'm at it, I noted a couple of issues: 1. 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. I need to give an updated .po file. Quote from: aidos on July 15, 2010, 12:49:11 AM 2. If an transaction's description in the list of transaction in the main window contains a diacritical character (such as "\u00e9\u00e0\u00e8\u00e7"), it's not displayed. I suppose the string is not being properly handled as UTF8 somewhere. OK, this must be a problem somewhere, I'll have to take a look at it or one of the other devs can. Quote from: aidos on July 15, 2010, 12:49:11 AM 4. About the .po file :    - There are a few strings in the .po file that don't needs translation (ie: "Bitcoin"). Maybe those shouldn't be inside _("...") ?    - 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.    - Some strings have whitespace at the end or start, which necessity is very debatable, and it's easy to miss in PoEdit. 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. BitcoinTalk Re: Website and software translations 2010-07-15 18:37:13 UTC -  -  I uploaded an updated bitcoin.po for 0.3.1 attached to this message: http://BitcoinTalk.org/index.php?topic=151.msg1259#msg1259 please use it if you're starting a new translation. If you already have a po file, poedit can update it.   - Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do: http://BitcoinTalk.org/index.php?topic=383.0 - Make a subdirectory under src: locale/??/LC_MESSAGES (?? could be anything really, "en" or your language 2-letter code) - Put your .po file there - Open it with poedit - In poedit, Catalog->Update from sources The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file. Martii Malmi (AKA Sirius) “COPA trial” email #203 Date: Thu, 15 Jul 2010 18:41:10 +0100 From: Satoshi Nakamoto Subject: bitcoin.org drupal users To: Martti Malmi Is it possible for the translators (at least the more trusted ones) to have user accounts on drupal so they can update their translated text directly? The user accounts on drupal appear to be pretty weak. I created a satoshi account and it can't even edit the side bar stuff, just the main text of pages. I don't think user accounts can access any of the admin stuff. Do you think it's safe, or do you feel insecure about doing that? If you're worried, maybe there's a way to lock just the english version of the homepage. It would be nice if when I need to make changes to the homepage, I could enlist someone like Xunie to do the rote work of reflecting it to all the translations instead of having to do all that work myself. (many light changes don't require understanding the language to fix the translated pages) BitcoinTalk Re: Website and software translations 2010-07-15 18:43:54 UTC -  -  Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM I recommend to remove the download links at the bottom of the main page. As 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. There's a download box with the current releases on the right anyway, so why not remove the links from the translated pages. I updated them to 0.3.0. I am tempted to remove the download links from the other languages and only keep it on English. They 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. Martii Malmi (AKA Sirius) “COPA trial” email #204 Date: Thu, 15 Jul 2010 18:43:55 +0100 From: Satoshi Nakamoto Subject: Fwd: Please update the bitcoin FAQ so new member can have the right info To: Martti Malmi -------- Original Message -------- Subject: Please update the bitcoin FAQ so new member can have the right info Date: Mon, 12 Jul 2010 14:13:20 -0700 From: Jim Nguyen To: satoshin@gmx.com Hi, In the FAQ of bitcoin.org the backing up of the wallet had old instructions, right? Should it just be to back up wallat.dat instead of the entire folder??? See below. "How do I backup my wallet? Your data is stored in the directory ''%appdata%\Bitcoin'', which is typically: Windows XP: C:\Documents and Settings\username\Application Data\Bitcoin Windows Vista: C:\Users\username\AppData\Roaming\Bitcoin It’s recommended that you stop Bitcoin before backing it up to make sure the backup will be correct." BitcoinTalk Re: Website and software translations 2010-07-15 19:12:14 UTC -  -  Thanks for the Spanish and French translations!  The edited and updated .po files are attached. I uploaded these to the SVN. Martii Malmi (AKA Sirius) “COPA trial” email #205 Date: Thu, 15 Jul 2010 21:00:12 +0100 From: Satoshi Nakamoto Subject: bitcoin.org server To: Martti Malmi You did some research when choosing hosting, this was a well chosen one, right? It seems like it would be a tremendous hassle to change, and we've had good luck with this one. Cheaper will usually have some offsetting drawback in quality. I wonder if that extra memory is just disk cache or something. I take it you haven't received anything from that donor yet? He seemed pretty certain he was going to send it, maybe more. (if you get anything, we need to keep private for him the fact that we got a donation) BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-15 21:40:34 UTC -  -  Quote from: knightmb on July 15, 2010, 07:37:10 PM 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. 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. Do you have dual-proc?  Are you sure you weren't running a single processor hog? BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-15 22:07:35 UTC -  -  Quote from: knightmb on July 15, 2010, 08:15:46 PM 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). 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! http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-15 22:10:19 UTC -  -  Quote from: db on July 15, 2010, 08:39:08 PM The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.) Yes a bug.  It'll have to be fixed in the next version. BitcoinTalk Re: "SetIcons(): icon bundle doesn't contain any suitable icon" 2010-07-16 02:43:29 UTC -  -  That must be it then. It must be looking for a larger icon like 20x20 but we don't have one. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-07-16 14:46:12 UTC -  -  The proof-of-work difficulty is currently 45.38.  (see http://www.alloscomp.com/bitcoin/calculator.php)   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. The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase. BitcoinTalk Re: Assertion Failure - Ubuntu Lucid 2010-07-16 14:52:04 UTC -  -  That's the first time I've seen this error. How many blocks do you have? (in the status bar) You 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? BitcoinTalk Re: Fedora 13 libcrypto 2010-07-16 14:55:23 UTC -  -  Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency: http://BitcoinTalk.org/index.php?topic=383.0 Let me know if that works. BitcoinTalk Re: Resending transaction 2010-07-16 15:01:33 UTC -  -  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. BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-16 15:09:59 UTC -  -  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. BitcoinTalk Re: Source code documentation 2010-07-16 15:37:00 UTC -  -  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. To add them now at this point, what would be written would just be what's obvious from looking at the function. The external API we have, in rpc.cpp, the usage documentation is in the help string. Sorry to be a wet blanket. BitcoinTalk Re: Hash() function not secure 2010-07-16 16:13:53 UTC -  -  SHA256 is not like the step from 128 bit to 160 bit. To 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. SHA256 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. If 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. BitcoinTalk Re: Request: expected bitcoins per day display 2010-07-16 16:47:14 UTC -  -  Many businesses are like that.  For a car salesman, when will the next customer walk in the door? On 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? The difficulty quadrupled a few minutes ago to 181.54.  It's going to take typically about a week to generate now. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-07-16 16:56:54 UTC -  -  It adjusted to 181.54 a few minutes ago.  Typical time to get a block is about a week now. The difficulty can adjust down as well as up. The network should be generating close to 6 blocks per hour now. BitcoinTalk Re: Source code documentation 2010-07-16 17:15:47 UTC -  -  It's in init.cpp. It'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) Sorry 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. We'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. BitcoinTalk Re: 0.3.1 release candidate, please test 2010-07-16 17:26:17 UTC -  -  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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-07-16 17:29:28 UTC -  -  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. BitcoinTalk Re: bitcoin trademark? 2010-07-16 17:47:05 UTC -  -  No, not related at all. BitcoinTalk Re: The dollar cost of bitmining energy 2010-07-16 17:58:44 UTC -  -  Neat chart. Difficulty just increased by 4 times, so now your cost is US$0.02/BTC. BitcoinTalk Re: Website integration for bitcoin 2010-07-16 18:23:04 UTC -  -  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. BitcoinTalk Re: Proof-of-work difficulty increasing 2010-07-16 18:43:51 UTC -  -  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. The recent adjustment put us back to close to 6 blocks per hour again. There's a site where you can see the time between blocks, and since block 68545, it's been more like 10 minutes per block: http://nullvoid.org/bitcoin/statistix.php BitcoinTalk Sample account system using JSON-RPC needed 2010-07-16 19:45:10 UTC -  -  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. When 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 ).  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) You use getreceivedbylabel 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. If 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.  A 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. vekja.net is an example of a site like this. BitcoinTalk Re: Bitcoin 0.3.1 released 2010-07-16 21:06:57 UTC -  -  I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the links on the homepage. You 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. BitcoinTalk Re: A New Currency System for the World 2010-07-16 22:20:09 UTC -  -  Quote from: hugolp on May 08, 2010, 10:38:51 AM 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. 0.3.1 fixes that, sets the generate threads to the lowest priority.  Download links are on the homepage now. BitcoinTalk Re: BUG Report: Rounding glitch 2010-07-17 16:06:12 UTC -  -  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. 1.139999999999 is longer than bitcoin can internally represent. internally, it could only be: 1.13999999 or 1.14000000 1.139999999999 is much much closer to 1.14000000 than 1.13999999, so it must be 1.14000000. The code is this: (double)GetBalance() / (double)COIN. (I can't think of an easy way to fix it at the moment) BitcoinTalk Re: Privacy versus Safety: handling change 2010-07-17 16:27:39 UTC -  -  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. The 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. There'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. BitcoinTalk Re: Nenolod, the guy that wants to prove Bitcoin doesn't work. 2010-07-17 16:56:06 UTC -  -  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%. But if someone has 50%+ of the CPU power and malicious intent, they can prove what it already says in the design document. BitcoinTalk Bitcoin 0.3.2 released 2010-07-17 21:35:51 UTC -  -  Download links available now on bitcoin.org.  Everyone should upgrade to this version. - Added a simple security safeguard that locks-in the block chain up to this point. - Reduced addr messages to save bandwidth now that there are plenty of nodes to connect to. - Spanish translation by milkiway. - French translation by aidos. The 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) I'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. BitcoinTalk Re: Bitcoin snack machine (fast transaction problem) 2010-07-17 22:29:13 UTC -  -  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. The 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. A rough back-of-the-envelope example: 1         0 4         1 16        4 64        16 80%      20% So if a double-spend has to wait even a second, it has a huge disadvantage. The 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. BitcoinTalk Re: Assertion Failure - Ubuntu Lucid 2010-07-17 22:37:06 UTC -  -  Quote from: singpolyma on July 17, 2010, 10:19:48 PM My coins disappeared, but I assume they'll come back when it's up to current? Right, they'll re-appear when it's finished downloading all the blocks. BitcoinTalk Re: Bitcoin 0.3.2 released 2010-07-17 22:54:24 UTC -  -  Quote from: llama on July 17, 2010, 09:56:25 PM 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. 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: llama on July 17, 2010, 09:56:25 PM Also, I'm assuming that the block lock means that the blocks will also come prepackaged with the client.  Is this so? Sorry, not yet, but I do want to make the initial block download faster. BitcoinTalk Re: Source code documentation 2010-07-17 23:18:30 UTC -  -  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. All the user-facing commands are listed in the -? help. BitcoinTalk Re: Network Size 2010-07-17 23:25:16 UTC -  -  Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM 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. In 0.3.0, the change to 8 only ended up in the Windows version, the other versions still had 15. Please upgrade to 0.3.2, it's available now. BitcoinTalk Re: Bitcoin snack machine (fast transaction problem) 2010-07-18 01:59:15 UTC -  -  Quote from: llama on July 18, 2010, 12:03:29 AM This is a good start, but still not impermeable. I didn't say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards. Quote (for example, by refusing to propogate word of the transaction at the vending machine) 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. BitcoinTalk Re: Source code documentation 2010-07-18 15:12:54 UTC -  -  They're only intended for intrepid programmers who read the sourcecode. BitcoinTalk Re: URI-scheme for bitcoin 2010-07-18 16:06:16 UTC -  -  Quote from: lachesis on June 16, 2010, 06:14:05 AM 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). That's what I thought too. Quote from: sirius-m on June 16, 2010, 08:26:14 AM 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. 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... If this is the case, then do not use the -server switch or bitcoind on a system where you do web browsing. I'll get started on adding the password field. Martii Malmi (AKA Sirius) “COPA trial” email #209 Date: Sun, 18 Jul 2010 16:23:21 +0100 From: Satoshi Nakamoto Subject: wiki To: Martti Malmi http://www.bitcoin.org/smf/index.php?topic=393.msg3785#msg3785 AndrewBuck: ... EDIT: 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? -Buck Martii Malmi (AKA Sirius) “COPA trial” email #210 Date: Sun, 18 Jul 2010 16:23:10 +0100 From: Satoshi Nakamoto Subject: Re: Fwd: bitcoin hosting To: mmalmi@cc.hut.fi Please promise me you won't make a switch now. The last thing we need is switchover hassle on top of the slashdot flood of work we've got now. I'm losing my mind there are so many things that need to be done. Also, it would suck to be on a smaller, less reliable host just to save a measly $20. I will try to think of a polite way to ask the donor if he sent it, but right now there are other higher priority things that are going to bump even that for a few days. Would a donation of bitcoins help in the short term? mmalmi@cc.hut.fi wrote: > Rackspace has very good support, good backend, good connections and > nicely scaling cloud based virtual servers. I got this offer from Thufir: > > ----- > Hi Sirius, > > Check out www.citrusdesignstudio.com. You will see through the portfolio > that > I am a real business with many clients. > > That is my business that I provide managed hosting through. > I also do unmanaged VPSes. > > Normally I would charge $15/mo for 512MB. > I will do it for $10/mo for you. > > To see my pricing, go to www.linnode.com. I match everything they have > except > their great panel -- you have to email or call my people. > > I provide VPS services normally for 3/4ths the posted cost on linnode.com. > (Rackspace is even more expensive.) > > I will do it for 1/2 of linnode's price for you. > > It scales linerally just like linnodes, so for 2048 MB of memory, I would > charge $40, etc. > > Later! > ----- > > That would be worth considering, if they have good datacenters and > connections. $10 / month is about $20 less than what Rackspace costs. On > the other hand, Rackspace prices are no problem if the donation is to > arrive. > BitcoinTalk Re: Bitcoin 0.3.2 released 2010-07-18 18:58:21 UTC -  -  The change list is basically encompassed by what's listed in the first message.  Everyone should upgrade to get the important security improvements. Minimizing 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. BitcoinTalk JSON-RPC password 2010-07-18 20:49:22 UTC -  -  I uploaded to SVN my changes to add a password to JSON-RPC.  If you're set up to build, please test it. The -server switch is replaced with -rpcpw=, which is also used with bitcoind. bitcoin -rpcpw=    -- runs with JSON-RPC port open bitcoind -rpcpw=   -- daemon with password If 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. It gives a warning if you don't set a password. All commands now require the password as the first parameter.  It'll tell you that if you run "bitcoind help". The central code:   // Check password   if (params.size() < 1 || params[0].type() != str_type)       throw runtime_error("First parameter must be the password.");   if (params[0].get_str() != strRPCPassword)   {       if (strRPCPassword.size() < 15)           Sleep(50);       begin = strRequest.end();       printf("ThreadRPCServer incorrect password attempt ");       throw runtime_error("Incorrect password.");   } Any comments on these decisions? 1) 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. 2) 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) I also fixed the two duplicated commands listed in the help: getaddressesbylabel