All BitcoinTalk forum posts (539, SNI numbers 5–543), from "Welcome to the new Bitcoin forum!" to "Added some DoS limits, removed safe mode (0.3.19)" (Part 1 of 4)

Document text

Research, not advice. Part of the Bitcoin research archive (October 2026). Claims labelled unverified, contested or fringe are reported, not endorsed; statuses of bills and rules are as of the date checked. Government, court and patent records are public domain; the research notes are CC BY 4.0.

Satoshi Nakamoto — all BitcoinTalk forum posts, November 2009 – December 2010

Satoshi Nakamoto — all BitcoinTalk forum posts, November 2009 – December 2010

Compiled 2026-10-09 for ~/Projects/bitcoin (research, not advice).

Source: Satoshi Nakamoto Institute (SNI), data file forum_posts.json
at commit c412eb84a1d97df9114a6bf4dea300820965c0a7 of github.com/NakamotoInstitute/nakamotoinstitute.org, retrieved 2026-10-09.
SNI's site and data are licensed CC BY-SA 4.0; the messages themselves are Satoshi Nakamoto's own writing.

Contents: 539 messages by Satoshi Nakamoto from the Bitcoin Forum / BitcoinTalk (bitcoin.sourceforge.net/forum, later bitcointalk.org). Only Satoshi's own messages are included.
Replies by other people in the same threads are left out; text other people wrote that Satoshi quoted inside his own
message is kept as part of his message. Message text is reproduced as SNI publishes it; image tags are replaced by a
text placeholder so this file loads nothing from the internet. Dates are UTC as given by SNI.

Contents

#Date (UTC)Subject / threadOriginalSNI page

52009-11-22T18:04:28ZWelcome to the new Bitcoin forum!
thread: Welcome to the new Bitcoin forum!originalSNI

62009-11-22T18:31:44ZRepost: Bitcoin Maturation
thread: Repost: Bitcoin MaturationoriginalSNI

72009-11-22T18:32:00ZRepost: Request: Make this anonymous?
thread: Repost: Request: Make this anonymous?originalSNI

82009-11-22T18:34:21ZRe: Repost: Bitcoin Maturation
thread: Repost: Bitcoin MaturationoriginalSNI

92009-11-22T18:35:15ZRe: Repost: Request: Make this anonymous?
thread: Repost: Request: Make this anonymous?originalSNI

102009-11-25T18:15:57ZRepost: How anonymous are bitcoins?
thread: Repost: How anonymous are bitcoins?originalSNI

112009-11-25T18:17:23ZRe: Repost: How anonymous are bitcoins?
thread: Repost: How anonymous are bitcoins?originalSNI

122009-11-27T17:17:22ZRepost: Linux/UNIX compile
thread: Repost: Linux/UNIX compileoriginalSNI

132009-11-27T17:27:09ZRe: Repost: Linux/UNIX compile
thread: Repost: Linux/UNIX compileoriginalSNI

142009-11-27T22:48:39Z[OLD THREAD] Bitcoin version 0.2 development status
thread: [OLD THREAD] Bitcoin version 0.2 development statusoriginalSNI

152009-12-09T18:45:10ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

162009-12-10T19:31:49ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

172009-12-10T20:49:02ZRe: Questions about Bitcoin
thread: Questions about BitcoinoriginalSNI

182009-12-11T17:58:57ZRe: Questions about Bitcoin
thread: Questions about BitcoinoriginalSNI

192009-12-11T19:27:55ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

202009-12-12T17:52:44ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

212009-12-12T18:17:10ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

222009-12-13T16:51:25ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

232009-12-14T17:15:56ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

242009-12-15T20:37:32ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

252009-12-16T22:45:36ZBitcoin 0.2 released!
thread: Bitcoin 0.2 released!originalSNI

262009-12-17T18:38:06ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

272009-12-18T17:37:48ZRe: A few suggestions
thread: A few suggestionsoriginalSNI

282010-01-05T20:00:46ZRe: Is my second Transaction working correctly? +Transfer Question
thread: Is my second Transaction working correctly? +Transfer QuestionoriginalSNI

292010-01-14T20:17:20ZRe: 64bit support
thread: 64bit supportoriginalSNI

302010-01-20T20:07:15ZRe: Number of connections?
thread: Number of connections?originalSNI

312010-01-20T22:05:28ZRe: TOR and I2P
thread: TOR and I2PoriginalSNI

322010-01-27T21:52:27ZRe: Bitcoin crash when sending coins
thread: Bitcoin crash when sending coinsoriginalSNI

332010-01-28T01:01:48ZRe: A newb's test - anyone want to buy a picture for $1?
thread: A newb's test - anyone want to buy a picture for $1?originalSNI

342010-01-28T01:08:33ZRe: Blocks never stop generating?
thread: Blocks never stop generating?originalSNI

352010-01-28T23:08:02ZRe: Bitcoin crash when sending coins
thread: Bitcoin crash when sending coinsoriginalSNI

362010-01-28T23:26:09ZRe: Payment server
thread: Payment serveroriginalSNI

372010-01-29T00:22:13ZRe: A newb's test - anyone want to buy a picture for $1?
thread: A newb's test - anyone want to buy a picture for $1?originalSNI

382010-01-29T00:42:49ZRe: 64bit support
thread: 64bit supportoriginalSNI

392010-02-03T23:29:57ZRe: Bitcoin crash when sending coins
thread: Bitcoin crash when sending coinsoriginalSNI

402010-02-03T23:36:54ZRe: Win32 CPU Cycles vs 'Live Protection' Engines ?
thread: Win32 CPU Cycles vs 'Live Protection' Engines ?originalSNI

412010-02-04T00:07:07ZRe: Questions about Addresses
thread: Questions about AddressesoriginalSNI

422010-02-04T00:30:50ZRe: TOR and I2P
thread: TOR and I2PoriginalSNI

432010-02-05T19:19:12ZProof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

442010-02-05T19:44:46ZRe: Questions about Addresses
thread: Questions about AddressesoriginalSNI

452010-02-06T21:06:32ZRe: Repost: Request: Make this anonymous?
thread: Repost: Request: Make this anonymous?originalSNI

462010-02-06T23:25:53ZRe: How divisible are bitcoins and other market/economic questions
thread: How divisible are bitcoins and other market/economic questionsoriginalSNI

472010-02-08T01:22:29ZRe: Make your "we accept Bitcoin" logo
thread: Make your "we accept Bitcoin" logooriginalSNI

482010-02-08T01:27:02ZBitcoin client and website translation
thread: Bitcoin client and website translationoriginalSNI

492010-02-08T16:10:37ZBitcoin client and website translation
thread: Bitcoin client and website translationoriginalSNI

502010-02-08T16:37:24ZRe: Simple to implement feature requests
thread: Simple to implement feature requestsoriginalSNI

512010-02-12T02:33:02ZRe: DEB Package?
thread: DEB Package?originalSNI

522010-02-12T03:08:08ZRe: What's with this odd generation?
thread: What's with this odd generation?originalSNI

532010-02-12T15:57:37ZRe: DEB Package?
thread: DEB Package?originalSNI

542010-02-12T17:28:32ZRe: Repost: Request: Make this anonymous?
thread: Repost: Request: Make this anonymous?originalSNI

552010-02-13T01:38:37ZRe: DEB Package?
thread: DEB Package?originalSNI

562010-02-14T06:28:03ZRe: What's with this odd generation?
thread: What's with this odd generation?originalSNI

572010-02-14T15:52:23ZRe: What's with this odd generation?
thread: What's with this odd generation?originalSNI

582010-02-15T06:28:38ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

592010-02-16T01:34:56ZRe: Setting up multiple bitcoin machines behind NAT
thread: Setting up multiple bitcoin machines behind NAToriginalSNI

602010-02-16T17:36:40ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

612010-02-17T17:58:03ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

622010-02-17T19:19:43ZRe: Bitcoin client and website translation
thread: Bitcoin client and website translationoriginalSNI

632010-02-21T03:43:48ZRe: Number of connections
thread: Number of connectionsoriginalSNI

642010-02-21T04:19:53ZPost your static IP
thread: Post your static IPoriginalSNI

652010-02-21T05:44:24ZRe: Current Bitcoin economic model is unsustainable
thread: The current Bitcoin economic model doesn't workoriginalSNI

662010-02-21T21:48:01ZUI improvements
thread: UI improvementsoriginalSNI

672010-02-23T00:49:56ZRe: generation slowed down dramatically
thread: generation slowed down dramaticallyoriginalSNI

682010-02-23T01:16:28ZRe: UI improvements
thread: UI improvementsoriginalSNI

692010-02-23T16:26:09ZRe: Bitcoin Address Collisions
thread: Bitcoin Address CollisionsoriginalSNI

702010-02-23T16:53:27ZRe: UI improvements
thread: UI improvementsoriginalSNI

712010-02-23T22:15:41ZCommand Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

722010-02-23T22:24:00ZRe: Bitcoin Address Collisions
thread: Bitcoin Address CollisionsoriginalSNI

732010-02-24T05:57:43ZRe: URI-scheme for bitcoin
thread: URI-scheme for bitcoinoriginalSNI

742010-02-24T06:17:23ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

752010-02-24T21:24:23ZNew icon/logo
thread: New icon/logooriginalSNI

762010-02-24T21:53:52ZRe: Make your "we accept Bitcoin" logo
thread: Make your "we accept Bitcoin" logooriginalSNI

772010-02-24T22:08:55ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

782010-02-24T22:42:24ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

792010-02-25T01:56:24ZRe: New icon/logo
thread: New icon/logooriginalSNI

802010-02-25T22:54:17ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

812010-02-25T23:06:29ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

822010-02-26T16:29:21ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

832010-02-26T23:17:19ZRe: New icon/logo
thread: New icon/logooriginalSNI

842010-02-26T23:48:44ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

852010-02-27T04:28:29ZRe: New icon/logo
thread: New icon/logooriginalSNI

862010-02-27T21:22:53ZRe: wxWidgets 2.9.0
thread: wxWidgets 2.9.0originalSNI

872010-03-02T02:33:05ZRe: New icon/logo
thread: New icon/logooriginalSNI

882010-03-03T04:28:56ZRe: Money Transfer Regulations
thread: Money Transfer RegulationsoriginalSNI

892010-03-05T01:46:25ZRe: Command Line and JSON-RPC
thread: Command Line and JSON-RPCoriginalSNI

902010-03-15T18:44:12ZRe: bitcoin auto-renice-ing
thread: bitcoin auto-renice-ingoriginalSNI

912010-03-15T19:16:56ZIdea for file hosting and proxy services
thread: Idea for file hosting and proxy servicesoriginalSNI

922010-03-16T19:48:47ZRe: On IRC bootstrapping
thread: On IRC bootstrappingoriginalSNI

932010-03-16T20:17:34ZRe: Idea for file hosting service
thread: Idea for file hosting and proxy servicesoriginalSNI

942010-03-23T15:22:41ZRe: who is bitcoin.com
thread: who is bitcoin.comoriginalSNI

952010-03-23T17:35:34ZRe: Exchange Methods
thread: Exchange MethodsoriginalSNI

962010-03-24T18:01:57ZRe: Idea for file hosting and proxy services
thread: Idea for file hosting and proxy servicesoriginalSNI

972010-03-24T18:02:55ZRe: Idea for file hosting and proxy services
thread: Idea for file hosting and proxy servicesoriginalSNI

