@ Turc Testerman 🦃

# Kicking the Hornet's Nest - third edition - part 13 All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub: ``` npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j ``` ---- ### Kicking the Hornet's Nest pages 275 - 300 ---- **BitcoinTalk** Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG _2010-06-18 16:17:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=195.msg1617#msg1617) A second version would be a massive development and maintenance hassle for me. It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version. I know, most developers don't like their software forked, but I have real technical reasons in this case. [**Quote from: gavinandresen on June 17, 2010, 07:58:14 PM**](https://bitcointalk.org/index.php?topic=195.msg1613#msg1613) _I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel. That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends..._ That's one of the reasons for transaction fees. There are other things we can do if necessary. [**Quote from: laszlo on June 17, 2010, 06:50:31 PM**](https://bitcointalk.org/index.php?topic=195.msg1612#msg1612) _How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well_  Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it. Much more of the work was designing than coding. Fortunately, so far all the issues raised have been things I previously considered and planned for. ##### BitcoinTalk #### Re: On IRC bootstrapping ##### _2010-06-18 17:28:18 UTC_ - [-](https://bitcointalk.org/index.php?topic=84.msg1619#msg1619) The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It's only slow to get connected the first time. This means TOR users won't need to -addnode anymore, it'll get connected automatically. ##### BitcoinTalk #### Re: Get 5 free bitcoins from freebitcoins.appspot.com ##### _2010-06-18 23:08:34 UTC_ - [-](https://bitcointalk.org/index.php?topic=183.msg1620#msg1620) Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up. You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something. ##### BitcoinTalk #### Re: Bitcoin in Ubuntu 10.04 ##### _2010-06-21 17:20:21 UTC_ - [-](https://bitcointalk.org/index.php?topic=149.msg1646#msg1646) [_**Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM**_](https://bitcointalk.org/index.php?topic=149.msg1203#msg1203) _Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release._ This is now fixed in the SVN version. 1) Menu bar default color. 2) Balance bar not a different color. 3) Background behind bitcoin address and balance now the same color as toolbar. I checked all the standard themes and it seems reasonable with all of them. Ubuntu minimize,maximize,close buttons to the right: gconf-editor apps->metacity->general button_layout=menu:minimize,maximize,close They've got it awfully buried considering 9 out of 10 users are used to having it on the right. ##### BitcoinTalk #### Re: Dying bitcoins ##### _2010-06-21 17:48:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=198.msg1647#msg1647) Lost coins only make everyone else's coins worth slightly more. Think of it as a donation to everyone. [_**Quote from: laszlo on June 21, 2010, 01:54:29 PM**_](https://bitcointalk.org/index.php?topic=198.msg1640#msg1640) _I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this.._ Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal. ##### BitcoinTalk #### Re: Proof-of-work difficulty increasing ##### _2010-06-21 18:09:17 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg1648#msg1648) I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar. Two new log messages: 21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s 21/06/2010 01:23 generated 50.00 grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance. On windows, use: findstr "hashmeter generated" "%appdata%itcoin\debug.log" I have the hashmeter messages once an hour. How often do you think it should be? ##### BitcoinTalk #### Re: Bitcoin in Ubuntu 10.04 ##### _2010-06-22 03:45:56 UTC_ - [-](https://bitcointalk.org/index.php?topic=149.msg1653#msg1653) On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there. But now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it. Updated SVN. Thanks for testing. ##### BitcoinTalk #### 0.3 almost ready -- please test the Mac version! ##### _2010-06-22 04:01:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1654#msg1654) I finished everything on my list to do for version 0.3. The code on SVN is about ready to release. Testing at this point is much appreciated. ##### BitcoinTalk #### Re: How fast do the fastest computers generate bitcoins? ##### _2010-06-22 04:35:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=197.msg1656#msg1656) I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect. Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks. I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long. The latest SVN version has a khash/s display. Around 400 khash/s per processor is typical. ##### BitcoinTalk #### Re: Bitcoin in Ubuntu 10.04 ##### _2010-06-22 16:39:43 UTC_ - [-](https://bitcointalk.org/index.php?topic=149.msg1668#msg1668) It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list. I never would have noticed that if you hadn't pointed it out. ##### BitcoinTalk #### Re: Proof-of-work difficulty increasing ##### _2010-06-22 16:51:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg1669#msg1669) Agree. Certainly too trivial to clutter the user's attention with. I changed it to every 30 minutes. If I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 17:02:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1670#msg1670) [_**Quote from: lachesis on June 22, 2010, 06:20:02 AM**_](https://bitcointalk.org/index.php?topic=199.msg1658#msg1658) _It would be nice if the listtransactions RPC method were finished before the next release, though._ My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably. We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 17:37:08 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1671#msg1671) Here's RC1 for windows for testing: (removed, see RC2 below) Please only download this if you're going to test and report back whether everything seems fine or not. Make sure to look through the files in "c:\program filesitcoin" **Martii Malmi (AKA Sirius) “COPA trial” email #193** **Date: Tue, 22 Jun 2010 18:36:22 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: 0.3.0 rc1 quickie download link** **To: Martti Malmi <mmalmi@cc.hut.fi>** If bandwidth is a problem, delete my link in the "0.3 almost ready" thread. I just don't want to upload it to sourceforge for a quickie share for a day or two, possibly taking it down immediately if there's a bug. Sourceforge has a policy of not allowing removal of files once they're added, and it's a pain to upload to. I'll delete the file once the release is ready. BTW, it's looking like I may be able to get us some money soon to cover web host costs, back your exchange service, etc, in the form of cash in the mail. Can you receive it and act as the project's treasurer? ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 19:11:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1675#msg1675) [_**Quote from: davidonpda on June 22, 2010, 06:23:26 PM**_](https://bitcointalk.org/index.php?topic=199.msg1673#msg1673) _EXCEPTION: 22DbRunRecoveryException DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery C:\Program Files\Bitcoinitcoin.exe in OnInit()_ What operating system? Normally when it does that it's because the directory where the data directory should go doesn't exist. See if the "%appdata%" directory exists. Do you get that error with 0.2 also? It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 19:25:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1677#msg1677) davidonpda, were you also running laszlo's build previously? Check if the "%appdata%" directory exists, and "%appdata%itcoin" Try: rename "%appdata%itcoin" bitcoin2 does it work then? ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 19:46:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1679#msg1679) You figured it out faster than I could post a reply.  It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn't ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded. When you copied the directory except log.0000000002, that's the best solution. You should be good now. The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data. Please keep running v0.3 if at all possible, don't go back to v0.2.10. Anyone else who hits this problem, move the database\log.000000000* files somewhere else. (if it works fine after that, you can delete them later) I'm reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-22 22:23:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1686#msg1686) Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build. 30khash increase to what total rate? (to figure the % increase) **Martii Malmi (AKA Sirius) “COPA trial” email #195** **Date: Wed, 23 Jun 2010 21:33:57 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: donation** **To: mmalmi@cc.hut.fi** _>> BTW, it's looking like I may be able to get us some money soon to cover_ _>> web host costs, back your exchange service, etc, in the form of cash in_ _>> the mail. Can you receive it and act as the project's treasurer?_ _>_ _> That would be nice, I can do it. Sending cash in the mail may have its_ _> risks, but maybe it's still the best anonymous option. We can also ask_ _> for donations in BTC on the forum._ I got a donation offer for $2000 USD. I need to get your postal mailing address to have him send to. And yes, he wants to remain anonymous, so please keep the envelope's origin private. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-24 17:40:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1748#msg1748) Here's RC1 for linux for testing: (link removed, see below) It contains both 32-bit and 64-bit binaries. Recent changes: build-unix.txt: - Added instructions for building wxBase, which is needed to compile bitcoind. - The package libboost-dev doesn't install anything anymore, you need to get libboost-all-dev. - Updated version numbers. makefile.unix: - The libboost libraries have removed the "-mt" from their filenames in 1.40. If you're compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-25 02:17:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1760#msg1760) I don't know. Maybe someone with more Linux experience knows how to install the library it needs. I built it on Ubuntu 10.04. I hope that wasn't a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04? The 64-bit version shouldn't be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all. We don't need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It's not like Linux where the 64-bit OS wants 64-bit programs. I'm also curious if it's a little faster on linux than windows. Do you think I should make the directories: /bin32/ /bin64/ instead of /bin/32/ /bin/64/ ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-25 14:10:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1769#msg1769) Thanks virtualcoin, that's a perfect comparison. The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5). The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit. Hmm, I think the 8 extra registers added by x86-64 must be what's helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers. ##### BitcoinTalk #### Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel ##### _2010-06-25 21:15:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=215.msg1779#msg1779) We need more details about what happened MadHatter. Both 0.2 and 0.3 have a backup way of getting connected without IRC, it's just slower to get connected. 0.2 can find other nodes without IRC if it's ever been connected before, but a new install can't discover the network for the first time without IRC. 0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it's better having IRC for redundancy. ##### BitcoinTalk #### Re: On IRC bootstrapping ##### _2010-06-25 22:40:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=84.msg1781#msg1781) [_**Quote from: laszlo on June 14, 2010, 06:30:58 PM**_](https://bitcointalk.org/index.php?topic=84.msg1580#msg1580) _I run an IRC server you can use, it's fairly stable but it's not on redundant connections or anything. It is only two servers right now but we don't mess with it or anything, it just runs. My box is a dedicated irc server: 2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08 You can use irc.lfnet.org to connect._ This seems like a good idea. What does everyone think, should we make the switch for 0.3? ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-26 00:32:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1787#msg1787) Lets try using Laszlo's irc.lfnet.org instead of freenode. Here's RC2, that's the only change in it: (see below for download links) ##### BitcoinTalk #### Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel ##### _2010-06-26 14:28:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=215.msg1797#msg1797) Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo's option is a much better fit for us. I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over: [http://BitcoinTalk.org/index.php?topic=199.msg1787#msg1787](http://bitcointalk.org/index.php?topic=199.msg1787#msg1787) ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-06-26 15:10:10 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1800#msg1800) The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you're hovering in a menu. ##### BitcoinTalk #### Beta? ##### _2010-06-26 17:02:43 UTC_ - [-](https://bitcointalk.org/index.php?topic=217.msg1803#msg1803) Is it about time we lose the Beta? I would make this release version 1.3. ##### BitcoinTalk #### Re: 1.3 almost ready ##### _2010-06-26 19:21:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1806#msg1806) Changed the version number to 1.3 and removed "Beta". (links removed, see below) Uses irc.lfnet.org. ##### BitcoinTalk #### Re: Bitcoin mobile. ##### _2010-06-26 20:58:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=177.msg1814#msg1814) [_**Quote from: sirius-m on June 10, 2010, 01:51:16 PM**_](https://bitcointalk.org/index.php?topic=177.msg1452#msg1452) _You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them._ I think that's the best option right now. Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses. They could make a smaller version of the site optimized for mobile. If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from. If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website. A web interface to your own Bitcoin server at home wouldn't be a solution for everyone. Most users don't have a static IP, and it's too much trouble to set up port forwarding. ##### BitcoinTalk #### Re: Building BitCoin Client completely Headless ##### _2010-06-26 21:06:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=171.msg1815#msg1815) The linux release candidate in the "1.3 almost ready" thread contains prebuilt bitcoind. ##### BitcoinTalk #### Re: Bitcoin Faucet changes ##### _2010-06-26 21:39:52 UTC_ - [-](https://bitcointalk.org/index.php?topic=206.msg1816#msg1816) Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B. If you can't solve the problem, you can always keep lowering the amount of bitcoins given until it's manageable, and always require captcha. ##### BitcoinTalk #### Re: Beta? ##### _2010-06-27 12:43:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=217.msg1827#msg1827) But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don't want to put my money in something that's 1.0. 1.0 might be more interesting for a moment, but after that we're still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3) ##### BitcoinTalk #### Re: IPv6, headless client, and more ##### _2010-06-27 13:02:38 UTC_ - [-](https://bitcointalk.org/index.php?topic=218.msg1828#msg1828) Welcome, Harry. I hadn't thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial. The focus for bitcoind so far has been more on backend support for websites. There's demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for "generated" and "hashmeter" for some feedback. Generated blocks take about 24 hours before they're credited to your balance. ##### BitcoinTalk #### Re: 1.3 almost ready ##### _2010-06-27 15:30:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1834#msg1834) MinGW still only has good old stable 3.4.5. There's not much reason for them to update it. When I looked at the 3.4.5 compiled SHA disassembly, I couldn't see any room for improvement at all. I can't imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much? ##### BitcoinTalk #### Re: Major Meltdown ##### _2010-06-27 19:06:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=202.msg1838#msg1838) Here's an answer to a similar question about how to recover from a major meltdown. [https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585](https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585) [_**Quote from: satoshi on June 14, 2010, 08:39:50 PM**_](https://bitcointalk.org/index.php?topic=191.msg1585#msg1585) _If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function. If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used._ ##### BitcoinTalk #### Re: Feature Request: Limiting Connections ##### _2010-07-02 19:21:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=223.msg1924#msg1924) Thanks for the feedback on this. One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally. It would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections. I will implement a feature to stop accepting inbound connections once you hit a certain number. Which version are you running? Anyone know how many connections typical P2P software like BitTorrent can get up to? ##### BitcoinTalk #### Re: 1.3 almost ready ##### _2010-07-02 20:37:17 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1926#msg1926) [_**Quote from: dkaparis on June 27, 2010, 10:02:25 PM**_](https://bitcointalk.org/index.php?topic=199.msg1842#msg1842) _On a related note, is the thing compilable by Visual C++? I'm inclined to give it a try when I get around to it._ It is, but generating is more than twice as slow. ##### BitcoinTalk #### Re: 0.3 almost ready ##### _2010-07-02 21:57:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1927#msg1927) (reverted to rc2) Links removed, 0.3 is now released, so go to [http://www.bitcoin.org](http://www.bitcoin.org/) to download it. ##### BitcoinTalk #### Re: Beta? ##### _2010-07-02 22:03:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=217.msg1928#msg1928) OK, back to 0.3 then. Please download RC4 and check it over as soon as possible. I'd like to release it soon. [http://BitcoinTalk.org/index.php?topic=199.msg1927#msg1927](http://bitcointalk.org/index.php?topic=199.msg1927#msg1927) Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don't get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy. ##### BitcoinTalk #### Re: Feature Request: Limiting Connections ##### _2010-07-02 22:20:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=223.msg1929#msg1929) I reduced max outbound connections from 15 to 8 in RC4. 15 was way more than we needed for redundancy. 8 is still plenty of redundancy. As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get. If anyone wants more than 8 connections, they can open port 8333 on their firewall. ##### BitcoinTalk #### Re: 0.3 almost ready -- please test the Mac version! ##### _2010-07-04 21:52:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg1947#msg1947) Laszlo's build is going to be our first Mac release so please test it! ##### BitcoinTalk #### Re: Slashdot Submission for 1.0 ##### _2010-07-05 21:31:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=234.msg1976#msg1976) BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0. I really appreciate the effort, but there are a lot of problems. We don't want to lead with "anonymous". (I've been meaning to edit the homepage) "The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government." -- I am definitely not making an such taunt or assertion. It's not stable-with-respect-to-energy. There was a discussion on this. It's not tied to the cost of energy. NLS's estimate based on energy was a good estimated starting point, but market forces will increasingly dominate. Sorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There's nothing to relate it to. **Martii Malmi (AKA Sirius) “COPA trial” email #197** **Date: Tue, 06 Jul 2010 03:59:57 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Anonymous, homepage changes** **To: Martti Malmi <mmalmi@cc.hut.fi>** I think we should de-emphasize the anonymous angle. With the popularity of bitcoin addresses instead of sending by IP, we can't give the impression it's automatically anonymous. It's possible to be pseudonymous, but you have to be careful. If someone digs through the transaction history and starts exposing information people thought was anonymous, the backlash will be much worse if we haven't prepared expectations by warning in advance that you have to take precautions if you really want to make that work. Like Tor says, "Tor does not magically encrypt all of your Internet activities. Understand what Tor does and does not do for you." Also, anonymous sounds a bit shady. I think the people who want anonymous will still figure it out without us trumpeting it. I made some changes to the bitcoin.org homepage. It's not really crucial to update the translations. I tend to keep editing and correcting for some time afterwards, so if they want to update, they should wait. I removed the word "anonymous", and the sentence about "anonymity means", although you worded it so carefully "...CAN be kept hidden..." it was a shame to remove it. Instead, I added Tor instructions at the bottom, with instructions for how to stay anonymous (pseudonymous) directly after the Tor instructions: "If you want to remain anonymous (pseudonymous, really), be careful not to reveal any information linking your bitcoin addresses to your identity, and use a new bitcoin address for each payment you receive." It helps that it can now seed automatically through Tor. Even though it doesn't say anonymous until the bottom, I think anonymous seekers would already suspect it based on all the other attributes like no central authority to take your ID info and the way bitcoin addresses look. ##### BitcoinTalk #### Bitcoin 0.3 released! ##### _2010-07-06 18:32:35 UTC_ - [-](https://bitcointalk.org/index.php?topic=238.msg2004#msg2004) Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at [http://www.bitcoin.org](http://www.bitcoin.org/) or read the forum to find out more. **Martii Malmi (AKA Sirius) “COPA trial” email #198** **Date: Tue, 06 Jul 2010 19:03:50 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: 0.3.0 released** **To: Martti Malmi <mmalmi@cc.hut.fi>** I uploaded 0.3.0 beta to sourceforge and updated the links on bitcoin.org. I still need to post the announcement message on the forum and mailing list. Here's what I've prepared: Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually being released to the networks nodes based on the CPU power they contribute. You can get a share of them just by installing the software and contributing your idle CPU time. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Tabs for sent and received transactions - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) **Martii Malmi (AKA Sirius) “COPA trial” email #199** **Date: Tue, 06 Jul 2010 19:40:11 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: 0.3.0 released** **To: Martti Malmi <mmalmi@cc.hut.fi>** Actually, "tabs for sent and received transactions" sounds really immature if it doesn't have that already. "Transaction filter tabs" sounds better. I'm still editing it a little more and then I'll e-mail it to bitcoin-list and send it to the cryptography list. "Get it at http://www.bitcoin.org or read the forum to find out more." ##### BitcoinTalk #### Re: 0.3 almost ready -- please test the Mac version! ##### _2010-07-06 19:43:18 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg2006#msg2006) 0.3 released [http://BitcoinTalk.org/index.php?topic=238.msg2004#msg2004](http://bitcointalk.org/index.php?topic=238.msg2004#msg2004) ##### BitcoinTalk #### Re: 0.3 almost ready -- please test the Mac version! ##### _2010-07-06 19:43:18 UTC_ - [-](https://bitcointalk.org/index.php?topic=199.msg2006#msg2006) 0.3 released [http://BitcoinTalk.org/index.php?topic=238.msg2004#msg2004](http://bitcointalk.org/index.php?topic=238.msg2004#msg2004) **Martii Malmi (AKA Sirius) “COPA trial” email #200** **Date: Tue, 06 Jul 2010 22:53:07 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [bitcoin-list] Bitcoin 0.3 released!** **To: bitcoin-list@lists.sourceforge.net** Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at www.bitcoin.org, and read the forum to find out more. **bitcoin-list** [**bitcoin-list**] Bitcoin 0.3 released! _2010-07-06 21:53:53 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/25686730/) Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin's total circulation is limited to 21 million coins. The coins are gradually released to the network's nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time. What's new: - Command line and JSON-RPC control - Includes a daemon version without GUI - Transaction filter tabs - 20% faster hashing - Hashmeter performance display - Mac OS X version (thanks to Laszlo) - German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at http://www.bitcoin.org, and read the forum to find out more. ##### BitcoinTalk #### Re: On IRC bootstrapping ##### _2010-07-07 01:31:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=84.msg2010#msg2010) Everybody needs to connect to the same IRC server and channel so they can find each other. [_**Quote from: Vasiliev on June 25, 2010, 11:50:15 PM**_](https://bitcointalk.org/index.php?topic=84.msg1785#msg1785) _You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's._ It might not be good if we suddenly rushed freenode with a ton of users all at once. The fallback is our own seed system. irc.lfnet.org is pretty old and has impressive uptime. I think it's going to be fine. We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems. ##### BitcoinTalk #### Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username ##### _2010-07-08 18:24:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=246.msg2068#msg2068) Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that. Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not? ##### BitcoinTalk #### Re: Anonymity ##### _2010-07-08 19:12:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=241.msg2071#msg2071) It's hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world. Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated. If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over. If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way. It wouldn't be easy to take advantage of the segmentation to double-spend. If it's impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over. You would usually know whether you're in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you're in the smaller segment, you should assume nothing is confirmed. ##### BitcoinTalk #### Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username ##### _2010-07-09 03:01:35 UTC_ - [-](https://bitcointalk.org/index.php?topic=246.msg2077#msg2077) I think I see where the problem is. Coincidentally, I recently coded a replacement for the function in question which should fix it. It's not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison. ##### BitcoinTalk #### Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?) ##### _2010-07-09 03:28:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=242.msg2078#msg2078) What the OP described is called "cornering the market". When someone tries to buy all the world's supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It's great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell. The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979: "Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world's deliverable silver.[1] During Hunt's accumulation of the precious metal silver prices rose from $11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below $11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]" [http://en.wikipedia.org/wiki/Cornering_the_market](http://en.wikipedia.org/wiki/Cornering_the_market) ##### ##### BitcoinTalk #### Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username ##### _2010-07-09 15:37:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=246.msg2092#msg2092) I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it. This change is revision 102 of the SVN. ----