982010-05-16T21:01:44ZRe: Could the bitcoin network be destroyed by someone generating endless bitcoin add
thread: Could the bitcoin network be destroyed by someone generating endless bitcoin addoriginalSNI

992010-05-16T21:37:36ZRe: For a website taking payments with bitcoins, better: IP or bitcoin addresses?
thread: For a website taking payments with bitcoins, better: IP or bitcoin addresses?originalSNI

1002010-05-16T22:37:21ZRe: URI-scheme for bitcoin
thread: URI-scheme for bitcoinoriginalSNI

1012010-05-16T22:53:59ZRe: Exception: 9key_error error
thread: Exception: 9key_error errororiginalSNI

1022010-05-16T23:34:40ZRe: removing bitcoin addresses
thread: removing bitcoin addressesoriginalSNI

1032010-05-16T23:56:03ZRe: Setting up multiple bitcoin machines behind NAT
thread: Setting up multiple bitcoin machines behind NAToriginalSNI

1042010-05-18T02:58:11ZRe: Is there a way to automate bitcoin payments for a website?
thread: Is there a way to automate bitcoin payments for a website?originalSNI

1052010-05-18T20:06:46ZRe: Ummmm... where did my bitcoins go?
thread: Ummmm... where did my bitcoins go?originalSNI

1062010-05-20T21:43:42ZRe: We accept Bitcoins
thread: We accept Bitcoins [moved to bitcoin.it/wiki/Trade]originalSNI

1072010-05-26T18:27:25ZJSON-RPC programming tips using labels
thread: JSON-RPC programming tips using labelsoriginalSNI

1082010-05-26T18:51:04ZRe: Tracing a coin's lineage
thread: Tracing a coin's lineageoriginalSNI

1092010-05-26T20:09:34ZRe: CLI bitcoin generation
thread: CLI bitcoin generationoriginalSNI

1102010-05-26T20:34:34ZRe: Share database blocks ?
thread: Share database blocks ?originalSNI

1112010-05-26T21:16:34ZRe: Website translations
thread: Website and software translationsoriginalSNI

1122010-05-26T21:34:32ZRe: Odd amount of generated coins
thread: Odd amount of generated coinsoriginalSNI

1132010-05-27T14:18:22ZRe: Website translations
thread: Website and software translationsoriginalSNI

1142010-06-02T18:18:15ZRe: Hostnames instead of IP Addresses
thread: Hostnames instead of IP AddressesoriginalSNI

1152010-06-02T18:45:38ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

1162010-06-02T22:18:09ZRe: Website translations
thread: Website and software translationsoriginalSNI

1172010-06-14T18:13:21ZRe: On IRC bootstrapping
thread: On IRC bootstrappingoriginalSNI

1182010-06-14T19:53:44ZRe: Hostnames instead of IP Addresses
thread: Hostnames instead of IP AddressesoriginalSNI

1192010-06-14T20:39:50ZRe: Dealing with SHA-256 Collisions
thread: Dealing with SHA-256 CollisionsoriginalSNI

1202010-06-14T22:21:55ZRe: Technical clarifications
thread: Technical clarificationsoriginalSNI

1212010-06-14T22:40:14ZRe: Can't Build r80 from SVN
thread: Can't Build r80 from SVNoriginalSNI

1222010-06-15T23:41:29ZRe: What is the incentive to collect transactions?
thread: What is the incentive to collect transactions?originalSNI

1232010-06-16T00:15:47ZRe: URI-scheme for bitcoin
thread: URI-scheme for bitcoinoriginalSNI

1242010-06-16T16:53:34ZRe: Website translations
thread: Website and software translationsoriginalSNI

1252010-06-17T17:07:56ZRe: new binary release?
thread: new binary release?originalSNI

1262010-06-17T18:46:08ZRe: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
thread: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIGoriginalSNI

1272010-06-18T16:17:14ZRe: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
thread: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIGoriginalSNI

1282010-06-18T17:28:18ZRe: On IRC bootstrapping
thread: On IRC bootstrappingoriginalSNI

1292010-06-18T23:08:34ZRe: Get 5 free bitcoins from freebitcoins.appspot.com
thread: Get 5 free bitcoins from freebitcoins.appspot.comoriginalSNI

1302010-06-21T17:20:21ZRe: Bitcoin in Ubuntu 10.04
thread: Bitcoin in Ubuntu 10.04originalSNI

1312010-06-21T17:48:26ZRe: Dying bitcoins
thread: Dying bitcoinsoriginalSNI

1322010-06-21T18:09:17ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

1332010-06-22T03:45:56ZRe: Bitcoin in Ubuntu 10.04
thread: Bitcoin in Ubuntu 10.04originalSNI

1342010-06-22T04:01:53Z0.3 almost ready -- please test the Mac version!
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1352010-06-22T04:35:26ZRe: How fast do the fastest computers generate bitcoins?
thread: How fast do the fastest computers generate bitcoins?originalSNI

1362010-06-22T16:39:43ZRe: Bitcoin in Ubuntu 10.04
thread: Bitcoin in Ubuntu 10.04originalSNI

1372010-06-22T16:51:14ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

1382010-06-22T17:02:07ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1392010-06-22T17:37:08ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1402010-06-22T19:11:41ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1412010-06-22T19:25:13ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1422010-06-22T19:46:23ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1432010-06-22T22:23:39ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1442010-06-24T17:40:05ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1452010-06-25T02:17:41ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1462010-06-25T14:10:06ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1472010-06-25T21:15:15ZRe: Bitcoin clients getting k-lined from the IRC bootstrapping channel
thread: Bitcoin clients getting k-lined from the IRC bootstrapping channeloriginalSNI

1482010-06-25T22:40:47ZRe: On IRC bootstrapping
thread: On IRC bootstrappingoriginalSNI

1492010-06-26T00:32:09ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1502010-06-26T14:28:06ZRe: Bitcoin clients getting k-lined from the IRC bootstrapping channel
thread: Bitcoin clients getting k-lined from the IRC bootstrapping channeloriginalSNI

1512010-06-26T15:10:10ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1522010-06-26T17:02:43ZBeta?
thread: Beta?originalSNI

1532010-06-26T19:21:05ZRe: 1.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1542010-06-26T20:58:26ZRe: Bitcoin mobile.
thread: Bitcoin mobile.originalSNI

1552010-06-26T21:06:06ZRe: Building BitCoin Client completely Headless
thread: Building BitCoin Client completely HeadlessoriginalSNI

1562010-06-26T21:39:52ZRe: Bitcoin Faucet changes
thread: Bitcoin Faucet changesoriginalSNI

1572010-06-27T12:43:50ZRe: Beta?
thread: Beta?originalSNI

1582010-06-27T13:02:38ZRe: IPv6, headless client, and more
thread: IPv6, headless client, and moreoriginalSNI

1592010-06-27T15:30:13ZRe: 1.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1602010-06-27T19:06:09ZRe: Major Meltdown
thread: Major MeltdownoriginalSNI

1612010-07-02T19:21:36ZRe: Feature Request: Limiting Connections
thread: Feature Request: Limiting ConnectionsoriginalSNI

1622010-07-02T20:37:17ZRe: 1.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1632010-07-02T21:57:45ZRe: 0.3 almost ready
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1642010-07-02T22:03:41ZRe: Beta?
thread: Beta?originalSNI

1652010-07-02T22:20:20ZRe: Feature Request: Limiting Connections
thread: Feature Request: Limiting ConnectionsoriginalSNI

1662010-07-04T21:52:28ZRe: 0.3 almost ready -- please test the Mac version!
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1672010-07-05T21:31:14ZRe: Slashdot Submission for 1.0
thread: Slashdot Submission for 1.0originalSNI

1682010-07-06T18:32:35ZBitcoin 0.3 released!
thread: Bitcoin 0.3 released!originalSNI

1692010-07-06T19:43:18ZRe: 0.3 almost ready -- please test the Mac version!
thread: 0.3 almost ready -- please test the Mac version!originalSNI

1702010-07-07T01:31:07ZRe: On IRC bootstrapping
thread: On IRC bootstrappingoriginalSNI

1712010-07-08T18:24:19ZRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in usernameoriginalSNI

1722010-07-08T19:12:00ZRe: Anonymity
thread: AnonymityoriginalSNI

1732010-07-09T03:01:35ZRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in usernameoriginalSNI

1742010-07-09T03:28:46ZRe: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)
thread: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)originalSNI

1752010-07-09T15:37:05ZRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
thread: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in usernameoriginalSNI

1762010-07-10T12:58:02ZRe: Security
thread: SecurityoriginalSNI

1772010-07-10T13:36:17ZRe: Major Meltdown
thread: Major MeltdownoriginalSNI

1782010-07-14T16:22:03ZRe: No blocks downloaded... why?
thread: No blocks downloaded - MS Security Essentials users please readoriginalSNI

1792010-07-14T16:29:39ZRe: resource hog
thread: resource hogoriginalSNI

1802010-07-14T17:04:02ZRe: stopped prodicing coins
thread: stopped prodicing coinsoriginalSNI

1812010-07-14T17:34:50ZRe: Building Bitcoin 0.3
thread: Building Bitcoin 0.3originalSNI

1822010-07-14T17:38:31ZRe: bitcoin auto-renice-ing
thread: bitcoin auto-renice-ingoriginalSNI

1832010-07-14T18:02:28ZRe: Stuck on 513 blocks
thread: Stuck on 513 blocksoriginalSNI

1842010-07-14T18:25:41ZRe: Error on Ubuntu 10.04
thread: Error on Ubuntu 10.04originalSNI

1852010-07-14T18:45:53ZRe: Runaway CPU usage for 64bit BitCoin (Linux Client)
thread: Runaway CPU usage for 64bit BitCoin (Linux Client)originalSNI

1862010-07-14T18:56:29ZRe: Warning this block was not received by any other nodes
thread: Warning this block was not received by any other nodesoriginalSNI

1872010-07-14T20:25:06ZRe: Hash/sec Throttling for Democracy
thread: Hash/sec Throttling for DemocracyoriginalSNI

1882010-07-14T21:10:52ZRe: Scalability
thread: ScalabilityoriginalSNI

1892010-07-15T00:18:23ZRe: Runaway CPU usage for 64bit BitCoin (Linux Client)
thread: Runaway CPU usage for 64bit BitCoin (Linux Client)originalSNI

1902010-07-15T14:05:20ZRe: [Bitcoin 0.3.0] Runtime error
thread: [Bitcoin 0.3.0] Runtime errororiginalSNI

1912010-07-15T14:33:04ZRe: Static Linux x86_64 bins for those having libcrypto troubles
thread: UPDATED - Linux x64 bins for those having libcrypto and GLIBCXX_3.4.11 troublesoriginalSNI

1922010-07-15T14:59:00ZRe: resource hog
thread: resource hogoriginalSNI

1932010-07-15T17:05:54ZBitcoin 0.3.1 released
thread: Bitcoin 0.3.1 releasedoriginalSNI

1942010-07-15T17:23:48ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

1952010-07-15T17:56:43ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

1962010-07-15T18:30:22ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

1972010-07-15T18:37:13ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

1982010-07-15T18:43:54ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

1992010-07-15T19:12:14ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

2002010-07-15T21:40:34ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2012010-07-15T22:07:35ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2022010-07-15T22:10:19ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2032010-07-15T22:18:26ZRe: "SetIcons(): icon bundle doesn't contain any suitable icon"
thread: "SetIcons(): icon bundle doesn't contain any suitable icon"originalSNI

2042010-07-15T22:22:30ZRe: Runaway CPU usage for 64bit BitCoin (Linux Client)
thread: Runaway CPU usage for 64bit BitCoin (Linux Client)originalSNI

2052010-07-15T23:23:04ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2062010-07-15T23:41:23ZRe: "SetIcons(): icon bundle doesn't contain any suitable icon"
thread: "SetIcons(): icon bundle doesn't contain any suitable icon"originalSNI

2072010-07-16T00:44:32ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2082010-07-16T02:02:07ZRe: Donations to freebitcoins.appspot.com needed!
thread: Donations to freebitcoins.appspot.com needed!originalSNI

2092010-07-16T02:43:29ZRe: "SetIcons(): icon bundle doesn't contain any suitable icon"
thread: "SetIcons(): icon bundle doesn't contain any suitable icon"originalSNI

2102010-07-16T14:46:12ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

2112010-07-16T14:52:04ZRe: Assertion Failure - Ubuntu Lucid
thread: Assertion Failure - Ubuntu LucidoriginalSNI

2122010-07-16T14:55:23ZRe: Fedora 13 libcrypto
thread: Fedora 13 libcryptooriginalSNI

2132010-07-16T15:01:33ZRe: Resending transaction
thread: Resending transactionoriginalSNI

2142010-07-16T15:09:59ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2152010-07-16T15:37:00ZRe: Source code documentation
thread: Source code documentationoriginalSNI

2162010-07-16T16:13:53ZRe: Hash() function not secure
thread: Hash() function not secureoriginalSNI

2172010-07-16T16:47:14ZRe: Request: expected bitcoins per day display
thread: Request: expected bitcoins per day displayoriginalSNI

2182010-07-16T16:56:54ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

2192010-07-16T17:15:47ZRe: Source code documentation
thread: Source code documentationoriginalSNI

2202010-07-16T17:26:17ZRe: 0.3.1 release candidate, please test
thread: Bitcoin 0.3.1 releasedoriginalSNI

2212010-07-16T17:29:28ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

2222010-07-16T17:47:05ZRe: bitcoin trademark?
thread: bitcoin trademark?originalSNI

2232010-07-16T17:58:44ZRe: The dollar cost of bitmining energy
thread: The dollar cost of bitmining energyoriginalSNI

2242010-07-16T18:23:04ZRe: Website integration for bitcoin
thread: Website integration for bitcoinoriginalSNI

2252010-07-16T18:43:51ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

2262010-07-16T19:45:10ZSample account system using JSON-RPC needed
thread: Sample account system using JSON-RPC neededoriginalSNI

2272010-07-16T21:06:57ZRe: Bitcoin 0.3.1 released
thread: Bitcoin 0.3.1 releasedoriginalSNI

2282010-07-16T22:20:09ZRe: A New Currency System for the World
thread: A New Currency System for the WorldoriginalSNI

2292010-07-17T16:06:12ZRe: BUG Report: Rounding glitch
thread: BUG Report: Rounding glitchoriginalSNI

2302010-07-17T16:27:39ZRe: Privacy versus Safety: handling change
thread: Privacy versus Safety: handling changeoriginalSNI

2312010-07-17T16:56:06ZRe: Nenolod, the guy that wants to prove Bitcoin doesn't work.
thread: Nenolod, the guy that wants to prove Bitcoin doesn't work.originalSNI

2322010-07-17T21:35:51ZBitcoin 0.3.2 released
thread: Bitcoin 0.3.2 releasedoriginalSNI

2332010-07-17T22:29:13ZRe: Bitcoin snack machine (fast transaction problem)
thread: Bitcoin snack machine (fast transaction problem)originalSNI

2342010-07-17T22:37:06ZRe: Assertion Failure - Ubuntu Lucid
thread: Assertion Failure - Ubuntu LucidoriginalSNI

2352010-07-17T22:54:24ZRe: Bitcoin 0.3.2 released
thread: Bitcoin 0.3.2 releasedoriginalSNI

2362010-07-17T23:18:30ZRe: Source code documentation
thread: Source code documentationoriginalSNI

2372010-07-17T23:25:16ZRe: Network Size
thread: Network SizeoriginalSNI

2382010-07-18T01:59:15ZRe: Bitcoin snack machine (fast transaction problem)
thread: Bitcoin snack machine (fast transaction problem)originalSNI

2392010-07-18T15:12:54ZRe: Source code documentation
thread: Source code documentationoriginalSNI

2402010-07-18T16:06:16ZRe: URI-scheme for bitcoin
thread: URI-scheme for bitcoinoriginalSNI

2412010-07-18T18:58:21ZRe: Bitcoin 0.3.2 released
thread: Bitcoin 0.3.2 releasedoriginalSNI

2422010-07-18T20:49:22ZJSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2432010-07-18T21:24:09ZRe: MSVC build & SHA-256
thread: Faster SHA-256, MSVC build originalSNI

2442010-07-18T21:56:18ZRe: Nenolod, the guy that wants to prove Bitcoin doesn't work.
thread: Nenolod, the guy that wants to prove Bitcoin doesn't work.originalSNI

2452010-07-18T23:35:27ZRe: Did block generation crawl to a halt?
thread: Did block generation crawl to a halt?originalSNI

2462010-07-19T04:43:13ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2472010-07-19T16:01:38ZWarning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
thread: Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)originalSNI

2482010-07-19T16:20:50ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2492010-07-20T18:38:28ZRe: They want to delete the Wikipedia article
thread: They want to delete the Wikipedia articleoriginalSNI

2502010-07-21T00:05:20ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2512010-07-21T05:51:34ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2522010-07-21T16:07:57ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2532010-07-21T17:31:09ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2542010-07-22T02:34:23ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2552010-07-23T17:07:40ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2562010-07-23T17:14:31ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2572010-07-23T17:23:47ZRe: bitcoind not responding to RPC
thread: bitcoind not responding to RPCoriginalSNI

2582010-07-23T18:24:56ZFaster initial block download (5x faster)
thread: Faster initial block download (5x faster)originalSNI

2592010-07-23T20:13:27ZRe: Faster initial block download
thread: Faster initial block download (5x faster)originalSNI

2602010-07-23T20:39:03ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2612010-07-24T00:59:08ZRe: JSON-RPC Multiple Invocations
thread: JSON-RPC Multiple InvocationsoriginalSNI

2622010-07-24T01:15:58ZRe: bitcoind not responding to RPC
thread: bitcoind not responding to RPCoriginalSNI

2632010-07-24T02:29:09ZRe: Warning: don't use -server or bitcoind on a machine where you web browse
thread: Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)originalSNI

2642010-07-24T03:32:52ZVersion 0.3.2.5 -- please test!
thread: Version 0.3.2.5 -- please test!originalSNI

2652010-07-24T04:04:20ZRe: Reading/Writing Blocks and FLATDATA
thread: Reading/Writing Blocks and FLATDATAoriginalSNI

2662010-07-25T14:46:33ZRe: a simple traffic load test run
thread: a simple traffic load test runoriginalSNI

2672010-07-25T15:29:52ZRe: a simple traffic load test run
thread: a simple traffic load test runoriginalSNI

2682010-07-25T16:55:09ZBitcoin 0.3.3 released -- PLEASE UPGRADE
thread: Bitcoin 0.3.3 released -- PLEASE UPGRADEoriginalSNI

2692010-07-25T17:45:22ZRe: Stealing Coins
thread: Stealing CoinsoriginalSNI

2702010-07-25T19:06:23ZRe: Stealing Coins
thread: Stealing CoinsoriginalSNI

2712010-07-25T20:01:40ZRe: Stealing Coins
thread: Stealing CoinsoriginalSNI

2722010-07-25T20:48:01ZRe: Stealing Coins
thread: Stealing CoinsoriginalSNI

2732010-07-25T21:34:29ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2742010-07-25T21:44:16ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2752010-07-25T21:51:31ZRe: JSON-RPC password
thread: JSON-RPC passwordoriginalSNI

2762010-07-25T22:06:57ZRe: md5?
thread: md5?originalSNI

2772010-07-25T22:27:36ZRe: Stealing Coins
thread: Stealing CoinsoriginalSNI

2782010-07-26T17:23:33Zbitcoind without wxWidgets
thread: bitcoind without wxWidgetsoriginalSNI

2792010-07-26T18:41:31ZRe: Bitcoin x64 for Windows
thread: Bitcoin x64 for WindowsoriginalSNI

2802010-07-27T01:29:42ZRe: Bitcoin x86 for Windows
thread: Bitcoin x86 for WindowsoriginalSNI

2812010-07-27T03:04:58ZRe: Proof-of-work difficulty increasing
thread: Proof-of-work difficulty increasingoriginalSNI

2822010-07-27T18:27:30ZRe: Bitcoin x86 for Windows
thread: Bitcoin x86 for WindowsoriginalSNI

2832010-07-27T19:47:42ZRe: Bitcoin x86 for Windows
thread: Bitcoin x86 for WindowsoriginalSNI

2842010-07-28T20:58:26ZRe: Having problems specifing -datadir
thread: Having problems specifing -datadiroriginalSNI

2852010-07-28T21:23:23ZRe: Build error SVN r115 on my Mac: workaround
thread: Build error SVN r115 on my Mac: workaroundoriginalSNI

2862010-07-29T01:16:23ZRe: Difficulty
thread: DifficultyoriginalSNI

2872010-07-29T02:00:38ZRe: Scalability and transaction rate
thread: Scalability and transaction rateoriginalSNI

2882010-07-29T02:10:46ZRe: wiki registration email?
thread: wiki registration email?originalSNI

2892010-07-29T19:13:06Z*** ALERT *** Upgrade to 0.3.6
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2902010-07-29T19:55:51ZRe: *** ALERT *** version 0.3.6
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2912010-07-29T20:30:15ZRe: *** ALERT *** version 0.3.6
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2922010-07-29T21:20:38ZRe: *** ALERT *** Upgrade to 0.3.6 ASAP!
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2932010-07-29T21:43:15ZRe: *** ALERT *** Upgrade to 0.3.6 ASAP!
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2942010-07-29T22:04:15ZRe: Implementation bug prior to 0.3.6
thread: Implementation bug prior to 0.3.6originalSNI

2952010-07-29T22:08:31ZRe: Transaction disappeared in the void...
thread: Transaction disappeared in the void...originalSNI

2962010-07-29T22:17:24ZRe: Linux distribution download
thread: Linux distribution downloadoriginalSNI

2972010-07-29T23:12:12ZRe: *** ALERT *** Upgrade to 0.3.6 ASAP!
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

2982010-07-30T19:19:05ZRe: Bug: "Immature" coins lost in wallet.dat during transaction
thread: Bug: "Immature" coins lost in wallet.dat during transactionoriginalSNI

2992010-07-30T19:40:54ZRe: [PATCH] implement 'listtransactions'
thread: [PATCH] implement 'xlisttransactions'originalSNI

3002010-07-30T19:53:06ZRe: *** ALERT *** Upgrade to 0.3.6 ASAP!
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

3012010-07-30T21:44:04ZRe: *** ALERT *** Upgrade to 0.3.6 ASAP!
thread: *** ALERT *** Upgrade to 0.3.6originalSNI

3022010-07-31T00:29:20ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3032010-07-31T01:32:08ZWebpage idea: Next predicted difficulty change
thread: Webpage idea: Next predicted difficulty changeoriginalSNI

3042010-07-31T14:38:52ZRe: Linux distribution download
thread: Linux distribution downloadoriginalSNI

3052010-08-02T17:39:27ZRe: Linux version => No GUI after upgrade.  WTF?
thread: Linux version => No GUI after upgrade.  WTF?originalSNI

3062010-08-02T18:02:20ZRe: Mac Client Problems Outlined...
thread: Mac Client Problems Outlined...originalSNI

3072010-08-02T19:02:46ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3082010-08-02T20:22:08ZRe: Protocol Buffers for Bitcoin
thread: Protocol Buffers for BitcoinoriginalSNI

3092010-08-03T20:56:11ZRe: Builds for Ubuntu?
thread: Builds for Ubuntu?originalSNI

3102010-08-03T21:05:08ZRe: Bitcoind x86 binary for CentOS
thread: Bitcoind x86 binary for CentOSoriginalSNI

3112010-08-03T21:26:26ZRe: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)
thread: Authentication, JSON RPC and PythonoriginalSNI

3122010-08-03T22:45:07ZRe: What happens when network is split for prolonged time and reconnected?
thread: What happens when network is split for prolonged time and reconnected?originalSNI

3132010-08-03T23:40:18ZPlease upgrade to 0.3.8!
thread: Please upgrade to 0.3.8!originalSNI

3142010-08-04T00:09:32ZRe: Bitcoind x86 binary for CentOS
thread: Bitcoind x86 binary for CentOSoriginalSNI

3152010-08-04T00:29:37ZRe: Please upgrade to 0.3.8!
thread: Please upgrade to 0.3.8!originalSNI

3162010-08-04T00:40:40ZRe: Building initial transaction trust through "coin ripping"
thread: Building initial transaction trust through "coin ripping"originalSNI

3172010-08-04T16:25:36ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3182010-08-05T16:03:21ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3192010-08-05T16:30:20ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3202010-08-05T16:39:58ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3212010-08-05T17:06:03ZRe: Who's the Spanish jerk draining the Faucet?
thread: Who's the Spanish jerk draining the Faucet?originalSNI

3222010-08-05T17:28:40ZRe: bitcoind transaction to ip address
thread: bitcoind transaction to ip addressoriginalSNI

3232010-08-05T17:38:21ZRe: Transaction Overload Solution
thread: Transaction Overload SolutionoriginalSNI

3242010-08-05T17:49:43ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3252010-08-05T18:08:30ZRe: A proposal for a semi-automated Escrow mechanism
thread: A proposal for a semi-automated Escrow mechanismoriginalSNI

3262010-08-07T16:28:17ZRe: latency and locality
thread: latency and localityoriginalSNI

3272010-08-07T17:46:09ZRe: Bitcoin minting is thermodynamically perverse
thread: Bitcoin minting is thermodynamically perverseoriginalSNI

3282010-08-07T20:04:59ZRe: A proposal for a semi-automated Escrow mechanism
thread: A proposal for a semi-automated Escrow mechanismoriginalSNI

3292010-08-07T20:13:52ZEscrow
thread: EscroworiginalSNI

3302010-08-07T21:16:01ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3312010-08-09T18:50:41ZRe: bitcoin generation broken in 0.3.8?
thread: bitcoin generation broken in 0.3.8?  (64-bit)originalSNI

3322010-08-09T19:46:58ZVersion 0.3.8.1 update for Linux 64-bit
thread: Version 0.3.8.1 update for Linux 64-bitoriginalSNI

3332010-08-09T20:13:26ZRe: What could be the transition plan to Y2038 compliant Bitcoin?
thread: What could be the transition plan to Y2038 compliant Bitcoin? (it already is)originalSNI

3342010-08-09T20:34:06ZRe: bitcoin generation broken in 0.3.8?  (64-bit)
thread: bitcoin generation broken in 0.3.8?  (64-bit)originalSNI

3352010-08-09T20:55:06ZRe: Version 0.3.8.1 update for Linux 64-bit
thread: Version 0.3.8.1 update for Linux 64-bitoriginalSNI

3362010-08-09T20:58:45ZConnection limits
thread: Connection limitsoriginalSNI

3372010-08-09T21:28:39ZRe: Bitcoin minting is thermodynamically perverse
thread: Bitcoin minting is thermodynamically perverseoriginalSNI

3382010-08-10T23:46:00ZRe: Version 0.3.8.1 update for Linux 64-bit
thread: Version 0.3.8.1 update for Linux 64-bitoriginalSNI

3392010-08-11T00:14:22ZRe: Not a suggestion
thread: Not a suggestionoriginalSNI

3402010-08-11T01:30:02ZRe: Escrow
thread: EscroworiginalSNI

3412010-08-11T01:42:30ZRe: Compile error in SVN r127
thread: Compile error in SVN r127originalSNI

3422010-08-11T21:07:59ZRe: Not a suggestion
thread: Not a suggestionoriginalSNI

3432010-08-11T21:46:51ZRe: Lost large number of bitcoins
thread: Lost large number of bitcoinsoriginalSNI

3442010-08-11T22:40:25ZRe: Where is the separate discussion devoted to possible Bitcoin weaknesses.
thread: Where is the separate discussion devoted to possible Bitcoin weaknesses.originalSNI

3452010-08-11T23:28:50ZRe: Flood attack 0.00000001 BC
thread: Flood attack 0.00000001 BCoriginalSNI

3462010-08-12T00:02:06ZRe: BSD detection
thread: BSD detectionoriginalSNI

3472010-08-12T02:46:56ZRe: Not a suggestion
thread: Not a suggestionoriginalSNI

3482010-08-12T21:14:20ZRe: BSD detection
thread: BSD detectionoriginalSNI

3492010-08-12T21:20:31ZBugfixes in SVN rev 130
thread: Bugfixes in SVN rev 130originalSNI

3502010-08-12T21:34:44ZRe: Bitcoin Watchdog Service
thread: Bitcoin Watchdog ServiceoriginalSNI

3512010-08-12T21:43:29ZRe: Having problems specifing -datadir
thread: Having problems specifing -datadiroriginalSNI

3522010-08-12T22:07:23ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3532010-08-13T03:15:23ZRe: Bugfixes in SVN rev 130
thread: Bugfixes in SVN rev 130originalSNI

3542010-08-13T17:09:27ZRe: Bitcoin Watchdog Service
thread: Bitcoin Watchdog ServiceoriginalSNI

3552010-08-13T17:40:00ZVersion 0.3.9 rc1, please test
thread: Version 0.3.9 rc1, please testoriginalSNI

3562010-08-13T19:28:47ZRe: Not a suggestion
thread: Not a suggestionoriginalSNI

3572010-08-13T23:39:14ZRe: Proposed change to sendtoaddress API call
thread: Proposed change to sendtoaddress API calloriginalSNI

3582010-08-14T00:49:18ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3592010-08-14T04:22:29ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3602010-08-14T17:55:37ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3612010-08-14T22:06:13ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3622010-08-15T03:40:29ZRe: 4 hashes parallel on SSE2 CPUs for 0.3.6
thread: 4 hashes parallel on SSE2 CPUs for 0.3.6originalSNI

3632010-08-15T15:52:09Ztcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3642010-08-15T16:37:16ZRe: Potential disaster scenario
thread: Potential disaster scenariooriginalSNI

3652010-08-15T18:11:41ZRe: Version 0.3.9 rc1, please test
thread: Version 0.3.9 rc1, please testoriginalSNI

3662010-08-15T18:23:26ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3672010-08-15T18:43:27ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3682010-08-15T20:59:09ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3692010-08-15T21:06:45ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3702010-08-15T21:23:55ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3712010-08-15T21:40:19ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3722010-08-15T22:58:08ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3732010-08-15T23:17:24ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3742010-08-15T23:36:10ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3752010-08-15T23:37:07ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3762010-08-15T23:48:22ZVersion 0.3.10 - block 74638 overflow PATCH!
thread: Version 0.3.10 - block 74638 overflow PATCH!originalSNI

3772010-08-16T00:28:28ZRe: 0.3.10.1 Question on where block should be
thread: 0.3.10.1 Question on where block should beoriginalSNI

3782010-08-16T00:37:20ZRe: 0.3.10.1 Question on where block should be
thread: 0.3.10.1 Question on where block should beoriginalSNI

3792010-08-16T01:00:45ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3802010-08-16T01:02:24ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3812010-08-16T01:12:05ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3822010-08-16T02:16:10ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3832010-08-16T02:38:21ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3842010-08-16T02:57:57ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3852010-08-16T03:23:04ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3862010-08-16T04:36:59ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3872010-08-16T12:59:38ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3882010-08-16T13:38:01ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

3892010-08-16T15:25:54ZRe: [PATCH] Automatic block validation
thread: [PATCH] Automatic block validationoriginalSNI

3902010-08-16T15:59:25Zblocks minus 1
thread: blocks minus 1originalSNI

3912010-08-16T17:06:27ZRe: blocks minus 1
thread: blocks minus 1originalSNI

3922010-08-16T17:08:02ZRe: [PATCH] Automatic block validation
thread: [PATCH] Automatic block validationoriginalSNI

3932010-08-16T20:07:46ZChecking the block chain on load
thread: Checking the block chain on loadoriginalSNI

3942010-08-16T20:20:53ZRe: checkpointing the block chain
thread: checkpointing the block chainoriginalSNI

3952010-08-16T22:54:55ZRe: overflow bug SERIOUS
thread: overflow bug SERIOUSoriginalSNI

3962010-08-16T23:01:48ZRe: checkpointing the block chain
thread: checkpointing the block chainoriginalSNI

3972010-08-18T16:58:44ZRe: New screenshots to the front page?
thread: New screenshots to the front page?originalSNI

3982010-08-18T18:01:40ZRe: Difficulty: More nodes active, or faster nodes?
thread: Difficulty: More nodes active, or faster nodes?originalSNI

3992010-08-18T18:28:28ZRe: Checking the block chain on load
thread: Checking the block chain on loadoriginalSNI

4002010-08-19T18:44:36ZRe: Convert Bitcoin to GTK: Yes?  No?  wx is better?
thread: Convert Bitcoin to GTK: Yes?  No?  wx is better?originalSNI

4012010-08-19T18:55:48ZRe: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)
thread: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic)originalSNI

4022010-08-19T19:07:43ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

4032010-08-19T19:40:30ZRe: 28 days without generation, i have 4200khash/s
thread: 28 days without generation, i have 4200khash/soriginalSNI

4042010-08-19T20:14:01ZNeed a post writing up some things users should know
thread: Need a post writing up some things users should knoworiginalSNI

4052010-08-19T20:28:50ZRe: Hypothetical question on lost coins / transfers
thread: Hypothetical question on lost coins / transfersoriginalSNI

4062010-08-22T22:51:00ZRe: Need a post writing up some things users should know
thread: Need a post writing up some things users should knoworiginalSNI

4072010-08-22T23:01:02ZRe: 28 days without generation, i have 4200khash/s
thread: 28 days without generation, i have 4200khash/soriginalSNI

4082010-08-22T23:21:50ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

4092010-08-22T23:55:06ZDevelopment of alert system
thread: Development of alert systemoriginalSNI

4102010-08-22T23:57:32ZRe: integrating digital payments into p2p protocols
thread: integrating digital payments into p2p protocolsoriginalSNI

4112010-08-24T22:43:56ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

4122010-08-24T23:51:12ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4132010-08-25T00:06:36ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4142010-08-25T15:17:37ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4152010-08-25T16:40:20ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4162010-08-25T16:56:15ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4172010-08-25T17:59:30ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4182010-08-26T00:08:12ZRe: Development of alert system
thread: Development of alert systemoriginalSNI

4192010-08-26T00:33:28ZRe: RFC: remove DB_PRIVATE flag
thread: RFC: remove DB_PRIVATE flagoriginalSNI

4202010-08-26T00:44:05ZRe: Need a post writing up some things users should know
thread: Need a post writing up some things users should knoworiginalSNI

4212010-08-26T00:57:40ZRe: auto backing up of wallet.dat
thread: auto backing up of wallet.datoriginalSNI

4222010-08-27T00:49:43ZRe: Gentoo Linux Ebuild
thread: Gentoo Linux EbuildoriginalSNI

4232010-08-27T01:13:42ZRe: auto backing up of wallet.dat
thread: auto backing up of wallet.datoriginalSNI

4242010-08-27T02:54:07ZRe: auto backing up of wallet.dat
thread: auto backing up of wallet.datoriginalSNI

4252010-08-27T15:47:57ZRe: auto backing up of wallet.dat
thread: auto backing up of wallet.datoriginalSNI

4262010-08-27T16:13:16ZRe: New web service: obtain dump of bitcoin block NNNN
thread: New web service: obtain dump of bitcoin block NNNNoriginalSNI

4272010-08-27T16:39:26ZRe: Bitcoins are most like shares of common stock
thread: Bitcoins are most like shares of common stockoriginalSNI

4282010-08-27T17:32:07ZRe: Bitcoin does NOT violate Mises' Regression Theorem
thread: Bitcoin does NOT violate Mises' Regression TheoremoriginalSNI

4292010-08-27T21:54:12ZVersion 0.3.11 with upgrade alerts
thread: Version 0.3.11 with upgrade alertsoriginalSNI

4302010-08-28T14:27:15ZRe: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
thread: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10originalSNI

4312010-08-28T14:54:04ZRe: Version 0.3.11 with upgrade alerts
thread: Version 0.3.11 with upgrade alertsoriginalSNI

4322010-08-29T22:14:36ZRe: Big endian code problems
thread: Big endinan code problemsoriginalSNI

4332010-09-05T23:25:32ZRe: CryptoPP Assertion Error
thread: CryptoPP Assertion ErrororiginalSNI

4342010-09-05T23:36:20ZRe: Warning : Check your system   ( Help me )
thread: Warning : Check your system clock (help me)originalSNI

4352010-09-06T21:21:21ZRe: HTTP status codes from the JSON-RPC api
thread: HTTP status codes from the JSON-RPC apioriginalSNI

4362010-09-06T21:41:06ZRe: Warning : Check your system   ( Help me )
thread: Warning : Check your system clock (help me)originalSNI

4372010-09-06T21:45:10ZRe: auto backing up of wallet.dat
thread: auto backing up of wallet.datoriginalSNI

4382010-09-06T21:52:45ZRe: bitcoind as daemon in OSX
thread: bitcoind as daemon in OSXoriginalSNI

4392010-09-07T16:32:21ZRe: Always pay transaction fee?
thread: Always pay transaction fee?originalSNI

4402010-09-07T19:17:55ZVersion 0.3.12
thread: Version 0.3.12originalSNI

4412010-09-08T17:30:14ZRe: Always pay transaction fee?
thread: Always pay transaction fee?originalSNI

4422010-09-08T18:06:04ZRe: Version 0.3.12
thread: Version 0.3.12originalSNI

4432010-09-08T20:27:39ZRe: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?
thread: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?originalSNI

4442010-09-09T01:04:05ZAuto-detect for 128-bit 4-way SSE2
thread: Auto-detect for 128-bit 4-way SSE2originalSNI

4452010-09-10T00:23:24ZRe: Won't let me send coins because it requires a transaction fee?
thread: Won't let me send coins because it requires a transaction fee?originalSNI

4462010-09-10T00:46:37ZRe: Won't let me send coins because it requires a transaction fee?
thread: Won't let me send coins because it requires a transaction fee?originalSNI

4472010-09-10T17:12:33ZRe: Won't let me send coins because it requires a transaction fee?
thread: Won't let me send coins because it requires a transaction fee?originalSNI

4482010-09-10T18:11:06ZRe: Auto-detect for 128-bit 4-way SSE2
thread: Auto-detect for 128-bit 4-way SSE2originalSNI

4492010-09-12T17:40:20ZRe: Running on a port other than 8333
thread: Running on a port other than 8333originalSNI

4502010-09-12T18:00:39ZRe: RFC: remove DB_PRIVATE flag
thread: RFC: remove DB_PRIVATE flagoriginalSNI

4512010-09-12T19:24:53ZRe: Switch to GPL
thread: Switch to GPLoriginalSNI

4522010-09-19T17:22:03ZRe: Memory leak
thread: Memory leakoriginalSNI

4532010-09-19T18:46:46ZRe: Issues building bitcoin on Windows 7
thread: Issues building bitcoin on Windows 7originalSNI

4542010-09-19T19:58:11ZRe: Bug?  /usr/bin/bitcoind ""
thread: Bug?  /usr/bin/bitcoind ""originalSNI

4552010-09-19T21:49:30ZRe: The case for removing IP transactions
thread: The case for removing IP transactionsoriginalSNI

4562010-09-19T22:47:00ZRe: Message Encryption as a built-in feature?
thread: Message Encryption as a built-in feature?originalSNI

4572010-09-23T16:08:35ZRe: Always pay transaction fee?
thread: Always pay transaction fee?originalSNI

4582010-09-23T16:19:08ZInternal version number
thread: Internal version numberoriginalSNI

4592010-09-23T16:28:25ZRe: Warning : Check your system   ( Help me )
thread: Warning : Check your system clock (help me)originalSNI

4602010-09-23T17:56:55ZRe: Porn
thread: PornoriginalSNI

4612010-09-23T18:39:56ZRe: How divisible are bitcoins - the technical side
thread: How divisible are bitcoins - the technical sideoriginalSNI

4622010-09-23T18:46:20ZRe: Internal version number
thread: Internal version numberoriginalSNI

4632010-09-26T17:34:26ZRe: How To Make a Distributed BitCoin Escrow Service
thread: How To Make a Distributed BitCoin Escrow ServiceoriginalSNI

4642010-09-30T16:38:53ZRe: I broke my wallet, sends never confirm now.
thread: I broke my wallet, sends never confirm now.originalSNI

4652010-09-30T16:59:00ZRe: I broke my wallet, sends never confirm now.
thread: I broke my wallet, sends never confirm now.originalSNI

4662010-09-30T17:04:15Z0.3.13 RC1 for Windows, please test
thread: 0.3.13 RC1 for Windows, please testoriginalSNI

4672010-09-30T17:50:32ZRe: BitCoin Wikipedia page DELETED!!!
thread: BitCoin Wikipedia page DELETED!!!originalSNI

4682010-09-30T18:11:56ZRe: Prioritized transactions, and tx fees
thread: Prioritized transactions, and tx feesoriginalSNI

4692010-09-30T18:22:22ZRe: Prioritized transactions, and tx fees
thread: Prioritized transactions, and tx feesoriginalSNI

4702010-09-30T18:27:41ZRe: Remote RPC access
thread: Remote RPC accessoriginalSNI

4712010-10-01T00:32:46ZRe: 0.3.13 RC1 for Windows, please test
thread: 0.3.13 RC1 for Windows, please testoriginalSNI

4722010-10-01T00:34:35ZVersion 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4732010-10-03T18:17:06ZRe: Version 0.3.13
thread: Version 0.3.13, please upgradeoriginalSNI

4742010-10-03T19:39:06ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4752010-10-03T19:49:32ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4762010-10-03T20:02:24ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4772010-10-03T20:54:07ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4782010-10-03T21:07:28ZRe: [PATCH] increase block size limit
thread: [PATCH] increase block size limitoriginalSNI

4792010-10-03T21:30:04ZRe: How to overthrow the GPU Oligarchs
thread: How to overthrow the GPU OligarchsoriginalSNI

4802010-10-03T21:43:20ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4812010-10-03T22:07:00ZRe: Memory leak
thread: Memory leakoriginalSNI

4822010-10-03T23:46:19ZRe: Version 0.3.13, please upgrade
thread: Version 0.3.13, please upgradeoriginalSNI

4832010-10-04T01:44:41ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

4842010-10-04T19:21:01ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

4852010-10-04T19:48:40ZRe: [PATCH] increase block size limit
thread: [PATCH] increase block size limitoriginalSNI

4862010-10-06T15:42:39ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

4872010-10-06T16:54:23ZRe: I broke my wallet, sends never confirm now.
thread: I broke my wallet, sends never confirm now.originalSNI

4882010-10-06T17:36:41ZRe: Tor connections not working reliably, many seednodes offline
thread: Tor connections not working reliably, many seednodes offlineoriginalSNI

4892010-10-06T23:10:31ZRe: The Niche List
thread: The Niche ListoriginalSNI

4902010-10-09T20:19:33ZKey pool feature for safer wallet backup
thread: Key pool feature for safer wallet backuporiginalSNI

4912010-10-21T16:39:27ZVersion 0.3.14
thread: Version 0.3.14originalSNI

4922010-10-21T22:50:47ZRe: Website and software translations
thread: Website and software translationsoriginalSNI

4932010-10-23T18:22:49ZRe: ERROR - PLEASE HELP ME!
thread: ERROR - PLEASE HELP ME!originalSNI

4942010-10-23T18:38:04ZRe: ERROR - PLEASE HELP ME!
thread: ERROR - PLEASE HELP ME!originalSNI

4952010-10-23T18:52:02ZRe: Win7 64bit since last patch Tues now crashes
thread: Win7 64bit since last patch Tues now crashesoriginalSNI

4962010-10-23T19:02:57ZRe: Suggestion: Allow short messages to be sent together with bitcoins ?
thread: Suggestion: Allow short messages to be sent together with bitcoins ?originalSNI

4972010-10-24T19:17:51ZRe: Multiple Wallets, one computer
thread: Multiple Wallets, one computer (multiple accounts)originalSNI

4982010-10-25T16:53:53ZRe: Multiple Wallets, one computer
thread: Multiple Wallets, one computer (multiple accounts)originalSNI

4992010-10-25T17:27:47ZRe: Win7 64bit since last patch Tues now crashes
thread: Win7 64bit since last patch Tues now crashesoriginalSNI

5002010-11-13T00:55:51ZRe: New icon/logo
thread: New icon/logooriginalSNI

5012010-11-13T23:25:26ZRe: Some testing that I did on the testnetwork, my findings.
thread: Some testing that I did on the testnetwork, my findings.originalSNI

5022010-11-13T23:26:40ZVersion 0.3.15
thread: Version 0.3.15originalSNI

5032010-11-14T16:53:19ZRe: Some testing that I did on the testnetwork, my findings.
thread: Some testing that I did on the testnetwork, my findings.originalSNI

5042010-11-15T18:37:44ZRe: Need OP_BLOCKNUMBER to allow "time" limited transactions
thread: Need OP_BLOCKNUMBER to allow "time" limited transactionsoriginalSNI

5052010-11-19T23:50:24ZRe: Transaction / spam flood attack currently under way
thread: Transaction / spam flood attack currently under wayoriginalSNI

5062010-11-20T17:24:20ZRe: OpenCL miner for the masses
thread: python OpenCL bitcoin mineroriginalSNI

5072010-11-23T19:50:12ZNew getwork
thread: New getworkoriginalSNI

5082010-11-23T20:55:27ZRe: New getwork
thread: New getworkoriginalSNI

5092010-11-24T17:21:01ZRe: New getwork
thread: New getworkoriginalSNI

5102010-11-24T17:53:09ZRe: OpenCL miner for the masses
thread: python OpenCL bitcoin mineroriginalSNI

5112010-11-25T17:51:39ZRe: RFC: ship block chain 1-74000 with release tarballs?
thread: RFC: ship block chain 1-74000 with release tarballs?originalSNI

5122010-11-25T20:07:36ZVersion 0.3.17
thread: Version 0.3.17originalSNI

5132010-11-26T17:32:01ZRe: RFC: ship block chain 1-74000 with release tarballs?
thread: RFC: ship block chain 1-74000 with release tarballs?originalSNI

5142010-11-26T18:23:30ZRe: Version 0.3.17
thread: Version 0.3.17originalSNI

5152010-11-26T21:31:13ZRe: New getwork
thread: New getworkoriginalSNI

5162010-11-26T22:02:41ZRe: New demonstration CPU miner available
thread: New demonstration CPU miner availableoriginalSNI

5172010-11-28T16:03:30ZRe: Cooperative mining
thread: [2.5+ EH] Slush Pool (slushpool.com); World's First Mining PooloriginalSNI

5182010-11-28T17:13:01ZRe: RFC: ship block chain 1-74000 with release tarballs?
thread: RFC: ship block chain 1-74000 with release tarballs?originalSNI

5192010-11-28T18:06:39ZRe: Is safe running bitcoins with the same wallet on more computers simultaneously?
thread: Is safe running bitcoins with the same wallet on more computers simultaneously?originalSNI

5202010-11-29T20:19:12ZRe: RFC: ship block chain 1-74000 with release tarballs?
thread: RFC: ship block chain 1-74000 with release tarballs?originalSNI

5212010-11-30T19:02:31ZRe: Incompatible wallet format with latest bitcoin-git ?
thread: Incompatible wallet format with latest bitcoin-git ?originalSNI

5222010-12-01T21:25:39ZRe: RFC: ship block chain 1-74000 with release tarballs?
thread: RFC: ship block chain 1-74000 with release tarballs?originalSNI

5232010-12-05T09:08:08ZRe: Wikileaks contact info?
thread: Wikileaks contact info?originalSNI

5242010-12-08T20:21:49ZRe: JSON-RPC method idea: list transactions newer than a given txid
thread: JSON-RPC method idea: list transactions newer than a given txidoriginalSNI

5252010-12-08T22:36:45ZRe: JSON-RPC method idea: list transactions newer than a given txid
thread: JSON-RPC method idea: list transactions newer than a given txidoriginalSNI

5262010-12-08T23:19:24ZVersion 0.3.18
thread: Version 0.3.18originalSNI

5272010-12-09T00:12:17ZRe: JSON-RPC method idea: list transactions newer than a given txid
thread: JSON-RPC method idea: list transactions newer than a given txidoriginalSNI

5282010-12-09T14:37:05ZRe: Version 0.3.18
thread: Version 0.3.18originalSNI

5292010-12-09T15:17:53ZRe: Version 0.3.18
thread: Version 0.3.18originalSNI

5302010-12-09T18:08:08ZRe: JSON-RPC method idea: list transactions newer than a given txid
thread: JSON-RPC method idea: list transactions newer than a given txidoriginalSNI

5312010-12-09T18:28:45ZRe: Automated nightly builds
thread: Automated nightly buildsoriginalSNI

5322010-12-09T21:02:42ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5332010-12-09T22:46:50ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5342010-12-09T23:58:54ZRe: Fees in BitDNS confusion
thread: Fees in BitDNS confusionoriginalSNI

5352010-12-10T17:29:28ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5362010-12-10T19:21:03ZAccounts example code
thread: Accounts example codeoriginalSNI

5372010-12-10T19:55:12ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5382010-12-10T20:19:39ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5392010-12-11T13:08:30ZRe: BitDNS and Generalizing Bitcoin
thread: BitDNS and Generalizing BitcoinoriginalSNI

5402010-12-11T13:32:37ZRe: Bitcoin and buffer overflow attacks
thread: Bitcoin and buffer overflow attacksoriginalSNI

5412010-12-11T22:07:04ZRe: minimalistic bitcoin client on D language?
thread: minimalistic bitcoin client on D language?originalSNI

5422010-12-11T23:39:16ZRe: PC World Article on Bitcoin
thread: PC World Article on BitcoinoriginalSNI

5432010-12-12T18:22:33ZAdded some DoS limits, removed safe mode (0.3.19)
thread: Added some DoS limits, removed safe mode (0.3.19)originalSNI

5. Welcome to the new Bitcoin forum!

Poster: satoshi · Date: 2009-11-22T18:04:28Z · Thread: Welcome to the new Bitcoin forum!
Original: https://bitcointalk.org/index.php?topic=5.msg28#msg28
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/5/

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/

6. Repost: Bitcoin Maturation

Poster: satoshi · Date: 2009-11-22T18:31:44Z · Thread: Repost: Bitcoin Maturation
Original: https://bitcointalk.org/index.php?topic=6.msg29#msg29
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/6/

--------------------
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.

7. Repost: Request: Make this anonymous?

Poster: satoshi · Date: 2009-11-22T18:32:00Z · Thread: Repost: Request: Make this anonymous?
Original: https://bitcointalk.org/index.php?topic=7.msg30#msg30
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/7/

--------------------
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.

8. Re: Repost: Bitcoin Maturation

Poster: satoshi · Date: 2009-11-22T18:34:21Z · Thread: Repost: Bitcoin Maturation
Original: https://bitcointalk.org/index.php?topic=6.msg31#msg31
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/8/

It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.

1) During generation (when the status bar says "Generating" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.

2) When you successfully generate a block, it is immediately broadcast to the network.  Other nodes must receive it and link to it for it to be accepted as the new latest block.

Think of it as a cooperative effort to make a chain.  When you add a link, you must first find the current end of the chain.  If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.

After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent.  Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours.  You don't have to be online during that time.

9. Re: Repost: Request: Make this anonymous?

Poster: satoshi · Date: 2009-11-22T18:35:15Z · Thread: Repost: Request: Make this anonymous?
Original: https://bitcointalk.org/index.php?topic=7.msg32#msg32
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/9/

There will be a proxy setting in version 0.2 so you can connect through TOR.  I've done a careful scrub to make sure it doesn't use DNS or do anything that would leak your IP while in proxy mode.

10. Repost: How anonymous are bitcoins?

Poster: satoshi · Date: 2009-11-25T18:15:57Z · Thread: Repost: How anonymous are bitcoins?
Original: https://bitcointalk.org/index.php?topic=8.msg33#msg33
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/10/

--------------------
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)?

11. Re: Repost: How anonymous are bitcoins?

Poster: satoshi · Date: 2009-11-25T18:17:23Z · Thread: Repost: How anonymous are bitcoins?
Original: https://bitcointalk.org/index.php?topic=8.msg34#msg34
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/11/

> 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=<someipaddress>

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.

12. Repost: Linux/UNIX compile

Poster: satoshi · Date: 2009-11-27T17:17:22Z · Thread: Repost: Linux/UNIX compile
Original: https://bitcointalk.org/index.php?topic=9.msg36#msg36
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/12/

--------------------
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.

13. Re: Repost: Linux/UNIX compile

Poster: satoshi · Date: 2009-11-27T17:27:09Z · Thread: Repost: Linux/UNIX compile
Original: https://bitcointalk.org/index.php?topic=9.msg37#msg37
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/13/

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.

14. [OLD THREAD] Bitcoin version 0.2 development status

Poster: satoshi · Date: 2009-11-27T22:48:39Z · Thread: [OLD THREAD] Bitcoin version 0.2 development status
Original: https://bitcointalk.org/index.php?topic=10.msg38#msg38
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/14/

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

15. Re: A few suggestions

Poster: satoshi · Date: 2009-12-09T18:45:10Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg41#msg41
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/15/

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?

16. Re: A few suggestions

Poster: satoshi · Date: 2009-12-10T19:31:49Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg45#msg45
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/16/

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.

17. Re: Questions about Bitcoin

Poster: satoshi · Date: 2009-12-10T20:49:02Z · Thread: Questions about Bitcoin
Original: https://bitcointalk.org/index.php?topic=13.msg46#msg46
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/17/

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.

18. Re: Questions about Bitcoin

Poster: satoshi · Date: 2009-12-11T17:58:57Z · Thread: Questions about Bitcoin
Original: https://bitcointalk.org/index.php?topic=13.msg49#msg49
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/18/

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.

19. Re: A few suggestions

Poster: satoshi · Date: 2009-12-11T19:27:55Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg50#msg50
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/19/

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!

20. Re: A few suggestions

Poster: satoshi · Date: 2009-12-12T17:52:44Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg54#msg54
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/20/

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.

21. Re: A few suggestions

Poster: satoshi · Date: 2009-12-12T18:17:10Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg55#msg55
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/21/

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! [image: Wink; source: /static/img/emoticons/wink.gif] 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.

22. Re: A few suggestions

Poster: satoshi · Date: 2009-12-13T16:51:25Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg62#msg62
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/22/

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.

23. Re: A few suggestions

Poster: satoshi · Date: 2009-12-14T17:15:56Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg67#msg67
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/23/

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<char, std::char_traits<char>, std::allocator<char> >&)'
/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.  That's used everywhere, the conversion needs to work.

wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile.  You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.

It's probably some wxWidgets compile defines or build configuration.  What "configure" options did you use?

I'm not sure __WXMAC__ is the right define.  It may be the Mac Classic support that's complicating wxString, and we only want OSX.  Try __WXOSX__ (or see below)

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:

    * If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.
    * If you want to test for any GUI Mac port under OS X, use __WXOSX__.
    * If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__"

24. Re: A few suggestions

Poster: satoshi · Date: 2009-12-15T20:37:32Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg70#msg70
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/24/

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?  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.  Is there anything in debug.log?  If you touched the file, that sounds like something is there.  Does the program have write access to the file?

25. Bitcoin 0.2 released!

Poster: satoshi · Date: 2009-12-16T22:45:36Z · Thread: Bitcoin 0.2 released!
Original: https://bitcointalk.org/index.php?topic=16.msg73#msg73
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/25/

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.

26. Re: A few suggestions

Poster: satoshi · Date: 2009-12-17T18:38:06Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg77#msg77
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/26/

That's good, is it running fine on FreeBSD?

I committed the changes to headers.h.  For consistency, I used __BSD__.  The complete list of defines is at http://docs.wxwidgets.org/stable/wx_cppconst.html
#ifdef __BSD__
#include <netinet/in.h>
#endif

malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble.

27. Re: A few suggestions

Poster: satoshi · Date: 2009-12-18T17:37:48Z · Thread: A few suggestions
Original: https://bitcointalk.org/index.php?topic=12.msg79#msg79
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/27/

What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized.  The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI.  Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty.

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.  I figured Linux people wouldn't mind doing that manually anyway.  I guess they need to know about the -min switch to do it right.

You can locate the data directory where you want with the "-datadir=<directory>" switch.  I know someone is already doing that to put it on a TrueCrypt USB drive.

28. Re: Is my second Transaction working correctly? +Transfer Question

Poster: satoshi · Date: 2010-01-05T20:00:46Z · Thread: Is my second Transaction working correctly? +Transfer Question
Original: https://bitcointalk.org/index.php?topic=17.msg85#msg85
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/28/

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.

29. Re: 64bit support

Poster: satoshi · Date: 2010-01-14T20:17:20Z · Thread: 64bit support
Original: https://bitcointalk.org/index.php?topic=18.msg97#msg97
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/29/

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.

30. Re: Number of connections?

Poster: satoshi · Date: 2010-01-20T20:07:15Z · Thread: Number of connections?
Original: https://bitcointalk.org/index.php?topic=21.msg112#msg112
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/30/

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.

31. Re: TOR and I2P

Poster: satoshi · Date: 2010-01-20T22:05:28Z · Thread: TOR and I2P
Original: https://bitcointalk.org/index.php?topic=22.msg113#msg113
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/31/

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.

32. Re: Bitcoin crash when sending coins

Poster: satoshi · Date: 2010-01-27T21:52:27Z · Thread: Bitcoin crash when sending coins
Original: https://bitcointalk.org/index.php?topic=27.msg156#msg156
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/32/

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.

33. Re: A newb's test - anyone want to buy a picture for $1?

Poster: satoshi · Date: 2010-01-28T01:01:48Z · Thread: A newb's test - anyone want to buy a picture for $1?
Original: https://bitcointalk.org/index.php?topic=25.msg159#msg159
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/33/

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.

34. Re: Blocks never stop generating?

Poster: satoshi · Date: 2010-01-28T01:08:33Z · Thread: Blocks never stop generating?
Original: https://bitcointalk.org/index.php?topic=28.msg160#msg160
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/34/

Where it says "# blocks" in the status column I'm changing it to say "# confirmations".  That might be clearer.

If you doubleclick on the transaction you get a little more information.

35. Re: Bitcoin crash when sending coins

Poster: satoshi · Date: 2010-01-28T23:08:02Z · Thread: Bitcoin crash when sending coins
Original: https://bitcointalk.org/index.php?topic=27.msg170#msg170
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/35/

The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent.  That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent.  Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.

A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem.  With resync, you could do about the same thing by sending all the money from one wallet to the other.  The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.

36. Re: Payment server

Poster: satoshi · Date: 2010-01-28T23:26:09Z · Thread: Payment server
Original: https://bitcointalk.org/index.php?topic=29.msg172#msg172
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/36/

That's the right way to do it as riX says.  The software can generate a new bitcoin address whenever you need one for each payment.  "Please send X bc to [single-use bitcoin address] to complete your order"  When the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.

Adding command line support is a high priority.  It's just a matter of getting the time to code it.

37. Re: A newb's test - anyone want to buy a picture for $1?

Poster: satoshi · Date: 2010-01-29T00:22:13Z · Thread: A newb's test - anyone want to buy a picture for $1?
Original: https://bitcointalk.org/index.php?topic=25.msg173#msg173
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/37/

The recommended ways to do a payment for an order:
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address.  This will be the standard way for website software to do it.

RSA vs ECDSA: it's not the size of the executable but the size of the data.  I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger.  Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part.  In that case, everything that's been implemented up to now would be implemented exactly as it has been.

We can figure out the best way to do this much later.  It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message.  The message would have to include a salt so nobody could brute force the hash to reveal a short message.

38. Re: 64bit support

Poster: satoshi · Date: 2010-01-29T00:42:49Z · Thread: 64bit support
Original: https://bitcointalk.org/index.php?topic=18.msg174#msg174
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/38/

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.

39. Re: Bitcoin crash when sending coins

Poster: satoshi · Date: 2010-02-03T23:29:57Z · Thread: Bitcoin crash when sending coins
Original: https://bitcointalk.org/index.php?topic=27.msg219#msg219
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/39/

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).

40. Re: Win32 CPU Cycles vs 'Live Protection' Engines ?

Poster: satoshi · Date: 2010-02-03T23:36:54Z · Thread: Win32 CPU Cycles vs 'Live Protection' Engines ?
Original: https://bitcointalk.org/index.php?topic=35.msg220#msg220
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/40/

Thanks for that.  Which version of Windows?

41. Re: Questions about Addresses

Poster: satoshi · Date: 2010-02-04T00:07:07Z · Thread: Questions about Addresses
Original: https://bitcointalk.org/index.php?topic=34.msg222#msg222
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/41/

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".

42. Re: TOR and I2P

Poster: satoshi · Date: 2010-02-04T00:30:50Z · Thread: TOR and I2P
Original: https://bitcointalk.org/index.php?topic=22.msg223#msg223
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/42/

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.

43. Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-05T19:19:12Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg249#msg249
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/43/

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%

44. Re: Questions about Addresses

Poster: satoshi · Date: 2010-02-05T19:44:46Z · Thread: Questions about Addresses
Original: https://bitcointalk.org/index.php?topic=34.msg250#msg250
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/44/

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.

45. Re: Repost: Request: Make this anonymous?

Poster: satoshi · Date: 2010-02-06T21:06:32Z · Thread: Repost: Request: Make this anonymous?
Original: https://bitcointalk.org/index.php?topic=7.msg264#msg264
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/45/

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.

46. Re: How divisible are bitcoins and other market/economic questions

Poster: satoshi · Date: 2010-02-06T23:25:53Z · Thread: How divisible are bitcoins and other market/economic questions
Original: https://bitcointalk.org/index.php?topic=44.msg267#msg267
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/46/

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.

47. Re: Make your "we accept Bitcoin" logo

Poster: satoshi · Date: 2010-02-08T01:22:29Z · Thread: Make your "we accept Bitcoin" logo
Original: https://bitcointalk.org/index.php?topic=45.msg278#msg278
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/47/

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.

48. Bitcoin client and website translation

Poster: satoshi · Date: 2010-02-08T01:27:02Z · Thread: Bitcoin client and website translation
Original: https://bitcointalk.org/index.php?topic=47.msg279#msg279
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/48/

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

49. Bitcoin client and website translation

Poster: satoshi · Date: 2010-02-08T16:10:37Z · Thread: Bitcoin client and website translation
Original: https://bitcointalk.org/index.php?topic=47.msg283#msg283
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/49/

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.

50. Re: Simple to implement feature requests

Poster: satoshi · Date: 2010-02-08T16:37:24Z · Thread: Simple to implement feature requests
Original: https://bitcointalk.org/index.php?topic=46.msg284#msg284
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/50/

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

51. Re: DEB Package?

Poster: satoshi · Date: 2010-02-12T02:33:02Z · Thread: DEB Package?
Original: https://bitcointalk.org/index.php?topic=49.msg315#msg315
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/51/

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.

52. Re: What's with this odd generation?

Poster: satoshi · Date: 2010-02-12T03:08:08Z · Thread: What's with this odd generation?
Original: https://bitcointalk.org/index.php?topic=48.msg316#msg316
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/52/

There's a small transaction fee for very large transactions.  The node that generates the block that contains the transaction gets the fee.

If the same money gets sent again, it won't incur the fee again.  If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together.  After that it's just one line to send the combined unit.

53. Re: DEB Package?

Poster: satoshi · Date: 2010-02-12T15:57:37Z · Thread: DEB Package?
Original: https://bitcointalk.org/index.php?topic=49.msg322#msg322
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/53/

Quote from: soultcer on February 12, 2010, 02:31:50 PM
If you want, I can provide you with a precompiled binary.

Am I missing something?  Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?

The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.

Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it.

54. Re: Repost: Request: Make this anonymous?

Poster: satoshi · Date: 2010-02-12T17:28:32Z · Thread: Repost: Request: Make this anonymous?
Original: https://bitcointalk.org/index.php?topic=7.msg324#msg324
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/54/

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.

55. Re: DEB Package?

Poster: satoshi · Date: 2010-02-13T01:38:37Z · Thread: DEB Package?
Original: https://bitcointalk.org/index.php?topic=49.msg326#msg326
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/55/

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)

There's one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason.  -- fixed

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.

56. Re: What's with this odd generation?

Poster: satoshi · Date: 2010-02-14T06:28:03Z · Thread: What's with this odd generation?
Original: https://bitcointalk.org/index.php?topic=48.msg327#msg327
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/56/

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.

57. Re: What's with this odd generation?

Poster: satoshi · Date: 2010-02-14T15:52:23Z · Thread: What's with this odd generation?
Original: https://bitcointalk.org/index.php?topic=48.msg329#msg329
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/57/

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.

58. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-15T06:28:38Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg346#msg346
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/58/

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.

59. Re: Setting up multiple bitcoin machines behind NAT

Poster: satoshi · Date: 2010-02-16T01:34:56Z · Thread: Setting up multiple bitcoin machines behind NAT
Original: https://bitcointalk.org/index.php?topic=54.msg360#msg360
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/59/

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=<the IP of the first computer>

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=<IP1> -connect=<IP2>

60. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-16T17:36:40Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg376#msg376
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/60/

Quote from: Suggester on February 16, 2010, 02:15:49 AM
Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create ฿50.00! With older PCs it will take forever. People like to feel that they "own" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making ฿50 every 20 hours, make ฿5 every 2 hours?
I thought about that but there wasn't a practical way to do smaller increments.  The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.

The algorithm aims for an average of 6 blocks per hour.  If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long.  It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.

61. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-17T17:58:03Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg388#msg388
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/61/

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.

62. Re: Bitcoin client and website translation

Poster: satoshi · Date: 2010-02-17T19:19:43Z · Thread: Bitcoin client and website translation
Original: https://bitcointalk.org/index.php?topic=47.msg389#msg389
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/62/

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\<langcode>\LC_MESSAGES\bitcoin.mo

<langcode> 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/<langcode>/LC_MESSAGES/bitcoin.mo
/usr/local/share/locale/<langcode>/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\<lang>\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).

63. Re: Number of connections

Poster: satoshi · Date: 2010-02-21T03:43:48Z · Thread: Number of connections
Original: https://bitcointalk.org/index.php?topic=58.msg413#msg413
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/63/

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.

64. Post your static IP

Poster: satoshi · Date: 2010-02-21T04:19:53Z · Thread: Post your static IP
Original: https://bitcointalk.org/index.php?topic=59.msg414#msg414
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/64/

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.

65. Re: Current Bitcoin economic model is unsustainable

Poster: satoshi · Date: 2010-02-21T05:44:24Z · Thread: The current Bitcoin economic model doesn't work
Original: https://bitcointalk.org/index.php?topic=57.msg415#msg415
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/65/

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.

66. UI improvements

Poster: satoshi · Date: 2010-02-21T21:48:01Z · Thread: UI improvements
Original: https://bitcointalk.org/index.php?topic=60.msg426#msg426
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/66/

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.

67. Re: generation slowed down dramatically

Poster: satoshi · Date: 2010-02-23T00:49:56Z · Thread: generation slowed down dramatically
Original: https://bitcointalk.org/index.php?topic=61.msg433#msg433
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/67/

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.

68. Re: UI improvements

Poster: satoshi · Date: 2010-02-23T01:16:28Z · Thread: UI improvements
Original: https://bitcointalk.org/index.php?topic=60.msg434#msg434
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/68/

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.

69. Re: Bitcoin Address Collisions

Poster: satoshi · Date: 2010-02-23T16:26:09Z · Thread: Bitcoin Address Collisions
Original: https://bitcointalk.org/index.php?topic=62.msg443#msg443
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/69/

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.

70. Re: UI improvements

Poster: satoshi · Date: 2010-02-23T16:53:27Z · Thread: UI improvements
Original: https://bitcointalk.org/index.php?topic=60.msg446#msg446
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/70/

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.

71. Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-23T22:15:41Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg452#msg452
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/71/

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 <command> [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.

72. Re: Bitcoin Address Collisions

Poster: satoshi · Date: 2010-02-23T22:24:00Z · Thread: Bitcoin Address Collisions
Original: https://bitcointalk.org/index.php?topic=62.msg453#msg453
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/72/

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.

73. Re: URI-scheme for bitcoin

Poster: satoshi · Date: 2010-02-24T05:57:43Z · Thread: URI-scheme for bitcoin
Original: https://bitcointalk.org/index.php?topic=55.msg481#msg481
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/73/

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.

74. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-24T06:17:23Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg482#msg482
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/74/

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.

75. New icon/logo

Poster: satoshi · Date: 2010-02-24T21:24:23Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg504#msg504
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/75/

New icons, what do you think?  Better than the old one?

[image; source: https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin16.4.png&t=589&c=nbQh6wpencehMQ]  [image; source: https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin20.4.png&t=589&c=fFlL6ruPQ7IGHA]  [image; source: https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin32.5.png&t=589&c=U22oaajL6w5RyA]  [image; source: https://ip.bitcointalk.org/?u=http%3A%2F%2Fwww.bitcoin.org%2Fdownload%2Fbitcoin48.5.png&t=589&c=EvOpR1UIrHi0BA]

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.

76. Re: Make your "we accept Bitcoin" logo

Poster: satoshi · Date: 2010-02-24T21:53:52Z · Thread: Make your "we accept Bitcoin" logo
Original: https://bitcointalk.org/index.php?topic=45.msg507#msg507
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/76/

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.

77. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-24T22:08:55Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg509#msg509
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/77/

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.

78. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-24T22:42:24Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg510#msg510
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/78/

The automatic adjustment happened earlier today.

24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000

24/02/2010  3.78  +49%

I updated the first post.

79. Re: New icon/logo

Poster: satoshi · Date: 2010-02-25T01:56:24Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg521#msg521
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/79/

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.

80. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-25T22:54:17Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg539#msg539
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/80/

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.

81. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-02-25T23:06:29Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg540#msg540
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/81/

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.

82. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-26T16:29:21Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg555#msg555
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/82/

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.

83. Re: New icon/logo

Poster: satoshi · Date: 2010-02-26T23:17:19Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg561#msg561
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/83/

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?

84. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-02-26T23:48:44Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg562#msg562
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/84/

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.

85. Re: New icon/logo

Poster: satoshi · Date: 2010-02-27T04:28:29Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg566#msg566
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/85/

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.

86. Re: wxWidgets 2.9.0

Poster: satoshi · Date: 2010-02-27T21:22:53Z · Thread: wxWidgets 2.9.0
Original: https://bitcointalk.org/index.php?topic=65.msg571#msg571
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/86/

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.

87. Re: New icon/logo

Poster: satoshi · Date: 2010-03-02T02:33:05Z · Thread: New icon/logo
Original: https://bitcointalk.org/index.php?topic=64.msg588#msg588
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/87/

We have the standard icon sizes, and the full size scales nicely to anything else.

I added the full size to the first post.

88. Re: Money Transfer Regulations

Poster: satoshi · Date: 2010-03-03T04:28:56Z · Thread: Money Transfer Regulations
Original: https://bitcointalk.org/index.php?topic=69.msg614#msg614
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/88/

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.

89. Re: Command Line and JSON-RPC

Poster: satoshi · Date: 2010-03-05T01:46:25Z · Thread: Command Line and JSON-RPC
Original: https://bitcointalk.org/index.php?topic=63.msg633#msg633
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/89/

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.

90. Re: bitcoin auto-renice-ing

Poster: satoshi · Date: 2010-03-15T18:44:12Z · Thread: bitcoin auto-renice-ing
Original: https://bitcointalk.org/index.php?topic=72.msg717#msg717
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/90/

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);

91. Idea for file hosting and proxy services

Poster: satoshi · Date: 2010-03-15T19:16:56Z · Thread: Idea for file hosting and proxy services
Original: https://bitcointalk.org/index.php?topic=83.msg719#msg719
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/91/

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.

92. Re: On IRC bootstrapping

Poster: satoshi · Date: 2010-03-16T19:48:47Z · Thread: On IRC bootstrapping
Original: https://bitcointalk.org/index.php?topic=84.msg729#msg729
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/92/

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. [image: Smiley; source: /static/img/emoticons/smiley.gif]  Bitcoin's IRC client implementation is already thoroughly tested.

93. Re: Idea for file hosting service

Poster: satoshi · Date: 2010-03-16T20:17:34Z · Thread: Idea for file hosting and proxy services
Original: https://bitcointalk.org/index.php?topic=83.msg731#msg731
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/93/

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?

94. Re: who is bitcoin.com

Poster: satoshi · Date: 2010-03-23T15:22:41Z · Thread: who is bitcoin.com
Original: https://bitcointalk.org/index.php?topic=88.msg806#msg806
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/94/

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.

95. Re: Exchange Methods

Poster: satoshi · Date: 2010-03-23T17:35:34Z · Thread: Exchange Methods
Original: https://bitcointalk.org/index.php?topic=87.msg807#msg807
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/95/

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.

96. Re: Idea for file hosting and proxy services

Poster: satoshi · Date: 2010-03-24T18:01:57Z · Thread: Idea for file hosting and proxy services
Original: https://bitcointalk.org/index.php?topic=83.msg809#msg809
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/96/

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)

97. Re: Idea for file hosting and proxy services

Poster: satoshi · Date: 2010-03-24T18:02:55Z · Thread: Idea for file hosting and proxy services
Original: https://bitcointalk.org/index.php?topic=83.msg810#msg810
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/97/

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.

98. Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add

Poster: satoshi · Date: 2010-05-16T21:01:44Z · Thread: Could the bitcoin network be destroyed by someone generating endless bitcoin add
Original: https://bitcointalk.org/index.php?topic=130.msg1130#msg1130
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/98/

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.

99. Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?

Poster: satoshi · Date: 2010-05-16T21:37:36Z · Thread: For a website taking payments with bitcoins, better: IP or bitcoin addresses?
Original: https://bitcointalk.org/index.php?topic=129.msg1131#msg1131
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/99/

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.

100. Re: URI-scheme for bitcoin

Poster: satoshi · Date: 2010-05-16T22:37:21Z · Thread: URI-scheme for bitcoin
Original: https://bitcointalk.org/index.php?topic=55.msg1132#msg1132
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/100/

Quote from: Karmicads on May 01, 2010, 06:06:53 AM
A freenet URI is like this:

http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.

Quote from: DataWraith on May 02, 2010, 11:13:09 AM
A bitcoin-link should be more like mailto: than magnet: IMHO.

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.

101. Re: Exception: 9key_error error

Poster: satoshi · Date: 2010-05-16T22:53:59Z · Thread: Exception: 9key_error error
Original: https://bitcointalk.org/index.php?topic=135.msg1133#msg1133
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/101/

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.

102. Re: removing bitcoin addresses

Poster: satoshi · Date: 2010-05-16T23:34:40Z · Thread: removing bitcoin addresses
Original: https://bitcointalk.org/index.php?topic=101.msg1134#msg1134
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/102/

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.

103. Re: Setting up multiple bitcoin machines behind NAT

Poster: satoshi · Date: 2010-05-16T23:56:03Z · Thread: Setting up multiple bitcoin machines behind NAT
Original: https://bitcointalk.org/index.php?topic=54.msg1135#msg1135
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/103/

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.

104. Re: Is there a way to automate bitcoin payments for a website?

Poster: satoshi · Date: 2010-05-18T02:58:11Z · Thread: Is there a way to automate bitcoin payments for a website?
Original: https://bitcointalk.org/index.php?topic=112.msg1143#msg1143
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/104/

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.

105. Re: Ummmm... where did my bitcoins go?

Poster: satoshi · Date: 2010-05-18T20:06:46Z · Thread: Ummmm... where did my bitcoins go?
Original: https://bitcointalk.org/index.php?topic=125.msg1149#msg1149
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/105/

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.

106. Re: We accept Bitcoins

Poster: satoshi · Date: 2010-05-20T21:43:42Z · Thread: We accept Bitcoins [moved to bitcoin.it/wiki/Trade]
Original: https://bitcointalk.org/index.php?topic=30.msg1169#msg1169
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/106/

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.

107. JSON-RPC programming tips using labels

Poster: satoshi · Date: 2010-05-26T18:27:25Z · Thread: JSON-RPC programming tips using labels
Original: https://bitcointalk.org/index.php?topic=157.msg1252#msg1252
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/107/

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.

108. Re: Tracing a coin's lineage

Poster: satoshi · Date: 2010-05-26T18:51:04Z · Thread: Tracing a coin's lineage
Original: https://bitcointalk.org/index.php?topic=154.msg1254#msg1254
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/108/

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.

109. Re: CLI bitcoin generation

Poster: satoshi · Date: 2010-05-26T20:09:34Z · Thread: CLI bitcoin generation
Original: https://bitcointalk.org/index.php?topic=145.msg1256#msg1256
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/109/

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.

110. Re: Share database blocks ?

Poster: satoshi · Date: 2010-05-26T20:34:34Z · Thread: Share database blocks ?
Original: https://bitcointalk.org/index.php?topic=153.msg1258#msg1258
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/110/

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?

111. Re: Website translations

Poster: satoshi · Date: 2010-05-26T21:16:34Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg1259#msg1259
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/111/

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

112. Re: Odd amount of generated coins

Poster: satoshi · Date: 2010-05-26T21:34:32Z · Thread: Odd amount of generated coins
Original: https://bitcointalk.org/index.php?topic=141.msg1260#msg1260
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/112/

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  "

113. Re: Website translations

Poster: satoshi · Date: 2010-05-27T14:18:22Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg1269#msg1269
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/113/

Hurray!  We have our first language.  I uploaded it to SVN to go in with the 0.3 release.

114. Re: Hostnames instead of IP Addresses

Poster: satoshi · Date: 2010-06-02T18:18:15Z · Thread: Hostnames instead of IP Addresses
Original: https://bitcointalk.org/index.php?topic=158.msg1322#msg1322
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/114/

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:

1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.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.

115. Re: Proof-of-work difficulty increasing

Poster: satoshi · Date: 2010-06-02T18:45:38Z · Thread: Proof-of-work difficulty increasing
Original: https://bitcointalk.org/index.php?topic=43.msg1323#msg1323
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/115/

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.

116. Re: Website translations

Poster: satoshi · Date: 2010-06-02T22:18:09Z · Thread: Website and software translations
Original: https://bitcointalk.org/index.php?topic=151.msg1324#msg1324
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/116/

I uploaded the 93% complete Dutch translation to SVN.  Thanks!

117. Re: On IRC bootstrapping

Poster: satoshi · Date: 2010-06-14T18:13:21Z · Thread: On IRC bootstrapping
Original: https://bitcointalk.org/index.php?topic=84.msg1579#msg1579
SNI: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/117/

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