#

ifdef

(6 articles)

Kicking the Hornet's Nest - part 7

# Kicking the Hornet's Nest - third edition - part 7 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 125 - 150 ---- **Martii Malmi (AKA Sirius) “COPA trial” email #5** **Date****: Mon, 04 May 2009 16:51:00 +0100** **From****: Satoshi Nakamoto <satoshin@gmx.com>** **Subject****: Re: Bitcoin** **To****: mmalmi@cc.hut.fi** Oh crap, I got your sourceforge usernames mixed up, sorry about that. I clicked on the wrong e-mail when I was looking for your username. You now have access. Your FAQ looks good so far! You can create whatever you want on bitcoin.sourceforge.net. Something to get new users up to speed on what Bitcoin is and how to use it and why, and clean and professional looking would help make it look well established. The site at bitcoin.org was designed in a more professorial style when I was presenting the design paper on the Cryptography list, but we're moving on from that phase. You should probably change the part about "distribute them under several keys". When the paper says that it means for the software to do it, and it does. For privacy reasons, the software already uses a different key for every transaction, so every piece of money in your wallet is already on a different key. The exception is when using a bitcoin address, everything sent to the same bitcoin address is on the same key, which is a privacy risk if you're trying to be anonymous. The EC-DSA key size is very strong (sized for the future), we don't practically have to worry about a key getting broken, but if we did there's the advantage that someone expending the massive computing resources would only break one single transaction's worth of money, not someone's whole account. The details about how to backup your wallet files is in the Q&A dump and also it's explained in readme.txt and definitely belongs in the FAQ. Oh I see, you're trying to address byronm's concern on freedomainradio. I see what you mean about the password feature being useful to address that argument. Banks let anyone who has your name and account number drain your account, and you're not going to get it back from Nigeria. If someone installs a keylogger on your computer, they could just as easily get your bank password and transfer money out of your account. Once we password encrypt the wallet, we'll be able to make a clearer case that we're much more secure than banks. We use strong encryption, while banks still let anyone who has your account info draw money from your account. _mmalmi@cc.hut.fi wrote:_ _> Quoting Satoshi Nakamoto <satoshin@gmx.com>:_ _>_ _>> That would be great! I added you (dmp1ce) as a dev to the sourceforge_ _>> project and gave you access to edit the web space and everything._ _>_ _> Oh, that's not me but another guy who wanted to help. I've seen him on_ _> the Freedomain Radio forum. My name is Martti Malmi and my Sourceforge_ _> account is sirius-m. No problem!_ _>_ _> Thanks for your answered questions, I'll add them to the faq. Here's_ _> what I've done so far:_ _>_ _> **** Bitcoin FAQ ****_ _>_ _> General Questions_ _>_ _> 1 What is bitcoin?_ _>_ _> Bitcoin is a peer-to-peer network based anonymous digital_ _> currency. Peer-to-peer (P2P) means that there is no central_ _> authority to issue new money or to keep track of the_ _> transactions. Instead, those tasks are managed collectively by_ _> the nodes of the network. Anonymity means that the real world_ _> identity of the parties of a transaction can be kept hidden from_ _> the public or even from the parties themselves._ _>_ _> 2 How does bitcoin work?_ _>_ _> Bitcoin utilizes public/private key cryptography. When a coin is_ _> transfered from user A to user B, A adds B's public key to the_ _> coin and signs it with his own private key. Now B owns the coin_ _> and can transfer it further. To prevent A from transfering the_ _> already used coin to another user C, a public list of all the_ _> previous transactions is collectively maintained by the network_ _> of bitcoin nodes, and before each transaction the coin's_ _> unusedness will be checked._ _>_ _> For details, see chapter Advanced Questions._ _>_ _> 3 What is bitcoin's value backed by?_ _>_ _> Bitcoin is valued for the things it can be exchanged to, just_ _> like all the traditional paper currencies are._ _>_ _> When the first user publicly announces that he will make a pizza_ _> for anyone who gives him a hundred bitcoins, then he can use_ _> bitcoins as payment to some extent - as much as people want pizza_ _> and trust his announcement. A pizza-eating hairdresser who trusts_ _> him as a friend might then announce that she starts accepting_ _> bitcoins as payment for fancy haircuts, and the value of the_ _> bitcoin would be higher - now you could buy pizzas and haircuts_ _> with them. When bitcoins have become accepted widely enough, he_ _> could retire from his pizza business and still be able to use his_ _> bitcoin-savings._ _>_ _> 4 How are new bitcoins created?_ _>_ _> New coins are generated by a network node each time it finds the_ _> solution to a certain calculational problem. In the first 4 years_ _> of the bitcoin network, amount X of coins will be created. The_ _> amount is halved each 4 years, so it will be X/2 after 4 years,_ _> X/4 after 8 years and so on. Thus the total number of coins will_ _> approach 2X._ _>_ _> 5 Is bitcoin safe?_ _>_ _> Yes, as long as you make backups of your coin keys, protect them_ _> with strong passwords and keep keyloggers away from your_ _> computer. If you lose your key or if some unknown attacker_ _> manages to unlock it, there's no way to get your coins back. If_ _> you have a large amount of coins, it is recommended to distribute_ _> them under several keys. You propably wouldn't either keep all_ _> your dollars or euros as paper in a single wallet and leave it_ _> unguarded._ _>_ _> 6 Why should I use bitcoin?_ _>_ _> • Transfer money easily through the internet, without having to_ _> trust third parties._ _>_ _> • Third parties can't prevent or control your transactions._ _>_ _> • Be safe from the unfair monetary policies of the monopolistic_ _> central banks and the other risks of centralized power over a_ _> money supply. The limited inflation of the bitcoin system's_ _> money supply is distributed evenly (by CPU power) throughout_ _> the network, not monopolized to a banking elite._ _>_ _> • Bitcoin's value is likely to increase as the growth of the_ _> bitcoin economy exceeds the inflation rate - consider bitcoin_ _> an investment and start running a node today!_ _>_ _> 7 Where can I get bitcoins?_ _>_ _> Find a bitcoin owner and sell her something - MMORPG equipement,_ _> IT support, lawn mowing, dollars or whatever you can trade with_ _> her. You can also generate new bitcoins for yourself by running a_ _> bitcoin network node._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #8** **Date****: Tue, 05 May 2009 18:39:44 +0100** **From****: Satoshi Nakamoto <satoshin@gmx.com>** **Subject****: Re: Bitcoin** **To****: mmalmi@cc.hut.fi** _mmalmi@cc.hut.fi wrote:_ _>> You can create whatever you want on bitcoin.sourceforge.net. Something_ _>> to get new users up to speed on what Bitcoin is and how to use it and_ _>> why, and clean and professional looking would help make it look well_ _>> established. The site at bitcoin.org was designed in a more_ _>> professorial style when I was presenting the design paper on the_ _>> Cryptography list, but we're moving on from that phase._ _>_ _> Ok. Could you set the project MySQL database passwords so that I can set_ _> up a CMS on the site? I was thinking about WordPress, as it seems simple_ _> and well maintained. I need a password for the read/write account and_ _> one database (or the database admin pass to create it myself). This can_ _> be done somewhere in the project admin pages, I think._ They have Wordpress built in, you might not need to set up any database stuff manually. I enabled the Wordpress feature and added you as an admin, account sirius-m, e-mail sirius-m@users.sourceforge.net. I'm not sure how it works out the password for access, maybe it's just based on being logged in to sourceforge. https://apps.sourceforge.net/wordpress/bitcoin/wp-admin/ They also have support for MediaWiki if you want it. In case you still need it, here's the accounts and passwords for mysql. # Access this project's databases over the Internet https://apps.sourceforge.net/admin/Bitcoin # Documentation: Guide to MySQL Database Services http://p.sf.net/sourceforge/mysql # Hostname: mysql-b (exactly as shown, with no domain suffix) # Database name prefix: b244765_ -- i.e. "CREATE DATABASE b244765_myapp" as your ADMIN user. # RO user: b244765ro (SELECT) # RW user: b244765rw (SELECT, INSERT, DELETE, UPDATE) # ADMIN user: b244765admin (has RW account privileges, and CREATE, DROP, ALTER, INDEX, LOCK TABLES) # web-access URL: https://mysql-b.sourceforge.net/ passwords: b244765ro EaG3nHLL b244765rw sNKgyt4W b244765admin Mz589ZKf _> ...the difference being, though, that not everyone can easily_ _> transfer their regular bank money into an uncontrollable location. In_ _> bitcoin anyone can do it._ That's true. We shouldn't try to use security against identity theft as a selling point, since it leads into these counter arguments. The current banking model is already tested and the actual loss percentage is known. Even if ours is probably better, it's an unknown, so people can imagine anything. The uncertainty about what the average loss percentage will be is greater than the likely loss percentage itself. **Martii Malmi (AKA Sirius) “COPA trial” email #11** **Date****: Thu, 07 May 2009 03:35:50 +0100** **From****: Satoshi Nakamoto <satoshin@gmx.com>** **Subject****: Re: Bitcoin** **To****: mmalmi@cc.hut.fi** It's already an improvement, and like you say, there must be better themes to choose from. It would be good to make the download link go directly to the download area: https://sourceforge.net/project/showfiles.php?group_id=244765 I haven't found any way to gain admin control over the mediawiki feature. It thinks I'm a different S_nakamoto from the one that has admin access: User list * S nakamoto <- it thinks I'm this one * S nakamoto ‎(admin, editor) * Sirius-m I tried deleting and re-enabling the feature, no help. Oh well. _mmalmi@cc.hut.fi wrote:_ _> Quoting Satoshi Nakamoto <satoshin@gmx.com>:_ _>_ _>> They have Wordpress built in, you might not need to set up any database_ _>> stuff manually._ _>>_ _>> They also have support for MediaWiki if you want it._ _>_ _> The built-in Wordpress comes with ads, and new plugins and themes need_ _> to be installed by the Sourceforge staff, so I installed Wordpress at_ _> http://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/,_ _> with admin/Wubreches3eS as login. If there's something to add or change,_ _> feel free to._ _>_ _> The current layout is just a quickly applied free theme, but I'll see if_ _> I can do something more visual myself._ _>_ _> The MediaWiki might be quite useful for maintaining the FAQ, which could_ _> be retrieved from there to the main site somehow. The wiki says I need_ _> to be an editor or admin to create a new page, which is funny, because_ _> https://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights_ _> says that users can create pages._ **Martii Malmi (AKA Sirius) “COPA trial” email #15** **Date****: Sun, 24 May 2009 23:03:38 +0100** **From****: Satoshi Nakamoto <satoshin@gmx.com>** **Subject****: Re: Bitcoin** **To****: mmalmi@cc.hut.fi** You're right, that was it. I went in and granted us access using the alternate account. I like your idea of at least moving the FAQ into the wiki. I've seen other projects that use the wiki for the FAQ or even the whole site. If you can figure out how to make it so regular users can edit things, then anyone who wants to can help. _mmalmi@cc.hut.fi wrote:_ _> Quoting mmalmi@cc.hut.fi:_ _>_ _>> Quoting mmalmi@cc.hut.fi:_ _>>_ _>>> Quoting Satoshi Nakamoto <satoshin@gmx.com>:_ _>>>_ _>>>> I haven't found any way to gain admin control over the mediawiki_ _>>>> feature. It thinks I'm a different S_nakamoto from the one that has_ _>>>> admin access:_ _>>>> User list_ _>>>> * S nakamoto <- it thinks I'm this one_ _>>>> * S nakamoto ‎(admin, editor)_ _>>>> * Sirius-m_ _>>>>_ _>>>> I tried deleting and re-enabling the feature, no help. Oh well._ _>>>_ _>>> I think this has something to do with the underscore character in your_ _>>> username; MediaWiki handles them as spaces. I could ask SF Support_ _>>> about this._ _>>_ _>> Or could you control the MediaWiki with your account nakamoto2?_ _>_ _> Oh, sorry for spamming with emails, but the problem is indeed with the_ _> underscore character:_ _> http://apps.sourceforge.net/trac/sourceforge/ticket/300_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #19** **Date: Thu, 11 Jun 2009 22:24:25 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** The site layout is looking nicer. More impressive looking. There are a lot of things you can say on the sourceforge site that I can't say on my own site. Even so, I'm uncomfortable with explicitly saying "consider it an investment". That's a dangerous thing to say and you should delete that bullet point. It's OK if they come to that conclusion on their own, but we can't pitch it as that. A few details: the FAQ says "see section 2.3", but the sections aren't numbered. Also, could you delete the last sentence on the FAQ "They are planned to be hidden in v0.1.6, since they're just confusing and annoying and there's no reason for users to have to see them." -- that's not really something I meant to say publicly. The links to sites to help set up 8333 port forwarding is great. favicon is a nice touch. Someone came up with the word "cryptocurrency"... maybe it's a word we should use when describing Bitcoin, do you like it? Sourceforge is so slow right now I can't even get the login page to load. Maybe due to the site reorg they just did. I'll keep trying and try to get you that logo stats thing. _mmalmi@cc.hut.fi wrote:_ _> Now that the project web is up and running, do you think that setting up_ _> a custom VHOST for the bitcoin.org domain would be a good idea?_ _> Instructions:_ _> http://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs_ _>_ _> Also, could you please send me a link to a SF Logo for statistics, as_ _> instructed at:_ _> http://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #21** **Date: Sun, 14 Jun 2009 21:30:58 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** _mmalmi@cc.hut.fi wrote:_ _> I made the changes. You could also register to the site or use the admin_ _> account to make necessary changes yourself, since the pages are located_ _> in the wiki._ Thanks, I've been really busy lately. I registered username "satoshi". Since there's no SSL login, I want to mainly use that account with sub-admin powers and use the admin account as little as possible. I created a "Moderators" group to give my satoshi account as much editing control as possible without the ability to overthrow everything. There's something weird with the download bar on the right covering things up, like on the new account registration it covers up the entry fields unless you make the browser really wide, and the homepage it covers up the screenshots. (with Firefox) **Martii Malmi (AKA Sirius) “COPA trial” email #24** **Date: Tue, 21 Jul 2009 04:14:43 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** I know this sounds really retarded, but I still haven't been able to get the sourceforge login page to load, so I haven't been able to read it either. https://sourceforge.net/account/login.php Hal isn't currently actively involved. He helped me a lot defending the design on the Cryptography list, and with initial testing when it was first released. He carried this torch years ago with his Reusable Proof Of Work (RPOW). I'm not going to be much help right now either, pretty busy with work, and need a break from it after 18 months development. It would help if there was something for people to use it for. We need an application to bootstrap it. Any ideas? There are donors I can tap if we come up with something that needs funding, but they want to be anonymous, which makes it hard to actually do anything with it. _mmalmi@cc.hut.fi wrote:_ _> Hi,_ _>_ _> I made a post on the Bitcoin developer's forum at SF about a month ago_ _> and sent you, David and Hal a notification about it to your_ _> users.sourceforge.net emails. A few days ago I wondered why no one had_ _> replied, and tried if the SF mail aliases even work - and they didn't,_ _> at least in the case of my account. So could you please forward this_ _> message to the others?_ _>_ _> Best regards,_ _> sirius-m_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #28** **Date: Mon, 24 Aug 2009 23:00:35 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** That's a good point that since you know how many coins exist and how fast new ones are created, you could set a support price based on the amount of legacy currency you have and be sure you'll have enough to meet all demands. I had imagined an auction, but it would be far simpler and more confidence inspiring to back it at a specific exchange rate. Offering currency to back bitcoins would attract freebie seekers, with the benefit of attracting a lot of publicity. At first it would mostly be seen as a way to get free money for your computer's idle time. Maybe pitched like help support the future of e-commerce and get a little money for your computer's spare cycles. As people cash in and actually get paid, word would spread exponentially. It might help to keep the minimum transaction size above an amount which a typical user would be able to accumulate with one computer, so that users have to trade with each other for someone to collect enough to cash in. Aggregators would set up shop to buy bitcoins in smaller increments, which would add confidence in users ability to sell bitcoins if there are more available buyers than just you. People would obviously be sceptical at first that the backing will hold up against an onslaught of people trying to get the free money, but as the competition raises the proof-of-work difficulty, it should become clear that bitcoins stay scarce. People will see that they can't just get all the bitcoins they want. It would establish a minimum value under bitcoins enabling them to be used for other purposes if, hopefully, other purposes are waiting for something to use. _>> It would help if there was something for people to use it for. We need_ _>> an application to bootstrap it. Any ideas?_ _>_ _> I've been thinking about a currency exchange service that sells and_ _> buys bitcoins for euros and other currencies. Direct exchangeability_ _> to an existing currency would give bitcoin the best possible initial_ _> liquidity and thus the best adoptability for new users. Everyone_ _> accepts payment in coins that are easily exchangeable for common_ _> money, but not everyone accepts payment in coins that are only_ _> guaranteed to buy a specific kind of a product._ That would be more powerful if there was also some narrow product market to use it for. Some virtual currencies like Tencent's Q coin have made headway with virtual goods. It would be sweet if there was some way to horn in on a market like that as the official virtual currency gets clamped down on with limitations. Not saying it can't work without something, but a ready specific transaction need that it fills would increase the certainty of success. _> At its simplest this exchange service could be a website where_ _> traders, who can be individual persons, can post their rates, and_ _> random users can leave trade requests. Some kind of an average rate_ _> estimate could be shown on the site. Small-scale trading by_ _> individuals would be outside legal hassle in most countries, and_ _> putting all the eggs in the same basket would be avoided._ Basically like an eBay site with user reviews to try to establish which sellers can be trusted. The escrow feature will help but not solve everything. It would be far more work to set up such a site than just to set up a single exchange site of your own, and there won't be enough users to make it go until later. I'm thinking it wouldn't make sense to make an eBay type site until later. _> Another idea, which could be additional to the previous one, would be_ _> an automated exchange service. The service would automatically_ _> calculate the exchange rate and perform the transactions. This would_ _> be nicer to the user: completion of the transaction request would be_ _> certain and instantaneous. Making this service might actually be quite_ _> easy if there was a command line interface to Bitcoin: just take any_ _> web application framework and use PayPal back-end integration to_ _> automatically send euros when Bitcoins are received, and vice versa._ _> This kind of business would also work great on larger scale if you set_ _> up a company and take care of all the bureaucracy needed to practice_ _> currency exchange. (I actually have a registered company that I've_ _> used for billing of some IT work, I could use that as a base.)_ Even if you had automation, you'd probably want to review orders manually before processing them anyway. It wouldn't be hard to process orders by hand, especially at first. You could always set a minimum order size to keep orders more infrequent. _> This exchange business thing is something that I'd be interested in_ _> doing, and I also have the sufficient technical skills to do it._ _> Although, before this can be done, there should be a non-alpha version_ _> of Bitcoin (and the command line interface / API)._ _>_ _> If this gets started, donors / high-risk investors would be very_ _> welcome to bring capital for the currency's backup._ _>_ _> So, what do you think about the idea? Note that this is not something_ _> that I'm asking you to do (unless you want to) if you're busy with_ _> other things. I can do it myself, if I get positive reviews about the_ _> plan._ That's great, I could probably get a donor to send currency to you which you convert to euros and pay out through methods that are convenient for users. I don't want to do an exchange business myself, but it can be done independently of me. Like you say, there is more software development to be done first, and also I'd like to keep trying for a while to think of a bootstrap application to use bitcoins for. I've had some ideas that could only be done before an exchange exists. BTW, I tried to buy bitcoin.com before I started but there was no chance, it's owned by a professional domain speculator. It's normal for open source projects to have .org so it's not so bad. **Martii Malmi (AKA Sirius) “COPA trial” email #29** **Date: Mon, 24 Aug 2009 23:04:25 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** Glad that worked, it's a pain that the dependencies are so big and hard to build. Some of them give little attention to the Windows build. Next time I update to the latest versions, maybe I'll lay everything out in one directory tree and bundle the whole thing up into a giant archive. I'm not sure they had wxPack before. I'm glad they got that so everyone doesn't have to build wxWidgets themselves. OpenSSL is the harder one to build. I reduced the EXE size by running strip.exe on it to take out the debug symbols. That's with mingw. That's the better compiler, I only used VC for debugging. _mmalmi@cc.hut.fi wrote:_ _> I got it compile with MinGW + MSYS when I used wxPack instead of just_ _> wxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize was_ _> 52MB though, I should see how that can be fixed._ _>_ _> Next I'm going to implement the "minimize to tray" feature and the_ _> option to autostart Bitcoin with Windows, so the number of nodes online_ _> would stay higher. After that I could see if I can do a Linux port or_ _> the command line interface needed for web app frameworks._ _>_ _> Drop by at #bitcoin-dev on FreeNode some time if you use IRC._ _>_ _> And again, thanks for the great work you've done with Bitcoin._ _>_ _> Quote mmalmi@cc.hut.fi:_ _>_ _>> I've had quite a few errors coming up when trying to build the_ _>> third-party libraries and adding them to the Bitcoin build. Do you_ _>> happen to have a ready-to-build package that you could upload to the_ _>> CVS or somewhere else? I use mingw + msys, but I guess I could try_ _>> Visual C++ also, if it's easier that way._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #31** **Date: Sat, 29 Aug 2009 18:31:05 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** _> Next I'm going to implement the "minimize to tray" feature and the_ _> option to autostart Bitcoin with Windows, so the number of nodes online_ _> would stay higher._ Now that I think about it, you've put your finger on the most important missing feature right now that would make an order of magnitude difference in the number of nodes. Without auto-run, we'll almost never retain nodes after an initial tryout interest. Auto-running as a minimized tray icon by default was the key to success for the early file sharing networks. It wouldn't have been appropriate for v0.1.0 when stability wasn't a given yet, but now it's good and stable. This is a must-have feature for the next release so any users that come back to try the new version we hopefully retain this time. I think the most user friendly way of doing auto-run is putting an icon in the Startup folder. I see OpenOffice.org and a number of other things on my computer do it that way. The other way, creating a runas registry entry, is not easily visible or editable by users, I've never liked that much. I guess what we want is an auto-run option that's on by default, if the option is changed then it creates or deletes the startup icon. While it's tempting to do a Linux port, once we do it we have that extra work with every release from then on. I'd rather put it off a while longer. Auto-run might give us 300% more nodes while Linux might give us 3% more. Linux would help server farms, but actually we'd like to favour individual users. Someone reported that it works fine in WinE. **Martii Malmi (AKA Sirius) “COPA trial” email #33** **Date: Wed, 30 Sep 2009 19:12:29 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin** **To: mmalmi@cc.hut.fi** That's great, that's a good step forward. Yes, I worked out the sourceforge login problem, it was some tricky thing on the login page that exposed a quirky bug in a browser add-in. _mmalmi@cc.hut.fi wrote:_ _> Just for information: I committed my working copy to the svn/branches._ _> There's the minimize to tray feature and some other changes. It's nicer_ _> to run in the background now, but it's still incomplete and I'm working_ _> on it. The bugs are listed in bugs.txt._ _>_ _> Did you get your Sourceforge account work yet?_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #35** **Date: Fri, 16 Oct 2009 19:41:40 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Setup, Autorun, v0.1.6** **To: mmalmi@cc.hut.fi** Thanks for that. I'm still merging in some changes I had that need to go in before any next release. Some things based on questions and feedback I've received that'll reduce confusion. I'll probably enable multi-proc generating support, and hopefully make it safe to just backup wallet.dat to backup your money. It's good to be coding again! I'm going to hide the transaction fee setting, which is completely not needed and only serves to confuse people. It was only there for testing and demonstration of a technical detail that can only be needed in the far away future, if ever, but was necessary to implement at the beginning to make it possible later. What was the problem with the shortcut in the startup folder? If you could send me the code, I'd like to take another look and see if I can see what the problem was. The first strcat in the registry code should be strcpy, otherwise it would fail intermittently. If the same code was in the shortcut one, maybe that was the problem. It's encouraging to see more people taking an interest such as that NewLibertyStandard site. I like his approach to estimating the value based on electricity. It's educational to see what explanations people adopt. They may help discover a simplified way of understanding it that makes it more accessible to the masses. Many complex concepts in the world have a simplistic explanation that satisfies 80% of people, and a complete explanation that satisfies the other 20% who see the flaws in the simplistic explanation. _mmalmi@cc.hut.fi wrote:_ _> I made a Windows installer for the latest version of Bitcoin, which_ _> includes the autostart and minimize to tray features. The installer_ _> makes a start menu shortcut and a startup registry entry. I first_ _> implemented the autostart with a shortcut to the startup folder, but I_ _> found out that it doesn't always work by default and ended up doing it_ _> with a registry entry. The registry entry is removed by the uninstaller_ _> and can be also disabled from the options menu, so I don't think it's_ _> such a big menace to the user after all._ _>_ _> I made the installer with NSIS, and the nsi script can be found in the SVN._ _>_ _> Could you add the installer to the SF download page? Here's the file:_ _> http://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe_ _>_ _> There are some new users registered to the bitcoin.sf.net site. One of_ _> them just announced that he's trading Bitcoins for dollars. Here's his_ _> site: http://newlibertystandard.wetpaint.com/. Making an exchange_ _> service first seemed a bit premature for the time being, but on the_ _> other hand it's good that people show interest towards the project, and_ _> this might attract even more interested people (and hopefully more_ _> developers). I just sent the guy an email._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #36** **Date: Sun, 18 Oct 2009 18:59:42 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Setup, Autorun, v0.1.6** **To: Martti Malmi <mmalmi@cc.hut.fi>** I got it, I see you checked in the startup folder code before changing it to registry. I don't see any visible problems in the code. I guess it depends what exactly the problem was with it not always working by default. Was there a Vista/UAC security problem? **Martii Malmi (AKA Sirius) “COPA trial” email #38** **Date: Mon, 19 Oct 2009 00:11:50 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Setup, Autorun, v0.1.6** **To: mmalmi@cc.hut.fi** It's possible Bitcoin ran and bailed out because something was wrong. debug.log should tell something if that was the case. What OS are you using? I wonder if we need Admin privilege and don't realize it. Stuff that requires Admin can't start on startup on Vista. Program shortcuts have multiple tabs of settings with lots of little details. I'll try the startup folder code and see if I can reproduce the problem. Every other systray icon on my computer is in the startup folder, and it makes it easy for users to manage all their autoruns in one place. The things in the registry key tend to be devious hidden bloatware. I implemented the code to flush wallet.dat whenever it's closed so we'll be able to tell users they only need to backup wallet.dat. You can restore just wallet.dat and it'll re-download the rest. I'll have to do another stress test before release. _mmalmi@cc.hut.fi wrote:_ _> Well, the code worked and made a shortcut in the startup folder. For_ _> some reason it didn't automatically start when booting, but worked fine_ _> when you clicked on it in the menu. Now I tried making a shortcut_ _> manually, and this time it works on autostart, don't know why. I could_ _> try again with the older code._ _>_ _>> I got it, I see you checked in the startup folder code before changing_ _>> it to registry. I don't see any visible problems in the code. I guess_ _>> it depends what exactly the problem was with it not always working by_ _>> default. Was there a Vista/UAC security problem?_ _>>_ **Martii Malmi (AKA Sirius) “COPA trial” email #40** **Date: Wed, 21 Oct 2009 18:58:49 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Setup, Autorun, v0.1.6** **To: mmalmi@cc.hut.fi** Yeah, I put back your startup folder shortcut code and it started fine for me too on XP and Vista. For good measure, I changed it to make the shortcut settings look identical to one I manually created. I set the working directory to where the EXE is since that's where debug.log is created, otherwise windows puts it in some weird directory. I didn't change the setup script yet. I checked everything in to SVN (thanks for setting that up) - multi-proc generate - flush wallet.dat after every change so the DB doesn't leave that stuff in the transaction logs - view menu checkbox to hide all generated coins so you can see just your payment transactions - disabled transaction fee option - made the minimize to tray options similar to Firefox's MinimizeToTray - bunch of other misc changes since the 0.1.5 release I made it not show non-accepted generated coins. It won't show generated coins until they have at least one confirmation (one block linked after it), so usually they'll just never be seen. Occasionally a generated coin that was displayed might disappear because it became not accepted later. I don't think anyone would notice the occasional non-accepteds if we didn't point them out in the UI. People have told me they find it annoying to have to look at them, as they're permanently displayed in the transaction record. I still have more testing to do. I guess we gotta test Windows 7 now. _mmalmi@cc.hut.fi wrote:_ _>> It's possible Bitcoin ran and bailed out because something was wrong._ _>> debug.log should tell something if that was the case. What OS are you_ _>> using? I wonder if we need Admin privilege and don't realize it._ _>> Stuff that requires Admin can't start on startup on Vista._ _>_ _> I'm using XP. I recompiled the older revision and this time the startup_ _> shortcut works. It also works when testing on Vista (non-admin). Maybe I_ _> just missed something the previous time._ _>_ _>> Program shortcuts have multiple tabs of settings with lots of little_ _>> details. I'll try the startup folder code and see if I can reproduce_ _>> the problem. Every other systray icon on my computer is in the startup_ _>> folder, and it makes it easy for users to manage all their autoruns in_ _>> one place. The things in the registry key tend to be devious hidden_ _>> bloatware._ _>_ _> Here it's the other way around, I have all my startup programs in the_ _> registry. But maybe the shortcut method is nicer for the user, if it_ _> works just as well_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #41** Date: Sat, 24 Oct 2009 00:55:06 +0100 From: Satoshi Nakamoto <satoshin@gmx.com> Subject: Re: [bitcoin-list] Does Bitcoin Crash in Windows? To: Liberty Standard <newlibertystandard@gmail.com> Cc: bitcoin-list@lists.sourceforge.net _Liberty Standard wrote:_ _> Do you Windows users experience occasional Bitcoin crashes?_ _> Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was_ _> just wondering whether this is a Wine issue or a Bitcoin issue._ I haven't had any reports of crashes in v0.1.5. It's been rock solid for me on Windows. I think it must be Wine related. If you get another crash in Wine and it prints anything on the terminal, e-mail me and I may be able to figure out what happened, maybe something I can work around. Martti and I have been working on a new version to release soon and it would be nice to get any Wine fixes in there. _> The following four lines print from the terminal when I start Bitcoin._ _> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot_ _> fixme:toolhelp:Heap32ListFirst : stub_ _> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot_ _> fixme:toolhelp:Heap32ListFirst : stub_ Those don't look like anything to worry about. Probably functions unimplemented by Wine that are harmlessly stubbed out. _> I previously wasn't starting Bitcoin from the terminal, so I don't know what_ _> gets printed out when it crashes, but I'll reply with the results the next_ _> time it crashes._ _>_ _> While Bitcoin first downloads previously completed blocks, the file_ _> debug.log grows grows to 17.4 MB and then stops growing. I imagine it will_ _> continue to grow as more bitcoins are completed._ You can delete debug.log occasionally if you don't want to take the disk space. It's just status messages that help with debugging. bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing some maintenance. Satoshi **Martii Malmi (AKA Sirius) “COPA trial” email #42** **Date: Mon, 26 Oct 2009 17:50:10 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Fw: bitcoin.sourceforge.net** **To: Martti Malmi <mmalmi@cc.hut.fi>** Any idea what's going on with it? Every time I look, it's fine. _Eugen Leitl wrote:_ _On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:_ _> > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing_ _Doesn't work right now._ _> > some maintenance._ _Liberty Standard wrote:_ _> In case you weren't aware, the Bitcoin website is down._ _>_ _> http://bitcoin.sourceforge.net/_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #44** **Date: Tue, 27 Oct 2009 04:45:47 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fw: bitcoin.sourceforge.net** **To: mmalmi@cc.hut.fi** Sourceforge is just so darn slow. I don't know what else to do though. It's such a standard, more often than not any given project has a projectname.sourceforge.net site. When I see whatever.sourceforge.net in a google search, I assume that's the official site. Is there a way to make Bitweaver allow users to edit (and maybe delete) their own messages in the forum? Getting antsy to port to Linux? It's not a decision to be taken lightly because once it's done, it doubles my testing and building workload. Although I am worried about Liberty's Wine crashes. I've tried to be as portable as possible and use standard C stuff instead of Windows calls. The threading is _beginthread which is part of the standard C library. wxWidgets has wxCriticalSection stuff we can use. The sockets code is send/recv stuff which I think is the same as unix because Microsoft ported sockets from BSD. We need direct control over sockets, it wouldn't be a good idea to get behind an abstraction layer. wxWidgets is a good place to look for cross-platform support functions. I want to avoid #ifdefing up the code if we can. Anything that's used more than once probably becomes a function in util.cpp that has the #ifdef in it. BTW, I have a lot of uncommitted changes right now because it includes some crucial protocol transitions that can't be unleashed on the network until I've tested the heck out of it. It shouldn't be too much longer. Can you make the setup uninstall the Startup folder icon? I figure it should install and uninstall an icon in a regular program group, and just uninstall the Startup folder one. I guess it doesn't matter that much whether it installs and uninstalls the Startup folder icon or just uninstalls it. **Martii Malmi (AKA Sirius) “COPA trial” email #46** **Date: Thu, 29 Oct 2009 02:05:30 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fw: bitcoin.sourceforge.net** **To: mmalmi@cc.hut.fi** I'll convert the CriticalSection code to wxCriticalSection and upload it to SVN (it's a little tricky). I don't know what to do for TryEnterCriticalSection though. I think I'm almost ready to check everything in. You're probably right, it's about time to do a linux build. I've been working on getting my linux machine set up and building the dependencies. > Ok. I replaced the Windows thread and socket library includes with their > POSIX equivalents, and now it only gives a few errors, mostly from the > CriticalSections. If I make it work, I'll put it into svn/branches, it > doesn't need to be an official release yet. **Martii Malmi (AKA Sirius) “COPA trial” email #48** **Date: Thu, 29 Oct 2009 06:38:30 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** The easy solution I took was to look at the wxWidgets source code and see how they did it. They just mapped it to wxMutex on non-MSW, which does have TryEnter, so that mapped in perfectly. I checked in all my backlog of changes to SVN, including the overhaul of CCriticalSection in util.h and OpenSSL's mutex callback in util.cpp to do everything with wxWidgets when not on Windows. If we get it working on Linux, I'll run my test suite against it here off-network first, then we can give an unreleased build to LibertyStandard to test for a while before going public. **Martii Malmi (AKA Sirius) “COPA trial” email #49** **Date: Fri, 30 Oct 2009 01:05:45 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: Martti Malmi <mmalmi@cc.hut.fi>** I fixed some non-portable stuff I came across: QueryPerformanceCounter %I64d in printf format strings Sleep CheckDiskSpace If there's any other unportable stuff you know of I should fix, let me know. I think I'll move debug.log and db.log into the same directory as the data files (%appdata%\Bitcoin), rather than whatever the current directory happens to be. **Martii Malmi (AKA Sirius) “COPA trial” email #51** **Date: Sat, 31 Oct 2009 20:09:58 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** heapchk() is just a MSVCRT debugging thing that's not being used. It can be a no-op on Linux. OpenSSL automatically uses /dev/urandom to seed on Linux, so RandAddSeedPerfmon can also be a no-op. Don't let it connect to the network before we've tested it thoroughly off-net. If you have two computers, unplug the internet and use "bitcoin -connect=<ip>" to connect to each other, one windows and one linux. -connect will allow you to connect to non-routable addresses like 192.168.x.x. We don't want to reflect badly on the reliability of the network if it throws off some malformed crud we hadn't thought to check for yet, or discovers something else anti-social to do on the network. I have time that I can do some testing when you've got something buildable to test. I can include it in the stress test I'm currently running on the changes so far. _mmalmi@cc.hut.fi wrote:_ _> I made an #ifdef to replace QueryPerformanceCounter with Linux's_ _> gettimeofday in util.h. Some Unicode/ANSI errors were resolved without_ _> code changes when I updated to wxWidgets 2.9. The only compile error I'm_ _> getting in Linux at the moment is from heapchk() in util.h._ _>_ _>> I fixed some non-portable stuff I came across:_ _>> QueryPerformanceCounter_ _>> %I64d in printf format strings_ _>> Sleep_ _>> CheckDiskSpace_ _>>_ _>> If there's any other unportable stuff you know of I should fix, let me_ _>> know._ _>>_ _>> I think I'll move debug.log and db.log into the same directory as the_ _>> data files (%appdata%\Bitcoin), rather than whatever the current_ _>> directory happens to be._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #53** **Date: Tue, 03 Nov 2009 15:53:25 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build, proxy** **To: mmalmi@cc.hut.fi** Great, I've been looking forward to working on the Linux build. If you connect to Freenode's hidden service, then they tell you they've also banned TOR from that due to abuse and it kicks you off. There's a several step procedure you can do to run a password utility on unix and e-mail request an account that you could login with, but that's getting pretty complicated. I wonder if we could get away with applying for one account and then everyone use the same account? I suppose the IRC server probably limits accounts to one login, or some admin might not like to see a dozen logins on the same account. Besides the IRC part, how did your test of proxy go? Since you've been connected before, your addr.dat contains known node addresses, but without IRC to know which ones are online, it takes a long time to find them. There are normally 1 to 3 other nodes besides you that can accept incoming connections, and existing nodes that already know you would eventually connect to you. How many connections did you get, and how long did it take? I guess to know whether it successfully connected outbound through TOR you'd need to search debug.log for "connected". To originally connect with TOR without connecting normally once to get seeded, you'd have to know the address of an existing node that can accept incoming connections and seed it like this: bitcoin -proxy=127.0.0.1:9050 -addnode=<ip of a node> If some nodes that accept incoming connects were willing to have their IP coded into the program, it could seed automatically. Or some IP seed addresses posted on a Wiki page with the instructions. Another option is to search the world again for an IRC server that doesn't ban TOR nodes. Or if we could get someone to set one up. IRC servers ban TOR because they have actual text chat on them... if there was one with just bots and junk then it wouldn't care. Probably should post a question on the forum or the mailing list and see if anyone knows one. Another problem is that TOR users can't accept incoming connections, and we have so few that can. If everyone goes to TOR, there won't be any nodes to connect to. We have a shortage of nodes that can accept incoming connections. It generally ranges from 2 to 4 lately. We need to emphasize the importance to people of setting up port forwarding on their router. Every P2P file sharing program has instructions how to do it. We should have a paragraph on the bitcoin.sourceforge.net homepage urging people to set up port forwarding to accept incoming connections, and a link to a site that describes how to do it for each router. _mmalmi@cc.hut.fi wrote:_ _> I uploaded what I've ported so far to the svn/branches. Util, script, db_ _> and the headers compile fully now and net.cpp partially, so there's_ _> still work to do._ _>_ _> _beginthread doesn't have a direct Linux equivalent, so I used Boost_ _> threads instead._ _>_ _> I couldn't get connected using the Tor SOCKS proxy. That might be_ _> because of the Freenode Tor policy which requires connecting to their_ _> hidden service: http://freenode.net/irc_servers.shtml#tor_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #54** **Date: Wed, 04 Nov 2009 05:38:17 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** It was almost there. I fixed a few things and got it to finish compiling but I don't know the system libraries to link to so there's undefined references galore. I changed the makefile to look for things under /usr/local and in their default "make install" locations. I wrote what I did and switches I used in build-unix.txt. I'm currently using wxWidgets 2.8.9 for now because it's the same version as on Windows and I don't want to wonder if there's version change issues at the same time as platform change. 2.8.10 or 2.9.0 are probably fine though. I went with the single-library compile of wxWidgets since we're linking to almost every library anyway. I added xpm files, which is what they use everywhere else but Windows instead of RC files. They're clever C files that define graphics in static arrays. The bitcoin icon has 5 different versions but I couldn't figure out how that works in xpm so I only put the biggest one. Maybe on GTK it scales it for you. I don't know if these are right or what, but they compile. _mmalmi@cc.hut.fi wrote:_ _> I uploaded what I've ported so far to the svn/branches. Util, script, db_ _> and the headers compile fully now and net.cpp partially, so there's_ _> still work to do._ _>_ _> _beginthread doesn't have a direct Linux equivalent, so I used Boost_ _> threads instead._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #55** **Date: Wed, 04 Nov 2009 20:38:03 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** Just letting you know I'm still working on the Linux build so we don't duplicate work. I got it linked and ran it and working through runtime issues like getting it switched to load bitmaps from xpm instead of resources. There are debian packages available for some of the dependencies instead of having to compile them ourselves: apt-get install build-essential apt-get install libgtk2.0-dev apt-get install libssl-dev I need to see if Berkeley DB or Boost have packages. We'll shared-link OpenSSL, I'm pretty sure it's always preinstalled on Linux. GTK has to be shared linked. I'm not completely sure if it's preinstalled by default.

Kicking the Hornet's Nest - part 19

# Kicking the Hornet's Nest - third edition - part 19 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 425 - 450 ---- ##### BitcoinTalk #### Re: New web service: obtain dump of bitcoin block NNNN ##### _2010-08-27 16:13:16 UTC_ - [-](https://bitcointalk.org/index.php?topic=928.msg11400#msg11400) That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day. ##### BitcoinTalk #### Re: Bitcoins are most like shares of common stock ##### _2010-08-27 16:39:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=845.msg11403#msg11403) Bitcoins have no dividend or potential future dividend, therefore not like a stock. More like a collectible or commodity. ##### BitcoinTalk #### Re: Bitcoin does NOT violate Mises' Regression Theorem ##### _2010-08-27 17:32:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=583.msg11405#msg11405) As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties: - boring grey in colour - not a good conductor of electricity - not particularly strong, but not ductile or easily malleable either - not useful for any practical or ornamental purpose and one special, magical property: - can be transported over a communications channel If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it. Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it. I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something. (I'm using the word scarce here to only mean limited potential supply) ##### BitcoinTalk #### Version 0.3.11 with upgrade alerts ##### _2010-08-27 21:54:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=941.msg11439#msg11439) Version 0.3.11 is now available. Changes: - Some blk*.dat checking on load - Built the -4way code with -march=amdfam10, which makes it a little faster - Warning if your clock is too far off - Warnings/errors/alerts can also be seen in the getinfo command - Alert system The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update. In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade: sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them. This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information. Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork. Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/) ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-28 14:27:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg11503#msg11503) The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower. ##### BitcoinTalk #### Re: Version 0.3.11 with upgrade alerts ##### _2010-08-28 14:54:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=941.msg11505#msg11505) [_**Quote from: torservers on August 28, 2010, 01:00:37 PM**_](https://bitcointalk.org/index.php?topic=941.msg11499#msg11499) _The "About" dialog still shows 0.3.10.1 beta._ What OS? I ran the Windows and 64-bit Linux version and checked the about dialog. The Mac version is still 0.3.10.1. [_**Quote from: pavelo on August 28, 2010, 07:36:07 AM**_](https://bitcointalk.org/index.php?topic=941.msg11481#msg11481) _iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok._ I updated the first post to be more specific. Only the -4way code is compiled this way. ##### BitcoinTalk #### Re: Big endian code problems ##### _2010-08-29 22:14:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=816.msg11610#msg11610) The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat. Big-endian is on its way out anyway. ##### BitcoinTalk #### Re: CryptoPP Assertion Error ##### _2010-09-05 23:25:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=967.msg12062#msg12062) You can probably just comment out the line cryptopp/secblock.h:187 //assert(false); Let me know if it works, and watch if it memory leaks. It looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm. ##### BitcoinTalk #### Re: Warning : Check your system ( Help me ) ##### _2010-09-05 23:36:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=960.msg12063#msg12063) Any suggestions for better text to put for this error message so the next person will be less likely to be confused? It's trying to tell them their clock is wrong and they need to correct it. It's relying on 3 time sources: 1) the system clock 2) the other nodes, if within an hour of the system clock if those disagree, then 3) the user (asking the user to fix the system clock) I've thought about NTP, but this is more secure. ##### BitcoinTalk #### Re: HTTP status codes from the JSON-RPC api ##### _2010-09-06 21:21:21 UTC_ - [-](https://bitcointalk.org/index.php?topic=969.msg12130#msg12130) This is in SVN rev 147. This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be _objects_ not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs. If you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string. Also in SVN rev 147: - The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256. - The "backupwallet <destination>" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy. ##### BitcoinTalk #### Re: Warning : Check your system ( Help me ) ##### _2010-09-06 21:41:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=960.msg12132#msg12132) [_**Quote from: Insti on September 06, 2010, 12:51:37 PM**_](https://bitcointalk.org/index.php?topic=960.msg12101#msg12101) [_**Quote from: satoshi on September 05, 2010, 11:36:20 PM**_](https://bitcointalk.org/index.php?topic=960.msg12063#msg12063) Any suggestions for better text to put for this error message so the next person will be less likely to be confused? _"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly."_ Thanks. ##### BitcoinTalk #### Re: auto backing up of wallet.dat ##### _2010-09-06 21:45:10 UTC_ - [-](https://bitcointalk.org/index.php?topic=921.msg12134#msg12134) rpc backupwallet <destination> is in SVN rev 147. ##### BitcoinTalk #### Re: bitcoind as daemon in OSX ##### _2010-09-06 21:52:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=992.msg12135#msg12135) Can you build? Try changing line 78 of init.cpp from: #ifdef __WXGTK__ to: #ifndef __WXMSW__ If that works, I'll change the source. It should work. ##### BitcoinTalk #### Re: Always pay transaction fee? ##### _2010-09-07 16:32:21 UTC_ - [-](https://bitcointalk.org/index.php?topic=994.msg12168#msg12168) Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee. The threshold should probably be lower than it currently is. I don't think the threshold should ever be 0. We should always allow at least some free transactions. ##### BitcoinTalk #### Version 0.3.12 ##### _2010-09-07 19:17:55 UTC_ - [-](https://bitcointalk.org/index.php?topic=999.msg12181#msg12181) Version 0.3.12 is now available. Features: - json-rpc errors return a more standard error object. (thanks to Gavin Andresen) - json-rpc command line returns exit codes. - json-rpc "backupwallet" command. - Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes. If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread: [http://BitcoinTalk.org/index.php?topic=969.0](http://bitcointalk.org/index.php?topic=969.0) Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/) ##### BitcoinTalk #### Re: Always pay transaction fee? ##### _2010-09-08 17:30:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=994.msg12237#msg12237) Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway. It's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block. I did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions: There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day. Average transaction bytes per block was 428 bytes, or 214 bytes per transaction. The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block. The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event. ##### BitcoinTalk #### Re: Version 0.3.12 ##### _2010-09-08 18:06:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=999.msg12240#msg12240) Bitcoin clients currently only create and recognize transactions that match two possible templates. Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will only work on adding those transactions to their block. In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them. ##### BitcoinTalk #### Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins? ##### _2010-09-08 20:27:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=955.msg12248#msg12248) [_**Quote from: BitLex on September 07, 2010, 08:10:54 PM**_](https://bitcointalk.org/index.php?topic=955.msg12189#msg12189) _AMD X3 @2.8ghz ->stock client ~3800khs ~150Watt_ Did you try -4way? _**Quote**_ _How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second._ AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that) There's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually. [http://BitcoinTalk.org/index.php?topic=820.0](http://bitcointalk.org/index.php?topic=820.0) ##### BitcoinTalk #### Auto-detect for 128-bit 4-way SSE2 ##### _2010-09-09 01:04:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=1007.msg12262#msg12262) SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2. It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw. Here's what I ended up with: **Code:** // We need Intel Nehalem or AMD K10 or better for 128bit SSE2 // Nehalem = i3/i5/i7 and some Xeon // K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II // Intel Core i5 family 6, model 26 or 30 // Intel Core i7 family 6, model 26 or 30 // Intel Core i3 family 6, model 37 // AMD Phenom family 16, model 10 bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) || (fAMD && nFamily * 10000 + nModel >= 160010)); I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs. If it's wrong, you can still override it with -4way or -4way=0. It prints what it finds in debug.log. Search on CPUID. This is only enabled if built with GCC. ##### BitcoinTalk #### Re: Won't let me send coins because it requires a transaction fee? ##### _2010-09-10 00:23:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341) What version is the one where this happened? Release build, or built it yourself? Which operating system? Were you sending by IP or by Bitcoin Address? When you sent 49.99, did it prompt you to pay a 0.01 fee? There was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge. The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way. ##### BitcoinTalk #### Re: Won't let me send coins because it requires a transaction fee? ##### _2010-09-10 00:46:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=1013.msg12342#msg12342) I think I know what happened. Doubleclick on the generated transaction. It probably has a sub-0.01 transaction fee in it. Someone has been paying a 0.00000010 transaction fee. I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it. Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee. It would normally be harmless except in this corner case. I should add a special case to CreateTransaction to handle this. ##### BitcoinTalk #### Re: Won't let me send coins because it requires a transaction fee? ##### _2010-09-10 17:12:33 UTC_ - [-](https://bitcointalk.org/index.php?topic=1013.msg12368#msg12368) The fix is in SVN rev 151. You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade. ##### BitcoinTalk #### Re: Auto-detect for 128-bit 4-way SSE2 ##### _2010-09-10 18:11:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372) [_**Quote from: teknohog on September 09, 2010, 07:32:05 PM**_](https://bitcointalk.org/index.php?topic=1007.msg12336#msg12336) _Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to #if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE) to make it compile again, at least on ARM._ Added in SVN rev 152 ##### BitcoinTalk #### Re: Running on a port other than 8333 ##### _2010-09-12 17:40:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=589.msg12483#msg12483) [**Quote from: lachesis on August 10, 2010, 03:24:55 PM**](https://bitcointalk.org/index.php?topic=589.msg8544#msg8544) It does not -- did my own tests. Is there a way to open BerkeleyDB exclusive? DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time. I've dropped the DB_PRIVATE flag in rev 153. ##### BitcoinTalk #### Re: RFC: remove DB_PRIVATE flag ##### _2010-09-12 18:00:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=920.msg12484#msg12484) Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different. On Windows at least, it creates six __db.001 - __db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind. The docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply. Tests on Windows private LAN download of 78500 blocks: with DB_PRIVATE 20 minutes 51 seconds without DB_PRIVATE 20 minutes 51 seconds I wasn't expecting them to come out exactly the same. ##### BitcoinTalk #### Re: Switch to GPL ##### _2010-09-12 19:24:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=989.msg12494#msg12494) If the only library is closed source, then there's a project to make an open source one. If the only library is GPL, then there's a project to make a non-GPL one. If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it. I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone. ##### BitcoinTalk #### Re: Memory leak ##### _2010-09-19 17:22:03 UTC_ - [-](https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201) Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch? Did you compile it or is this a release build, and what version? I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second? The wait function on linux is: inline void Sleep(int64 n) { boost::thread::sleep(boost::get_system_time() + boost::posix_time::milliseconds(n)); } If that doesn't work right, then it would be possible for it to spin through the loop as fast as it can. ##### BitcoinTalk #### Re: Issues building bitcoin on Windows 7 ##### _2010-09-19 18:46:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206) The lines it's tripping on: **Code:** ERROR extern map<string, string> mapAddressBook; ERROR extern CCriticalSection cs_mapAddressBook; ERROR extern vector<unsigned char> vchDefaultKey; OK extern bool fClient; OK extern int nBestHeight; OK extern unsigned int nWalletDBUpdated; ERROR extern DbEnv dbenv; So it's acting like nothing is defined, not even map and vector. Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h. Is VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using? There's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe. [http://tdm-gcc.tdragon.net/](http://tdm-gcc.tdragon.net/) Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason. ##### BitcoinTalk #### Re: Bug? /usr/bin/bitcoind "" ##### _2010-09-19 19:58:11 UTC_ - [-](https://bitcointalk.org/index.php?topic=1063.msg13211#msg13211) I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice. We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion. I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them. ##### BitcoinTalk #### Re: The case for removing IP transactions ##### _2010-09-19 21:49:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=1048.msg13219#msg13219) Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default. In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful. In general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses. I uploaded this change to SVN rev 156. The switch to enable is "-allowreceivebyip". Senders with this version will get the error "Recipient is not accepting transactions sent by IP address". Older version senders will get "Transfer was not accepted". I used a different name for the switch because "-allowiptransactions" sounds like it includes sending. If there's a better name for the switch, we can change it again. ##### BitcoinTalk #### Re: Message Encryption as a built-in feature? ##### _2010-09-19 22:47:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=1032.msg13221#msg13221) Theymos already said this... ECDSA does not support encrypting messages. Only digital signatures. ##### BitcoinTalk #### Re: Always pay transaction fee? ##### _2010-09-23 16:08:35 UTC_ - [-](https://bitcointalk.org/index.php?topic=994.msg13829#msg13829) [_**Quote from: satoshi on September 08, 2010, 05:30:14 PM**_](https://bitcointalk.org/index.php?topic=994.msg12237#msg12237) The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block. I implemented this change in SVN rev 157. The reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together. ##### BitcoinTalk #### Internal version number ##### _2010-09-23 16:19:08 UTC_ - [-](https://bitcointalk.org/index.php?topic=1269.msg13831#msg13831) In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around. ##### BitcoinTalk #### Re: How To Make a Distributed BitCoin Escrow Service ##### _2010-09-26 17:34:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=1283.msg14136#msg14136) It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here: [http://BitcoinTalk.org/index.php?topic=750.0](http://bitcointalk.org/index.php?topic=750.0) It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough. In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion. ##### BitcoinTalk #### Re: I broke my wallet, sends never confirm now. ##### _2010-09-30 16:38:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714) As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature. I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them. I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant. The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations. I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly. If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon. If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up. change: if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0) continue; to: if (pcoin->GetDepthInMainChain() < 1) continue; ##### BitcoinTalk #### 0.3.13 RC1 for Windows, please test ##### _2010-09-30 17:04:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=1322.msg14722#msg14722) 0.3.13 release candidate, to be released soon so please test: [http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe) - don't count or spend payments until they have 1 confirmation [http://BitcoinTalk.org/index.php?topic=1306.0](http://bitcointalk.org/index.php?topic=1306.0) - internal version number from 312 to 31300 - only accept transactions sent by IP address if -allowreceivebyip is specified - dropped DB_PRIVATE Berkeley DB flag - fix problem sending the last cent with sub-cent fractional change - auto-detect whether to use 128-bit 4-way SSE2 on Linux Gavin Andresen: - option -rpcallowip= to accept json-rpc connections from another machine - clean shutdown on SIGTERM on Linux ##### BitcoinTalk #### Re: BitCoin Wikipedia page DELETED!!! ##### _2010-09-30 17:50:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=652.msg14729#msg14729) If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is. I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of. The article could be as simple as something like: "Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/." The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is. ##### BitcoinTalk #### Re: Prioritized transactions, and tx fees ##### _2010-09-30 18:11:56 UTC_ - [-](https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732) It ramps up the fee requirement as the block fills up: <50KB free 50KB 0.01 250KB 0.02 333KB 0.03 375KB 0.04 etc. It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers. Just including the minimum 0.01 goes a long way. ##### BitcoinTalk #### Re: Prioritized transactions, and tx fees ##### _2010-09-30 18:22:22 UTC_ - [-](https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734) True, the switch should be something more dynamic that pays per KB. It's harder to think of how to explain it. ##### BitcoinTalk #### Re: Remote RPC access ##### _2010-09-30 18:27:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736) It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other. 0.3.13 RC1 is available for Windows: [http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe) ##### BitcoinTalk #### Re: 0.3.13 RC1 for Windows, please test ##### _2010-10-01 00:32:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=1322.msg14787#msg14787) Too late for 0.3.13, but I'll try to find time to add it to the next version. ##### BitcoinTalk #### Version 0.3.13, please upgrade ##### _2010-10-01 00:34:35 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg14788#msg14788) Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2. Changes: - Don't count or spend payments until they have 1 confirmation. - Internal version number from 312 to 31300. - Only accept transactions sent by IP address if -allowreceivebyip is specified. - Dropped DB_PRIVATE Berkeley DB flag. - Fix problem sending the last cent with sub-cent fractional change. - Auto-detect whether to use 128-bit 4-way SSE2 on Linux. Gavin Andresen: - Option -rpcallowip= to accept json-rpc connections from another machine. - Clean shutdown on SIGTERM on Linux. Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/) (Thanks Laszlo for the Mac OSX build!) Note: The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right: [http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz) You can still control the SSE2 use manually with -4way and -4way=0. Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it: [http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe) ##### BitcoinTalk #### Re: Version 0.3.13 ##### _2010-10-03 18:17:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15102#msg15102) [_**Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM**_](https://bitcointalk.org/index.php?topic=1327.msg14997#msg14997) _That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client. I still have to add the "-4way" switch._ Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode. Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have? Do all AMDs that support 64-bit have the better SSE2 hardware also? ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 19:39:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15110#msg15110) Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this. These are binaries only. The linux version is 64-bit only. [http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip) [http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz) SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better. ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 19:49:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112) [_**Quote from: tcatm on October 03, 2010, 07:45:45 PM**_](https://bitcointalk.org/index.php?topic=1327.msg15111#msg15111) _983 Mhash/s box._ Seriously? What hardware is that? ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 20:02:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116) **Code:** diff -u old\main.cpp new\main.cpp --- old\main.cpp Sun Oct 03 20:57:20 2010 +++ new\main.cpp Sun Oct 03 20:57:54 2010 @@ -2831,6 +2831,10 @@ bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) || (fAMD && nFamily * 10000 + nModel >= 160010)); + // AMD reports a lower model number in 64-bit mode + if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004) + fUseSSE2 = true; + static bool fPrinted; if (!fPrinted) { @@ -2989,6 +2993,17 @@ // Transaction fee based on block size int64 nMinFee = tx.GetMinFee(nBlockSize); + //////// temporary code + if (nBlockSize < MAX_BLOCK_SIZE_GEN / 10 && GetWarnings("statusbar") == "") + { + if (nBestHeight < 91000) + nMinFee = 0; + if (nBestHeight < 100000 && nTxSize < 2000) + nMinFee = 0; + if (nBestHeight < 110000 && nBestHeight % 10 == 0) + nMinFee = 0; + } + //////// temporary code map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool); if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee)) diff -u old\serialize.h new\serialize.h --- old\serialize.h Sun Oct 03 20:57:45 2010 +++ new\serialize.h Sun Oct 03 20:57:54 2010 @@ -22,8 +22,8 @@ class CAutoFile; static const unsigned int MAX_SIZE = 0x02000000; -static const int VERSION = 31300; -static const char* pszSubVer = ""; +static const int VERSION = 31301; +static const char* pszSubVer = " test1"; ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 20:54:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136) [_**Quote from: theymos on October 03, 2010, 08:09:51 PM**_](https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118) _ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm._ Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain. Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours. If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them. [_**Quote from: theymos on October 03, 2010, 08:09:51 PM**_](https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118) _The person who originally sent the broken transactions deleted his wallet_ Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet. [_**Quote from: tcatm on October 03, 2010, 08:10:47 PM**_](https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119) _It's running. Should find a block within 3 hours._ It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least. ##### BitcoinTalk #### Re: [PATCH] increase block size limit ##### _2010-10-03 21:07:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139) [_**Quote from: theymos on October 03, 2010, 08:28:39 PM**_](https://bitcointalk.org/index.php?topic=1347.msg15126#msg15126) _Applying this patch will make you incompatible with other Bitcoin clients._ _+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment._ We can phase in a change later if we get closer to needing it. **Martii Malmi (AKA Sirius) “COPA trial” email #235** **Date: Sun, 03 Oct 2010 21:27:29 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: SMF php code** **To: Martti Malmi <mmalmi@cc.hut.fi>** I noticed my custom captcha stuff is gone. I guess it got lost in an upgrade? What are we doing for captcha now? If we only have default captcha, we'd be getting flooded with spam accounts. Do I need to re-integrate the custom captcha stuff or do we have another solution now? ##### BitcoinTalk #### Re: How to overthrow the GPU Oligarchs ##### _2010-10-03 21:30:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=1332.msg15142#msg15142) [_**Quote from: theymos on October 02, 2010, 06:11:11 AM**_](https://bitcointalk.org/index.php?topic=1332.msg14966#msg14966) [_**Quote from: lzsaver on October 02, 2010, 05:49:47 AM**_](https://bitcointalk.org/index.php?topic=1332.msg14960#msg14960) _Can you tell more about it: "they have to do weird things with extraNonce, which increases the size of the block header"._ _When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception._ This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header. We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't. extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible. Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too. ##### BitcoinTalk #### Re: Version 0.3.13, please upgrade ##### _2010-10-03 21:43:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=1327.msg15147#msg15147) ShadowOfHarbringer, is yours faster with -4way? If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2. The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit. ----

Kicking the Hornet's Nest - part 18

# Kicking the Hornet's Nest - third edition - part 18 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 400 - 425 ---- ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 22:58:08 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9573#msg9573) Don't update the block chain download. When you take someone's block chain download, you don't want it right up to the end. A somewhat old one is better so it can download and verify the most recent blocks. tcatm's 4-way SSE2 SHA-256 is in the file sha256.cpp and already uploaded a few revs ago. I just now uploaded rev 134 which is the makefile.unix that enables building with it on Linux. If you build rev 134 on Linux now you'll get the -4way switch. If you have problems building because of it, then edit makefile.unix and: - remove -DFOURWAYSSE2 - remove obj/sha256.o from the end of these lines: bitcoin: $(OBJS) obj/ui.o obj/uibase.o obj/sha256.o bitcoind: $(OBJS:obj/%=obj/nogui/%) obj/sha256.o The 0.3.10 linux build _will_ have the -4way option when I build it. Here are the patch downloads for Windows:[http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe) [http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip) SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip Steps: 1) Shut down. 2) Download knightmb's blk files and replace your blk0001.dat and blkindex.dat files. [http://knightmb.dyndns.org/files/bitcoin/blocks/](http://knightmb.dyndns.org/files/bitcoin/blocks/) [http://rapidshare.com/files/413168038/BitcoinBlocks.torrent](http://rapidshare.com/files/413168038/BitcoinBlocks.torrent) 3) Upgrade to 0.3.10. 4) It should start out with less than 74000 blocks and redownload the rest. Or if you don't want to mess with downloading blk files, you can just do this: 1) Shut down. 2) Delete (or move) blk*.dat 3) Upgrade to 0.3.10. 4) It redownloads all blocks, probably take about an hour. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 23:17:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9576#msg9576) [_**Quote from: knightmb on August 15, 2010, 10:59:04 PM**_](https://bitcointalk.org/index.php?topic=823.msg9574#msg9574) _**[edit]**_ _Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain._ ![](file:///tmp/lu30467eu8.tmp/lu30468pn7_tmp_3ab8f56be9600311.gif) Just leave the old one alone! Older is better. What block number is it? Anywhere from 60000-74000 is good. The one that you've had available for a while has been vetted and is the best choice. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 23:36:10 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9584#msg9584) Starting at 67000 is _perfect_. Yeah, at the moment you'll stop at 74638. It should start slowly creeping up as more nodes upgrade and generate. Linux build links below. The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5 and AMD CPU's. Use the "-4way" switch to enable it and check if it's faster for you. Download links: [http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.10-win32-setup.exe) [http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.10-win32.zip) [http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.10-linux.tar.gz) SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 23:37:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9586#msg9586) [_**Quote from: Joozero on August 15, 2010, 11:32:43 PM**_](https://bitcointalk.org/index.php?topic=823.msg9582#msg9582) _I think that you should add something about this:_ [_http://_BitcoinTalk.org_/index.php?topic=259.0_](http://bitcointalk.org/index.php?topic=259.0)_There must be a label on the client that show a warning message if needed_ ![](file:///tmp/lu30467eu8.tmp/lu30468pn7_tmp_b56eb9f04b2623cd.gif)_ Now everyone have always to check the website, and I think that this is bad._ Agree, wanted to do that for a long time, haven't had time to do it. For now, you could also subscribe to the **bitcoin-list** mailing list. It rarely gets used except for announcements like this and major new versions. Subscribe/unsubscribe page:[http://lists.sourceforge.net/mailman/listinfo/**bitcoin-list**](http://lists.sourceforge.net/mailman/listinfo/bitcoin-list) ##### BitcoinTalk #### Version 0.3.10 - block 74638 overflow PATCH! ##### _2010-08-15 23:48:22 UTC_ - [-](https://bitcointalk.org/index.php?topic=827.msg9590#msg9590) Version 0.3.10 patches the block 74638 overflow bug. [http://BitcoinTalk.org/index.php?topic=823](http://bitcointalk.org/index.php?topic=823) The Linux version includes tcatm's 4-way SSE2 SHA-256 that makes generating faster on i5, i7 (with hyperthreading) and AMD CPU's. Try the "-4way" switch to enable it and check if it's faster for you. Download from sourceforge: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.10/) SHA1 16645ec5fcdb35bc54bc7195309a1a81105242bb bitcoin-0.3.10-win32-setup.exe SHA1 4f35ad7711a38fe8c880c6c9beab430824c426d3 bitcoin-0.3.10-win32.zip SHA1 e3fda1ddb31b0d5c35156cacd80dee6ea6ae6423 bitcoin-0.3.10-linux.tar.gz SHA1 b812ccff4881778b9090f7c0b0255bcba7b078ac bitcoin-0.3.10-macosx.zip It is no longer necessary to delete blk*.dat. The good block chain has overtaken the bad block chain, so you can just upgrade and it'll automatically reorg away the bad block chain. ##### BitcoinTalk #### Re: 0.3.10.1 Question on where block should be ##### _2010-08-16 00:28:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=828.msg9608#msg9608) I suspect there's some difficulty receiving blocks if all the nodes you're connected to are 0.3.9 or lower. We need enough of us so that at least one node you connect to will be 0.3.10. The problem will start to go away when we make up more than 1/8th of the network. It'll help if you port forward so you can get lots of connections. ##### BitcoinTalk #### Re: 0.3.10.1 Question on where block should be ##### _2010-08-16 00:37:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=828.msg9612#msg9612) For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 01:00:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9623#msg9623) [_**Quote from: Ground Loop on August 16, 2010, 12:29:55 AM**_](https://bitcointalk.org/index.php?topic=823.msg9609#msg9609) _Question about fallout: I had a_ _**transaction**_ _that I submitted after the bad block, using the bad block chain. What is the status of that transaction? From what I can tell, my (updated) sending client wallet shows the deducted amount. Will it get reincorporated into the fixed chain, and will the recipient be able to spend it?_ Right, it will get reincorporated into the fixed chain. The transaction won't disappear, it'll still be visible on both sides, but the confirmation count will jump back to 0 and start counting up again. It's only if you generated a block in the bad chain after block 74638 that the 50 BTC from that will disappear. Any blocks in the bad chain wouldn't have matured yet. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 01:02:24 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9624#msg9624) [_**Quote from: kosovito on August 16, 2010, 12:39:17 AM**_](https://bitcointalk.org/index.php?topic=823.msg9615#msg9615) _I did all steps, now my client is 0.3.10 and it stopped at block 74638. Is all fine?_ If you still show 74638 blocks then you aren't connected to any 0.3.10 nodes. For today, try adding these parameters: -addnode=75.158.131.108 -addnode=99.27.237.13 -addnode=68.68.99.14 See [http://BitcoinTalk.org/index.php?topic=828](http://bitcointalk.org/index.php?topic=828) ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 01:12:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9628#msg9628) [_**Quote from: trebronics on August 16, 2010, 01:02:35 AM**_](https://bitcointalk.org/index.php?topic=823.msg9625#msg9625) _Most people running clients are not reading this message thread. So... Silly questions: 1) How will this continue to affect version 3.8.1 (pre-catastrophe) clients with bad block chain? 2) How will this affect clients that upgrade to 3.8.10 but don't remove their block chain files?_ 1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations. 2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 02:16:10 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9642#msg9642) The bad chain is also slowed down as more nodes upgrade. We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 02:38:21 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9648#msg9648) On Windows, findstr /c:"version message" debug.log It looks like the bad chain was on block 74678 recently. Can't wait to overtake it. On the stats at [http://nullvoid.org/bitcoin/statistix.php](http://nullvoid.org/bitcoin/statistix.php) there's been 5 blocks per hour in the last 3 hours. We had a difficulty adjustment about a day ago that should have put it back to 6 blocks per hour. #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-16 02:57:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9655#msg9655) [_**Quote from: tcatm on August 16, 2010, 12:43:39 AM**_](https://bitcointalk.org/index.php?topic=820.msg9617#msg9617) _I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%._ _GCC 4.3.3 doesn't support -march=amdfamk10. I get: sha256.cpp:1: error: bad value (amdfamk10) for -march= switch_ [_**Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM**_](https://bitcointalk.org/index.php?topic=820.msg9630#msg9630) _With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way._ Hey, you may be onto something! hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share. tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2. How much of an improvement do you get with hyperthreading? Some numbers? What CPU is that? ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-16 03:23:04 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9661#msg9661) [_**Quote from: Vasiliev on August 16, 2010, 03:17:07 AM**_](https://bitcointalk.org/index.php?topic=820.msg9660#msg9660) _try -march=amdfam10_ That works. That's strange... are we sure that's the same thing? tcatm, try amdfam10 and make sure you get the same speed measurement. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-16 04:36:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9676#msg9676) [_**Quote from: jgarzik on August 16, 2010, 03:35:28 AM**_](https://bitcointalk.org/index.php?topic=820.msg9665#msg9665) _**Code:**_ _cpu family : 6 model : 26 model name : Genuine Intel(R) CPU 000 @ 3.20GHz stepping : 4_ cpu family 6 model 26 stepping 4 is an Intel Core i7. That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading. 33% faster with hyperthreading than without it. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 12:59:38 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9734#msg9734) It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now. That means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain. Thanks to everyone for the quick response! ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-16 13:38:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9736#msg9736) I wrapped sha256.cpp in #ifdef FOURWAYSSE2 #endif // FOURWAYSSE2 try it now. ##### BitcoinTalk #### Re: [PATCH] Automatic block validation ##### _2010-08-16 15:25:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=832.msg9754#msg9754) That's a difficult approach. We need to cause a reorg, which will disconnect the invalid chain. This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best. Here's what I was thinking of. (I haven't tested this yet) It checks all the blocks in the main chain. If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg. (It can't change pindexBest without actually doing a reorg) This isn't perfect yet. It still needs to receive one valid block to trigger the reorg. It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below. **Code:** bool CTxDB::LoadBlockIndex() { ... // Verify blocks in the main chain vector<CBlockIndex*> vChain; for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev) { vChain.push_back(pindex); CBlock block; if (!block.ReadFromDisk(pindex)) return error("LoadBlockIndex() : block.ReadFromDisk failed"); if (!block.CheckBlock()) { bnBestChainWork = pindex->pprev->bnChainWork; foreach(CBlockIndex* pindex2, vChain) pindex2->bnChainWork = 0; } } return true; } ##### BitcoinTalk #### blocks minus 1 ##### _2010-08-16 15:59:25 UTC_ - [-](https://bitcointalk.org/index.php?topic=837.msg9757#msg9757) I'd like to reduce the number of blocks displayed in the status bar by 1. When you first load the program, it'll display 0 blocks instead of 1: "0 connections 0 blocks 0 transactions" It's always been "nBestHeight + 1" because it's counting the genesis block. Technically, yes, the genesis block is a block. It's a hardcoded block that you start out with. You can't _not_ have the genesis block. Maybe think of it as a reference coin that you measure other coins against. The block count people are looking for is the number of blocks they've downloaded. The main benefit is that blocks will be equal to the block number of the current best block. If blocks is 10, then the highest block number you have is 10. It means you have block 10 and you don't have block 11. It would reduce the confusion we had here: [_**Quote from: kencausey on August 15, 2010, 11:45:26 PM**_](https://bitcointalk.org/index.php?topic=823.msg9588#msg9588) [_**Quote from: davidonpda on August 15, 2010, 11:31:37 PM**_](https://bitcointalk.org/index.php?topic=823.msg9580#msg9580) _... It already is on block 74638. I assume that means that block is now a good one?_ _ I had some confusion on this myself and got clarification in #bitcoin-dev: The bad block was number 74638, the last good one was 74637. The numbers start at 0, so when your client shows there are 74638 blocks then that means you have up to block number 74637, the last good one._ ##### BitcoinTalk #### Re: blocks minus 1 ##### _2010-08-16 17:06:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=837.msg9774#msg9774) Done in SVN rev 137 ##### BitcoinTalk #### Re: [PATCH] Automatic block validation ##### _2010-08-16 17:08:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=832.msg9775#msg9775) [**Quote from: satoshi on August 16, 2010, 03:25:54 PM**](https://bitcointalk.org/index.php?topic=832.msg9754#msg9754) It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention. I probably should break out part of AddToBlockIndex that sets the new best block. I'll probably end up doing that instead of the code below. This is what I ended up doing in SVN rev 139. Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out. ##### BitcoinTalk #### Checking the block chain on load ##### _2010-08-16 20:07:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=841.msg9813#msg9813) SVN rev 139 does a basic check of the block chain after loading. With this we wouldn't have needed to delete blk*.dat, it would have automatically done a reorg back to the fork. There wasn't time to do a careful implementation of this at the time. It might take longer than we want, since it has to load all the blocks. If it's too slow, we could have it only go back to a certain block number. ##### BitcoinTalk #### Re: checkpointing the block chain ##### _2010-08-16 20:20:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=834.msg9816#msg9816) There is no way for the software to automatically know if one chain is better than another except by the greatest proof-of-work. In the design it was necessary for it to switch to a longer chain no matter how far back it has to go. The only exception to that is the manual checkpoints I've added. If it weren't for those, it would be able to reorg all the way back to the first block. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-16 22:54:55 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9841#msg9841) Un-upgraded nodes have the correct chain most of the time, but they are still trying to include the overflow transaction in every block, so they're continually trying to fork and generate invalid blocks. If an old version node is restarted, its transaction pool is emptied, so it may generate valid blocks for a while until the transaction gets broadcast again. 0.3.9 and lower nodes still must upgrade. The SVN now has the code we needed to automatically reorg the block chain without having to delete the blk*.dat files manually. I knew I couldn't write that code fast and carefully enough yesterday, so I went with the quick manual option. ##### BitcoinTalk #### Re: checkpointing the block chain ##### _2010-08-16 23:01:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=834.msg9843#msg9843) [_**Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM**_](https://bitcointalk.org/index.php?topic=834.msg9839#msg9839) _How is the strength of the chain calculated?_ Total proof-of-work. ##### BitcoinTalk #### Re: New screenshots to the front page? ##### _2010-08-18 16:58:44 UTC_ - [-](https://bitcointalk.org/index.php?topic=850.msg10067#msg10067) Definitely. The old screenshots of 0.1 are very outdated. Windows Aero is a good choice. Windows is still the largest user group. Mind what's behind it for the transparent parts. What to have displayed in the transaction list? Not completely filled up with stuff, just a few things. ##### BitcoinTalk #### Re: Difficulty: More nodes active, or faster nodes? ##### _2010-08-18 18:01:40 UTC_ - [-](https://bitcointalk.org/index.php?topic=846.msg10076#msg10076) The performance numbers posted from a VIA C7's hardware SHA-256 weren't astronomical. Only in the 1500 khash/s range. If you think about it, just because it's implemented in hardware doesn't mean it's crazy fast. It still has to do all the steps. It's only if simplifying it down to single-purpose hardware makes it small enough to fit many in parallel. That's not necessarily easy or a given. ##### BitcoinTalk #### Re: Checking the block chain on load ##### _2010-08-18 18:28:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=841.msg10082#msg10082) In the next SVN rev, I'll make it only go back to the last checkpoint at block 74000. If we need to correct a problem in the future, we can always make sure it goes back at least as far back as the problem. Also, I'm adding code to verify the block index, which means the proof-of-work chain is checked. Still, the system won't be entirely secure against your blk*.dat files. You are trusting someone if you use a copy of their blk files. ##### BitcoinTalk #### Re: Convert Bitcoin to GTK: Yes? No? wx is better? ##### _2010-08-19 18:44:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=867.msg10272#msg10272) [_**Quote from: BioMike on August 19, 2010, 08:05:18 AM**_](https://bitcointalk.org/index.php?topic=867.msg10226#msg10226) _WxWidgets is not really a problem. My problem is the version that is used (2.9), which is considered unstable by many distro packagers (although the WxWidgets devs say it isn't). On the other side, as far as I know WxWidgets uses gtk under Linux for drawing the whole stuff and makes it for the bitcoins devs easy to make things cross platform._ wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all platforms including Windows. The distro packages of 2.8 are UTF-16, so they just trip people up. People had endless build problems with 2.8 and its wxString UTF-16/ANSI conditional build options until we standardized on 2.9. Also, to use 2.8, we were using ANSI, which was just a temporary stopgap until wxWidgets supported UTF-8. This is a problem that will solve itself. With time, 2.9 will become a more mainline release. ##### BitcoinTalk #### Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic) ##### _2010-08-19 18:55:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=868.msg10275#msg10275) That's a really well written walkthough. Someone should confirm if they followed it and didn't run into any snags. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-19 19:07:43 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg10281#msg10281) [_**Quote from: Ground Loop on August 18, 2010, 11:14:26 PM**_](https://bitcointalk.org/index.php?topic=820.msg10167#msg10167) _Any non-Mac i5 love? Windows i5 64-bit got slower here._ That's the first I've heard anyone say i5 was slower. Everyone else has said 4way was faster on i5. Moreso with hyperthreading enabled. [_**Quote from: nelisky on August 18, 2010, 11:02:25 PM**_](https://bitcointalk.org/index.php?topic=820.msg10164#msg10164) _And i5, at least on my macbookpro_ Good, so I take it that's a confirmation that it's working on Mac as well? Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac. I don't think makefile.osx on SVN has it yet, just the built version. ##### BitcoinTalk #### Re: 28 days without generation, i have 4200khash/s ##### _2010-08-19 19:40:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=862.msg10290#msg10290) Make sure your computer's date and time are correct. ##### BitcoinTalk #### Need a post writing up some things users should know ##### _2010-08-19 20:14:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=873.msg10297#msg10297) I'm not sure what to call it, but we could use a post that lists these things users should know. If someone has time to write it, here's the list: - Make sure your clock is set correctly. - Microsoft Security Essentials. This never got written up proper. - Warning not to mess around with your wallet.dat file. It's a database file, it's not as simple as you think. In this Beta version, we haven't had time to try and tinker-proof it yet. It may not work as expected if you start swapping it around. ##### BitcoinTalk #### Re: Hypothetical question on lost coins / transfers ##### _2010-08-19 20:28:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=870.msg10300#msg10300) That's right. You don't need to be re-broadcasting your transactions for it to work. When any node disconnects a fork, it dumps all the transactions from the fork back into the transaction pool to add to the new chain. The entire network is making sure to re-integrate your transactions again. All you should see is that your number of confirmations starts over from 0. In some types of forks, your transaction would have gotten into both forks already, so you're already good either way. ##### BitcoinTalk #### Re: Need a post writing up some things users should know ##### _2010-08-22 22:51:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=873.msg10715#msg10715) The clock part will be covered in the next release (0.3.11 or higher). SVN rev 141 pops up a message box if your clock is too far off. ##### BitcoinTalk #### Re: 28 days without generation, i have 4200khash/s ##### _2010-08-22 23:01:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=862.msg10717#msg10717) Search debug.log for "proof-of-work found". If you find any, then check for any errors right after that. [_**Quote from: davidonpda on August 19, 2010, 07:43:01 PM**_](https://bitcointalk.org/index.php?topic=862.msg10291#msg10291) _How big of a margin on the time is allowed for things to work right._ The margin is 2 hours. This should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-22 23:21:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg10720#msg10720) Thanks for clearing that up. I read the link someone posted about AMD making that change around 2007, but I didn't know what the story was for Intel. There's no hope for Core/Core2 then. They only have half the SSE2 hardware. Strange that Intel has 3 128bit units, but AMD with 2 128bit units is the faster one. ##### BitcoinTalk #### Development of alert system ##### _2010-08-22 23:55:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg10722#msg10722) I've been working on writing the alert system. Alerts are broadcast through the network and apply to a range of version numbers. Alert messages are signed with a private key that only I have. Nodes can do two things in response to an alert: - Put a warning message on the status bar. - Make the money handling methods of the json-rpc interface return an error. In cases like the overflow bug or a fork where users may not be able to trust received payments, the alert should keep old versions mostly safe until they upgrade. Manual users should notice the status bar warning when looking for received payments, and the json-rpc safe mode stops automated websites from making any more trades until they're upgraded. The json-rpc methods that return errors during an alert are: sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel ##### BitcoinTalk #### Re: integrating digital payments into p2p protocols ##### _2010-08-22 23:57:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=890.msg10723#msg10723) Hey Zooko! I wanted to thank you for posting about Bitcoin on your blog a year or two ago, back when I announced it on the **Cryptography Mailing List**. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-24 22:43:56 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg11068#msg11068) [_**Quote from: ArtForz on August 21, 2010, 04:56:31 PM**_](https://bitcointalk.org/index.php?topic=820.msg10609#msg10609) - _AMD K10: 2 128bit units_ - _intel nehalem: 3 128bit units_ This probably explains why hyperthreading increases performance with -4way. If three SSE2 units is excessive, then hyperthreading would help keep them all busy. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-24 23:51:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11074#msg11074) If you're so paranoid that you're getting hysterical over this, then surely you're paranoid enough that if a warning message displays on the status bar, you'll check the website and forum. I think if another bug like the overflow bug occurs, it's important that automated websites stop trading until their admins can check out what's going on and decide what to do. If you decide it's a false alarm and want to take your chances, you can use the "-disablesafemode" switch. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-25 00:06:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11078#msg11078) This is in SVN rev 142 as version 0.3.11. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-25 15:17:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11150#msg11150) It can't do arbitrary actions remotely. Maybe some of you are responding to other posters who suggested the alert system should do more? If there is an alert, the following json-rpc methods return an error: sendtoaddress getbalance getreceivedbyaddress getreceivedbylabel listreceivedbyaddress listreceivedbylabel The remaining 14 methods function as normal. I believe the safer option should be enabled by default. If you want your server to keep trading and ignore an alert saying the money its receiving might be like the money from the overflow bug, then you can use the switch and not blame anyone else if you lose your money. Worst case if you leave alerts enabled, your site stops trading until you upgrade or add the -disablesafemode switch. Getting surprised by some temporary down time when your node would otherwise be at risk is better than getting surprised by a thief draining all your inventory. Someday when we haven't found any new bugs for a long time and it has been thoroughly security reviewed without finding anything, this can be scaled back. I'm not arguing that this is the permanent way of things forever. It's still beta software. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-25 16:40:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11151#msg11151) I changed the switch name to -disablesafemode. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-25 16:56:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11155#msg11155) [_**Quote from: jimbobway on August 25, 2010, 04:45:22 PM**_](https://bitcointalk.org/index.php?topic=898.msg11153#msg11153) [_**Quote from: BioMike on August 23, 2010, 05:15:43 AM**_](https://bitcointalk.org/index.php?topic=898.msg10742#msg10742) _@mizerydearia, I think the quote button is easier to find then the reply one. So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand that he hands over his key (or get it from his computer) and shut down the complete network? Or is that not possible? How far would <some goverment> get?_ _ A few rhetorical questions for satoshi: Can you resist waterboarding? Can you endure electric shock? All forms of torture? Lastly, are you Jack Bauer by any chance? Seriously._ WRT the alert system, who cares? The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade. All nodes keep running and generating, the network stays up. If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system. It would be a temporary inconvenience only. [_**Quote from: BioMike on August 23, 2010, 05:15:43 AM**_](https://bitcointalk.org/index.php?topic=898.msg10742#msg10742) _So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand that he hands over his key (or get it from his computer) and shut down the complete network?_ This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network". ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-25 17:59:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11158#msg11158) [_**Quote from: nelisky on August 25, 2010, 01:28:32 AM**_](https://bitcointalk.org/index.php?topic=898.msg11092#msg11092) _So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?_ getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar. The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert. I added the switch "-testsafemode" for you. SVN rev 145. This stuff is very new and may still be subject to change. [_**Quote from: mizerydearia on August 25, 2010, 12:11:50 AM**_](https://bitcointalk.org/index.php?topic=898.msg11079#msg11079) _I just discovered_ [_http://www.bitcoin.org/wiki/doku.php?id=man_page_](http://www.bitcoin.org/wiki/doku.php?id=man_page)_and don't see any reference to -disablesafemode. Perhaps it should be added! Also others liek -4way should be added as well._ Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release. -4way should eventually be replaced by an auto-detect. ##### BitcoinTalk #### Re: Development of alert system ##### _2010-08-26 00:08:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=898.msg11219#msg11219) [_**Quote from: BioMike on August 25, 2010, 06:23:45 PM**_](https://bitcointalk.org/index.php?topic=898.msg11162#msg11162) [_**Quote from: satoshi on August 25, 2010, 04:56:15 PM**_](https://bitcointalk.org/index.php?topic=898.msg11155#msg11155) [_**Quote from: BioMike on August 23, 2010, 05:15:43 AM**_](https://bitcointalk.org/index.php?topic=898.msg10742#msg10742) _So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand that he hands over his key (or get it from his computer) and shut down the complete network? Or is that not possible? How far would <some goverment> get?_ This is what makes me think the people objecting don't know what they're talking about. It can't "shut down the complete network". _I've never objected this change/idea, just asking if this was possible and to what extent. What's wrong with getting informed?_ ![](file:///tmp/lu30467eu8.tmp/lu30468pn7_tmp_3ab8f56be9600311.gif) My apologies, your post was indeed a question not a statement. ##### BitcoinTalk #### Re: RFC: remove DB_PRIVATE flag ##### _2010-08-26 00:33:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=920.msg11224#msg11224) Can you provide more details about what removing DB_PRIVATE does? I can't remember if I had a specific reason for DB_PRIVATE, or if I just copied the flags from some example code. Does removing DB_PRIVATE make it safe for other processes to open the database simultaneously? That may be an improvement, depending what the side effects are. Does it substantially reduce performance by making it have to write out every change immediately or do other coordination? Are there additional locking or coordination files then? What else changes? You could test by timing an initial block download with and without DB_PRIVATE, preferably -connect-ing to a local machine so network isn't a factor. Apparently, DB_PRIVATE doesn't do what you would hope it would do, which is prevent other processes from being able to open the database. It still lets them, it just screws up if they do. Another option, if there's a way, would be to make it lock the database files so they can't be accessed by other processes. ##### BitcoinTalk #### Re: Need a post writing up some things users should know ##### _2010-08-26 00:44:05 UTC_ - [-](https://bitcointalk.org/index.php?topic=873.msg11227#msg11227) Any backup process/procedure would just be a stopgap until there's time to properly work on coding solutions in software. We can try to use words to help the situation until code gets there. The main backup improvement will be pre-made pool of keys, and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time. ##### BitcoinTalk #### Re: auto backing up of wallet.dat ##### _2010-08-26 00:57:40 UTC_ - [-](https://bitcointalk.org/index.php?topic=921.msg11228#msg11228) I started posting in the other topic but I'll repeat here, this thread seems more specific to the topic. The main backup improvement will be a pre-generated pool of keys and a rescan at load to scrape missed transactions from the block history. Then a backup will last forward for a long time. I was starting to post the same idea you said nelisky. How about a json-rpc command that locks the wallet, flushes it, copies wallet.dat to a location you specified, then unlocks it? That would be a smaller project than the pooled keys, so maybe it could be done first. What's the simplest portable way to copy a file? Is there something in Boost? What should it be named? maybe: backupwallet <destination> ##### BitcoinTalk #### Re: Gentoo Linux Ebuild ##### _2010-08-27 00:49:43 UTC_ - [-](https://bitcointalk.org/index.php?topic=930.msg11342#msg11342) Try -datadir= Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it. There wasn't time to investigate at the time. One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there. -lwx_gtk2ud-2.9 only matches the right configuration. It fails if wxWidgets was built with the wrong configuration. _**Quote**_ _Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used._ Did they say why they were baffled? _**Quote**_ _This is because on my system the path is /usr/include/wx-2.9/wx/wx.h_ Why is it there? Was it included by the OS, or did you have to build it? If you built it, I wonder why it would put itself in a different place. Has wxWidgets 2.9 finally started to become available as a debian package? Maybe we should do this: INCLUDEPATHS= \ -I"/usr/local/include/wx-2.9" \ -I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \ -I"/usr/include/wx-2.9" \ -I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9" Again, those paths help make sure it's only 2.9 and will fail with 2.8. wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile. ##### BitcoinTalk #### Re: auto backing up of wallet.dat ##### _2010-08-27 01:13:42 UTC_ - [-](https://bitcointalk.org/index.php?topic=921.msg11345#msg11345) If you read it into memory and write it out, it could fail in tight memory situations. I'm looking for something like copyfile(const char* from, const char* to) or copyfile(path from, path to), preferably something in Boost if it has it. If you find it for me, it's more likely I'll get to implementing it. [_**Quote from: nelisky on August 26, 2010, 01:21:57 AM**_](https://bitcointalk.org/index.php?topic=921.msg11232#msg11232) _As for the file copy, why add to the boost dependency? I for one would love to get a core lib with very little deps._ We require Boost for JSON and a dozen things replacing dependencies on wxWidgets. Boost is good, portable stuff, we should not shy away from it. ##### BitcoinTalk #### Re: auto backing up of wallet.dat ##### _2010-08-27 02:54:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=921.msg11350#msg11350) I doubt there's an mmap(2) on Windows. I'd rather call an existing file copy function than make and test my own. [_**Quote from: nelisky on August 27, 2010, 01:21:09 AM**_](https://bitcointalk.org/index.php?topic=921.msg11346#msg11346) _But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill._ Thanks. I thought it would be in there somewhere. We already use boost::filesystem in a dozen places. It's not a new added dependency. It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere. **Martii Malmi (AKA Sirius) “COPA trial” email #232** **Date: Fri, 27 Aug 2010 03:36:43 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [Fwd: SweepMines now accept bitcoins]** **To: Martti Malmi <mmalmi@cc.hut.fi>** -------- Original Message -------- Subject: SweepMines now accept bitcoins Date: Tue, 24 Aug 2010 19:50:47 +0600 From: Kirill Kisel <kisel2626@gmail.com> To: satoshin@gmx.com Dear BitCoin. http://apps.facebook.com/sweepmines/ now accepts BitCoins. This is single-player computer game based on Windows Minesweeper version. Would you be so kind to add us to the http://www.bitcoin.org/trade page? Thank you. ##### BitcoinTalk #### Re: auto backing up of wallet.dat ##### _2010-08-27 15:47:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=921.msg11399#msg11399) Sorry, I've been so busy lately I've been skimming messages and I still can't keep up. We want to avoid Windows API calls whenever possible. They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple. I usually shy away from iostreams. Seems like I too often hit limitations. They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right. Using it in rpc.cpp may still turn out to be a mistake. Bottom line is I'd rather call an existing file copy function than make and test my own. ----

Kicking the Hornet's Nest - part 17

# Kicking the Hornet's Nest - third edition - part 17 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 375 - 400 ---- ##### BitcoinTalk #### Re: Bitcoin minting is thermodynamically perverse ##### _2010-08-07 17:46:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=721.msg8114#msg8114) It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange. I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, _not_having Bitcoin would be the net waste. [_**Quote from: gridecon on August 06, 2010, 04:48:00 PM**_](https://bitcointalk.org/index.php?topic=721.msg7889#msg7889) _As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins._ Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it. If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs. I suppose it might be possible to measure CPU power _at certain times_. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back. Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself. ##### BitcoinTalk #### Re: A proposal for a semi-automated Escrow mechanism ##### _2010-08-07 20:04:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=645.msg8137#msg8137) [_**Quote from: jgarzik on August 05, 2010, 07:00:30 PM**_](https://bitcointalk.org/index.php?topic=645.msg7723#msg7723) _Due to that recourse, it is unlikely to be used as an escrow mechanism_ ![](file:///tmp/lu30467eu8.tmp/lu30468nv5_tmp_b56eb9f04b2623cd.gif) Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.) ##### BitcoinTalk #### Escrow ##### _2010-08-07 20:13:52 UTC_ - [-](https://bitcointalk.org/index.php?topic=750.msg8140#msg8140) Here's an outline of the kind of escrow transaction that's possible in software. This is not implemented and I probably won't have time to implement it soon, but just to let you know what's possible. The basic escrow: The buyer commits a payment to escrow. The seller receives a transaction with the money in escrow, but he can't spend it until the buyer unlocks it. The buyer can release the payment at any time after that, which could be never. This does not allow the buyer to take the money back, but it does give him the option to burn the money out of spite by never releasing it. The seller has the option to release the money back to the buyer. While this system does not guarantee the parties against loss, it takes the profit out of cheating. If the seller doesn't send the goods, he doesn't get paid. The buyer would still be out the money, but at least the seller has no monetary motivation to stiff him. The buyer can't benefit by failing to pay. He can't get the escrow money back. He can't fail to pay due to lack of funds. The seller can see that the funds are committed to his key and can't be sent to anyone else. Now, an economist would say that a fraudulent seller could start negotiating, such as "release the money and I'll give you half of it back", but at that point, there would be so little trust and so much spite that negotiation is unlikely. Why on earth would the fraudster keep his word and send you half if he's already breaking his word to steal it? I think for modest amounts, almost everyone would refuse on principle alone. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-07 21:16:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg8145#msg8145) [_**Quote from: impossible7 on August 06, 2010, 11:37:20 AM**_](https://bitcointalk.org/index.php?topic=648.msg7838#msg7838) _CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp._ Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it. Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs. ##### BitcoinTalk #### Re: bitcoin generation broken in 0.3.8? ##### _2010-08-09 18:50:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=753.msg8388#msg8388) I found that SSE2 only added a slight 2% speedup, which didn't seem worth the incompatibility. I was trying to take the safer option. It doesn't look to me like Crypto++ could be deciding whether to use SSE2 at runtime. There's one place where it detects SSE2 for deciding some block count parameter, but the SSE2 stuff is all #ifdef at compile time and I can't see how that would switch at runtime. Maybe I'm not looking in the right place. Should we enable SSE2 in all the makefiles? It seems like we must in case someone compiles with 64-bit. I will recompile the 64-bit part of the Linux 0.3.8 release. ##### BitcoinTalk #### Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-09 19:46:58 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8402#msg8402) When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6, generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on SourceForge with the 64-bit binary updated. Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download) Future versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem? ##### BitcoinTalk #### Re: What could be the transition plan to Y2038 compliant Bitcoin? ##### _2010-08-09 20:13:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=760.msg8413#msg8413) **unsigned** int is good until 2106. Surely the network will have to be totally revamped at least once by then. There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int. ##### BitcoinTalk #### Re: bitcoin generation broken in 0.3.8? (64-bit) ##### _2010-08-09 20:34:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=753.msg8417#msg8417) I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test with it and it has generated blocks. [http://BitcoinTalk.org/index.php?topic=765.0](http://bitcointalk.org/index.php?topic=765.0) Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download) ##### BitcoinTalk #### Re: Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-09 20:55:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8422#msg8422) That's a good point, I believe you could run with generation off if you don't have SSE2. How about add to the top of cryptopp/config.h: #if !defined(_M_X64) && !defined(__x86_64__) #define CRYPTOPP_DISABLE_SSE2 1 #endif that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC) ##### BitcoinTalk #### Connection limits ##### _2010-08-09 20:58:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=766.msg8424#msg8424) SVN rev 125: - Always make 8 outbound connections even if have 8 inbound - Limit outbound connections to one per a.b.?.? range - Switch -maxconnections=# I added the (currently undocumented) switch -maxconnections=#. You shouldn't use it unless you need to because your router can't maintain a lot of connections, then try -maxconnections=30. I haven't really tested -maxconnections much, could someone test it? ##### BitcoinTalk #### Re: Bitcoin minting is thermodynamically perverse ##### _2010-08-09 21:28:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=721.msg8431#msg8431) The heat from your computer is not wasted if you need to heat your home. If you're using electric heat where you live, then your computer's heat isn't a waste. It's equal cost if you generate the heat with your computer. If you have other cheaper heating than electric, then the waste is only the difference in cost. If it's summer and you're using A/C, then it's twice. Bitcoin generation should end up where it's cheapest. Maybe that will be in cold climates where there's electric heat, where it would be essentially free. ##### BitcoinTalk #### Re: Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-10 23:46:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8628#msg8628) SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC. Other compilers might have different 64-bit defines. ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-11 00:14:22 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8637#msg8637) This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible. Originally, a coin can be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions. The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this? It's hard to think of how to apply zero-knowledge-proofs in this case. We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included. ##### BitcoinTalk #### Re: Escrow ##### _2010-08-11 01:30:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=750.msg8649#msg8649) [_**Quote from: jgarzik on August 10, 2010, 06:53:57 PM**_](https://bitcointalk.org/index.php?topic=750.msg8566#msg8566) _Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party._ That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate. When you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that. Either party always has the option to release it to the other. [_**Quote from: nelisky on August 10, 2010, 08:20:36 PM**_](https://bitcointalk.org/index.php?topic=750.msg8585#msg8585) _But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that._ Then you must also be against the common system of payment up front, where the customer loses. Payment up front: customer loses, and the thief gets the money. Simple escrow: customer loses, but the thief doesn't get the money either. Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it? Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it. Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again. It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about "money burning" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever. ##### BitcoinTalk #### Re: Compile error in SVN r127 ##### _2010-08-11 01:42:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=784.msg8651#msg8651) Updated SVN. Thanks. There's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me. **Martii Malmi (AKA Sirius) “COPA trial” email #228** **Date: Wed, 11 Aug 2010 02:54:27 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]** **To: mmalmi@cc.hut.fi** Are PM notifications still disabled? (All we really need is disable the forum's access to the mail server) _> Does it work correctly now? I had made some forum code changes to_ _> disable PM email notification, but just reverted most of them as_ _> unnecessary._ ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-11 21:07:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8798#msg8798) Still thinking this idea through... The only job the network needs to do is to tell whether a spend of an outpoint is the first or not. If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as: - the value - the association of inpoints and outpoints in one transaction The network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is. I believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment. The fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history. **Martii Malmi (AKA Sirius) “COPA trial” email #230** **Date: Wed, 11 Aug 2010 21:00:13 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]** **To: mmalmi@cc.hut.fi** Right, forgot about that. Hopefully theymos was right that the PBL is the source of the problem. mmalmi@cc.hut.fi wrote: > Yes, they're still disabled. Disabling the access to the mail server > would be easy, but we probably want to keep the password recovery by email. > ##### BitcoinTalk #### Re: Lost large number of bitcoins ##### _2010-08-11 21:46:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=782.msg8803#msg8803) [_**Quote from: sirius-m on August 11, 2010, 02:01:53 AM**_](https://bitcointalk.org/index.php?topic=782.msg8657#msg8657) _I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed._ You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds) [_**Quote from: gridecon on August 11, 2010, 08:46:08 PM**_](https://bitcointalk.org/index.php?topic=782.msg8795#msg8795) _Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction._ No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change. ##### BitcoinTalk #### Re: Where is the separate discussion devoted to possible Bitcoin weaknesses. ##### _2010-08-11 22:40:25 UTC_ - [-](https://bitcointalk.org/index.php?topic=788.msg8804#msg8804) It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old transactions, but only a limited number per time period. I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster. A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack. [_**Quote from: gavinandresen on August 11, 2010, 04:10:56 PM**_](https://bitcointalk.org/index.php?topic=788.msg8761#msg8761) _Bitcoin's p2p network is subject to various kinds of denial of service attacks. There, I said it._ +1 Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting. ##### BitcoinTalk #### Re: Flood attack 0.00000001 BC ##### _2010-08-11 23:28:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=287.msg8810#msg8810) It would be nice to keep the blk*.dat files small as long as we can. The eventual solution will be to not care how big it gets. But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore. There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI. Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance. ##### BitcoinTalk #### Re: BSD detection ##### _2010-08-12 00:02:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=790.msg8814#msg8814) [_**Quote from: dkaparis on August 11, 2010, 11:00:16 PM**_](https://bitcointalk.org/index.php?topic=790.msg8807#msg8807) _There is this piece of code in headers.h: __#ifdef __WXMAC_OSX____#define __WXMAC__ 1__#define __WXOSX__ 1__#define __BSD__ 1__#endif__#endif_ That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__. _**Quote**_ _#if (defined(__unix__) || defined(unix)) && !defined(USG)__#include <sys/param.h>__#endif_ Will that definitely cause BSD to be defined on Mac? ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-12 02:46:56 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8836#msg8836) [_**Quote from: Red on August 12, 2010, 01:10:19 AM**_](https://bitcointalk.org/index.php?topic=770.msg8824#msg8824) [**Quote from: satoshi on August 11, 2010, 09:07:59 PM**](https://bitcointalk.org/index.php?topic=770.msg8798#msg8798) I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit. _ I thought this too at first. But then I convinced myself otherwise._ Are you back to talking about the existing Bitcoin system here? I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back. If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is: 1) Show it the entire history back to the original generated coin. 2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true. But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think. ##### BitcoinTalk #### Re: BSD detection ##### _2010-08-12 21:14:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=790.msg8919#msg8919) This is in SVN rev 130. Check that it compiles right. **Code:** #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> // to get BSD define #endif #ifdef __WXMAC_OSX__ #ifndef BSD #define BSD 1 #endif #endif ##### BitcoinTalk #### Bugfixes in SVN rev 130 ##### _2010-08-12 21:20:31 UTC_ - [-](https://bitcointalk.org/index.php?topic=795.msg8920#msg8920) Misc bugfixes in rev 130: fix -datadir with relative path autostart is now off by default except on windows fix occasional "vector iterator not dereferencable" assertion when compiled with msvc fix readlink compile warning on linux build use sys/param.h and BSD define instead of __BSD__ -paytxfee switch, e.g. -paytxfee=0.01 ##### BitcoinTalk #### Re: Bitcoin Watchdog Service ##### _2010-08-12 21:34:44 UTC_ - [-](https://bitcointalk.org/index.php?topic=691.msg8922#msg8922) True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek. ISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block. I favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities. ##### BitcoinTalk #### Re: Having problems specifing -datadir ##### _2010-08-12 21:43:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=601.msg8924#msg8924) Fixed in SVN rev 130. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-12 22:07:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg8929#msg8929) That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster. A quick summary: Xeon Quad 41% slower Core 2 Duo 55% slower Core 2 Duo same (vess) Core 2 Quad 50% slower Core i5 200% faster (nelisky) Core i5 100% faster (vess) AMD Opteron 105% faster aceat64: My system went from ~7100 to ~4200. This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz. impossible7: on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121) nelisky: My Core2Quad (Q6600) slowed down 50%, my i5 improved ~200%, impossible7: on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!) ##### BitcoinTalk #### Re: Bugfixes in SVN rev 130 ##### _2010-08-13 03:15:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=795.msg8960#msg8960) No, that's not what it is. -paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using "-paytxfee=0.01". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01. It's just there in case we need it. It probably won't be needed, and it can be explained more if we do. ##### BitcoinTalk #### Re: Bitcoin Watchdog Service ##### _2010-08-13 17:09:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=691.msg9041#msg9041) _**Quote**_ _But there will be no irc server to bootstrap from._ Which doesn't matter because you can't access sourceforge to download the software either. If you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is completely redundant since 0.3.0. ##### BitcoinTalk #### Version 0.3.9 rc1, please test ##### _2010-08-13 17:40:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=806.msg9046#msg9046) Here's a test build if you'd like to help test before 0.3.9 is released. (or if you'd rather get upgrading out of the way now instead of waiting) Downloads: (binaries only) [http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip) ([http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)) SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz Edit: Linux please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This will only be for Linux: [http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz) SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz Please report back your results [http://BitcoinTalk.org/index.php?topic=820](http://bitcointalk.org/index.php?topic=820) ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-13 19:28:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg9074#msg9074) I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage? If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it. Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it. Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it. Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related. There's something here in the general area: [http://www.users.zetnet.co.uk/hopwood/crypto/rh/](http://www.users.zetnet.co.uk/hopwood/crypto/rh/) What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m. When paying to a bitcoin address, you would generate a new blinded key for each use. Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it. As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it. ##### BitcoinTalk #### Re: Proposed change to sendtoaddress API call ##### _2010-08-13 23:39:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=807.msg9134#msg9134) It's too soon to start junking up the API for backward compatibility at all costs. Just return "<txid>". ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 00:49:18 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9145#msg9145) MinGW on Windows has trouble compiling it: g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I"/boost" -I"/db/build_unix" -I"/openssl/include" -I"/wxwidgets/lib/gcc_lib/mswud" -I"/wxwidgets/include" -msse2 -O3 -o obj/sha256.o sha256.cpp sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)': sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. make: *** [obj/sha256.o] Error 1 ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 04:22:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9159#msg9159) If you haven't already, try aligning thash. It might matter. Couldn't hurt. [_**Quote from: tcatm on August 14, 2010, 12:53:07 AM**_](https://bitcointalk.org/index.php?topic=648.msg9147#msg9147) _Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?_ No help from -O0, same error. MinGW is GCC 3.4.5. Probably the problem. I'll see if I can get a newer version of MinGW. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 17:55:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9228#msg9228) Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than stock with Core 2. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 22:06:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9278#msg9278) MinGW GCC 4.5.0: Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns I only got 4-way working with test.cpp but not when called by BitcoinMiner MinGW GCC 4.4.1: Crypto++ works 4-way SIGSEGV GCC is definitely not aligning __m128i. Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable. By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only: #define Ch(b, c, d) ((b & c) ^ (~b & d)) #define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d)) #define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n)) #define SHR(x, n) _mm_srli_epi32(x, n) But that's with -O0. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-15 03:40:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9359#msg9359) On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned. I have it working fine on GCC 4.3.3 on Ubuntu 32-bit. I found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that: **Code:** --- \old\sha.cpp Mon Jul 26 13:31:11 2010 +++ ew\sha.cpp Sat Aug 14 20:21:08 2010 @@ -336,7 +336,7 @@ ROUND(14, 0, eax, ecx, edi, edx) ROUND(15, 0, ecx, eax, edx, edi) - ASL(1) + ASL(label1) // Bitcoin: fix for MinGW GCC 4.5 AS2(add WORD_REG(si), 4*16) ROUND(0, 1, eax, ecx, edi, edx) ROUND(1, 1, ecx, eax, edx, edi) @@ -355,7 +355,7 @@ ROUND(14, 1, eax, ecx, edi, edx) ROUND(15, 1, ecx, eax, edx, edi) AS2( cmp WORD_REG(si), K_END) - ASJ( jne, 1, b) + ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5 AS2( mov WORD_REG(dx), DATA_SAVE) AS2( add WORD_REG(dx), 64) ##### BitcoinTalk #### tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-15 15:52:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9452#msg9452) 0.3.10 has tcatm's 4-way SSE2 as an option switch. Use the switch "-4way" to turn it on. Without the switch you get Crypto++ ASM SHA-256. I could only get this working with Linux. Download: Get 0.3.10 from [http://BitcoinTalk.org/index.php?topic=827.0](http://bitcointalk.org/index.php?topic=827.0) Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs. ##### BitcoinTalk #### Re: Potential disaster scenario ##### _2010-08-15 16:37:16 UTC_ - [-](https://bitcointalk.org/index.php?topic=813.msg9454#msg9454) Some places where generation will gravitate to: 1) places where it's cheapest or free 2) people who want to help for idealogical reasons 3) people who want to get some coins without the inconvenience of doing a transaction to buy them There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience. How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost. There's also kids putting it on their parent's power bill, employees their employer, botnets, etc. Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change. ##### BitcoinTalk #### Re: Version 0.3.9 rc1, please test ##### _2010-08-15 18:11:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=806.msg9475#msg9475) [_**Quote from: jgarzik on August 15, 2010, 05:46:27 PM**_](https://bitcointalk.org/index.php?topic=806.msg9467#msg9467) _the extended-help might have been based on my idea, but the code was somewhat different._ The idea was the main part. When you posted your patch, I realized it should have been done that way instead of "-?". I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-15 18:23:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9478#msg9478) I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with. I'm also curious if it performs much worse on 32-bit linux vs 64-bit. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-15 18:43:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9483#msg9483) I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff. **bitcoin-list** [**bitcoin-list**] ALERT - we are investigating a problem _2010-08-15 20:38:33 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/25954806/) *** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 20:59:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9530#msg9530) Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly. **Code:** bool CheckTransaction() const { // Basic checks that don't depend on any context if (vin.empty() || vout.empty()) return error("CTransaction::CheckTransaction() : vin or vout empty"); // Check for negative and overflow values int64 nTotal = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) return error("CTransaction::CheckTransaction() : txout.nValue negative"); if (txout.nValue > 21000000 * COIN) return error("CTransaction::CheckTransaction() : txout.nValue too high"); nTotal += txout.nValue; if (nTotal > 21000000 * COIN) return error("CTransaction::CheckTransaction() : txout total too high"); } if (IsCoinBase()) { if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100) return error("CTransaction::CheckTransaction() : coinbase script size"); } else { foreach(const CTxIn& txin, vin) if (txin.prevout.IsNull()) return error("CTransaction::CheckTransaction() : prevout is null"); } return true; } Don't sticky the topic, nobody looks up there. There'll be enough posts to bump. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:06:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9531#msg9531) It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be. A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:23:55 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9539#msg9539) Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends _before_ block 74000 so the most recent security lockin will check it. Can someone find the link for that? **Martii Malmi (AKA Sirius) “COPA trial” email #231** **Date: Sun, 15 Aug 2010 21:37:28 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [bitcoin-list] ALERT - we are investigating a problem** **To: bitcoin-list@lists.sourceforge.net** *** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:40:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9548#msg9548) Patch is uploaded to SVN rev 132! For now, recommended steps: 1) Shut down. 2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files) 3) Upgrade. 4) It should start out with less than 74000 blocks. Let it redownload the rest. If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once. I'll build releases shortly. ----

Kicking the Hornet's Nest - part 10

# Kicking the Hornet's Nest - third edition - part 10 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 200 - 225 ---- **Martii Malmi (AKA Sirius) “COPA trial” email #131** **Date: Wed, 16 Dec 2009 16:54:46 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Planned release announcement text** **To: Martti Malmi <mmalmi@cc.hut.fi>** Here's the planned release announcement text. Probably releasing shortly. Bitcoin version 0.2 is here! Download links: Windows Setup Program Windows Zip File Linux (tested on Ubuntu) New features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download - Various refinements to keep the network running smoothly We also have a new forum at http://www.bitcoin.org/smf/ if you have any questions. Thanks to Martti Malmi (sirius-m) for his coding work and for hosting the new site and forum, and thanks to New Liberty Standard for testing the Linux version. Satoshi Nakamoto **BitcoinTalk** Bitcoin 0.2 released! _2009-12-16 22:45:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=16.msg73#msg73) 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-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-win32.zip/download) [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download) New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download Major thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version. **Martii Malmi (AKA Sirius) “COPA trial” email #132** **Date: Thu, 17 Dec 2009 06:49:02 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [bitcoin-list] Bitcoin 0.2 released** **To: bitcoin-list@lists.sourceforge.net** Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto **bitcoin-list** [**bitcoin-list**] Bitcoin 0.2 released _2009-12-17 06:52:09 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/24205662/) Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto **BitcoinTalk** Re: A few suggestions _2009-12-17 18:38:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=12.msg77#msg77) That's good, is it running fine on FreeBSD? I committed the changes to headers.h.\u00a0 For consistency, I used __BSD__.\u00a0 The complete list of defines is at [http://docs.wxwidgets.org/stable/wx_cppconst.html](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. **BitcoinTalk** Re: A few suggestions _2009-12-18 17:37:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=12.msg79#msg79) What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized. \u00a0The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. \u00a0Note: there's a bug with tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if it's from 64-bit or Karmic, it was fine on 32-bit Jaunty. We didn't have time to implement the "Start Bitcoin on system startup" feature on Linux in time for 0.2 so it's greyed out. \u00a0I figured Linux people wouldn't mind doing that manually anyway. \u00a0I guess they need to know about the -min switch to do it right. You can locate the data directory where you want with the "-datadir=<directory>" switch. \u00a0I know someone is already doing that to put it on a TrueCrypt USB drive. **Martii Malmi (AKA Sirius) “COPA trial” email #134** **Date: Tue, 22 Dec 2009 19:00:41 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** Thanks for creating the maintenance account, it would have been impossible to do all that without it. I'm really always going to need it. OK, I changed the password to a 20 character random password. That's a good domain. People rarely type domain names anymore, they use autocomplete or click links on search engines. I need to make a way for you to programmatically get new generated bitcoin addresses. Either that or you could have them send to your IP address, but then you have to rely on them to put the order number in the comment. When generating the new address, there can be an option to add an entry to the address book associated with the address, so the received transaction will be labelled. I kinda hid the labels after early users found them confusing, but it would be very helpful for this application. You have to widen up the comment column to see them. Are you going to manually review and enter orders, at least to begin with? I sure would. I'm thinking I should move the UI in the direction of having the user ask for their bitcoin address when they want one. "give me a bitcoin to receive a payment with". I suppose next to the send button, there would by a receive button, you press it and it says "here's a new address to use, here's the button to copy it to the clipboard, do you want to label it?" and maybe some explanation about why you shouldn't reuse addresses. Or maybe just a "New Address" button next to the address box that you should hit each time to change it. _mmalmi@cc.hut.fi wrote:_ _> I have registered the domain name bitcoinexchange.com and will start_ _> coding the service sometime soon as a nice leisure activity. I'm_ _> envisioning a simple Google-like interface with no registration and only_ _> two texts fields on the front page, where you insert the amount of money_ _> you wish to trade, and either your PayPal address to buy dollars or_ _> bitcoin address to buy bitcoins. On the next page you'll get a new_ _> bitcoin address for sending the coins or a check code for the PayPal_ _> transaction text._ _>_ _> PayPal is good for the beginning - it's simple and has no startup costs,_ _> but later on I might accept credit cards also._ _>_ _> Do you still need the maintenance account? It's ok if you do, but change_ _> the password to something else._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #136** **Date: Wed, 23 Dec 2009 17:53:18 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** _mmalmi@cc.hut.fi wrote:_ _> I'd also need at least the command line tools to check if coins have_ _> been received and to send coins. It would require some way to_ _> communicate with the Bitcoin process running in the background. I don't_ _> know how that should be done, maybe with something RPC related._ _>_ _> It would also be great if the background process was non-graphical - the_ _> VPS on the current service level doesn't have enough memory to run the X_ _> Windowing environment, unless I come up with some ways to free memory._ I had been wondering why everyone keeps harping on no-UI, when already you can run it with only a small icon on the tray, which is common for server services on Windows. So I guess this is why. I had chalked it up to unix snobbery if they couldn't abide a tiny little icon on a desktop they never see. Not opening any windows is easy, but it may fail because the gtk libraries aren't there. wxWidgets has __WXBASE__ for "Only wxBase, no GUI features". You could try building for that instead of __WXGTK__ and see what happens. It would be preferable if there's any way to do it as a command line switch on the same executable, rather than yet another build variation to release. How much memory do you have to work with? Bitcoin necessarily takes a fair bit of memory; about 75MB on Windows. Is that a problem? Command line control is one of the next things on the list. I want to design the API carefully. Receiving payments is the part that has a lot of design choices to be made. The caller needs to identify the transactions of interest, that's where the one-bitcoin-address-per-transaction model helps. Searching the comments text for an order number is another possibility. There's polled, asking what has been received to the given bitcoin address, and event driven. I guess in event driven, bitcoin would be told to run a command line when a certain amount is received to a certain bitcoin address. **Martii Malmi (AKA Sirius) “COPA trial” email #138** **Date: Fri, 25 Dec 2009 16:11:14 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** You're right, I was looking at a test run with 250,000 blocks... duh. A normal one shows 17MB memory usage and 10MB VM size. _mmalmi@cc.hut.fi wrote:_ _>> How much memory do you have to work with?_ _> The VPS has 320MB RAM, 50MB of which is currently free. There's also_ _> 500MB swap space._ _>_ _>> Bitcoin necessarily takes a_ _>> fair bit of memory; about 75MB on Windows. Is that a problem?_ _>_ _> Sure about that? Windows task manager shows about 13MB memory usage here._ _>_ **BitcoinTalk** Re: Is my second Transaction working correctly? +Transfer Question _2010-01-05 20:00:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=17.msg85#msg85) 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**_](https://bitcointalk.org/index.php?topic=17.msg84#msg84) _**Quote**_ _However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under "Status". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?_ _ The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One "generated" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a "block" a bit confusing on the first sight._ Would it be clearer if the status said "x confirmations", like: 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 confirmations 7 confirmations 8 confirmations Each block essentially means another node has confirmed that it agrees with all transactions up to that point. **BitcoinTalk** Re: 64bit support _2010-01-14 20:17:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=18.msg97#msg97) I haven't tried compiling 64-bit yet. 64-bit wouldn't make it any faster, since it uses 64-bit numbers in only a few places and SHA-256 is a 32-bit algorithm, but it may be convenient for those running a 64-bit OS. If I get a chance I'll try -m64 and see what the problem is. You can run the 32-bit version on 64-bit Linux by installing ia32-libs. (sudo apt-get install ia32-libs) If we made a Debian package, it could automatically pull that in as a dependency. **BitcoinTalk** Re: Number of connections? _2010-01-20 20:07:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=21.msg112#msg112) Coins generate at the same speed with any number of connections >= 1. More connections just add redundancy. If you only had one connection, what if that node is slow or busy, or only connected to you? Having several connections increases the certainty that you're well connected to the network. That hasn't been a problem in practice, the network is very thoroughly connected. If you have 2 or 3 connections, you're fine. **BitcoinTalk** Re: TOR and I2P _2010-01-20 22:05:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=22.msg113#msg113) I've been thinking about that for a while. I want to add the backend support for .onion addresses and connecting to them, then go from there. There aren't many .onion addresses in use for anything because the user has to go through a number of steps to create one. Configure TOR to generate a .onion address, restart TOR, configure it with the generated address. Perhaps this is intentional to keep TOR so it can't be integrated into file sharing programs in any sufficiently automated way. **BitcoinTalk** Re: Bitcoin crash when sending coins _2010-01-27 21:52:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=27.msg156#msg156) That is what happens if you copy wallet files around. If you copy your wallet file to a second computer, then they both think the money in the wallet is theirs. If one spends any of it, the other doesn't know those coins are already spent and would try to spend them again, and that's the error you would hit. Now that it's clear this is a key error message, it ought to be something more like "the money appears to be already spent... this could happen if you used a copy of your wallet file on another computer." You can move or backup your wallet file, but it needs to have only one "lineage" and only used in one place at a time. Any time you transfer money out of it, then you must no longer use any previous copies. This brings up a good point. In the case of restoring a backup that may be from before you spent some coins, we need to add functionality to resync it to discover which coins have already been spent. This would not be hard to do, it just hasn't been implemented yet. I'll add it to the list. This would make it mostly repair the situation instead of giving that error message. **BitcoinTalk** Re: A newb's test - anyone want to buy a picture for $1? _2010-01-28 01:01:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=25.msg159#msg159) Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time. I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen. Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA. **BitcoinTalk** Re: 64bit support _2010-01-29 00:42:49 UTC_ - [-](https://bitcointalk.org/index.php?topic=18.msg174#msg174) I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0. There was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0. wxWidgets 2.9.0 is UTF-8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support. I compiled and ran on 64-bit Ubuntu 9.10 Karmic. I think the only bug left is where the status number is mashed up. I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked into it. build-unix.txt is updated and two makefiles on SVN: makefile.unix.wx2.8 makefile.unix.wx2.9 Unfortunately there's still no debian package for either version of wxWidgets we use. They only have the wchar ("unicode") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets 2.9. So you still have to get it and build it yourself. **Martii Malmi (AKA Sirius) “COPA trial” email #143** _Editor’s note: this email appears timestamped PRIOR to emails #141 and #142, however it was listed AFTER emails #141 and #142 in Martii Malmi’s COPA trial email documents._ **Date: Wed, 03 Feb 2010 20:25:53 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API** **To: mmalmi@cc.hut.fi** Is there any way to find out what the missing shared libraries are? It would help to know. It probably needs the gtk libraries, in which case you'll have the same problem with the 64-bit version. I would like to have a single executable that can also run on a UI-less system, but I'm not sure how on linux to link to things but still be able to run and not use them if the library is not present. Maybe we should statically link the GTK. Licensewise, it's LGPL, but since it's only used on unix, that would be OK. (we can't link LGPL stuff on windows because we provide the OpenSSL DLL, but on linux OpenSSL comes with the OS) My 64-bit (debug stripped) executable is attached. It includes untested changes that are not in SVN yet: UI changes and the wallet fSpent flag resync stuff. I've been researching options for interprocess calling. I want something that will be easy for a variety of server side languages to call, particularly PHP. Cross-platform to windows is a plus. I'm not sure if I want it to be something that can be accessed across the network. That would introduce security issues. If it can only be accessed on the local system, then local security authentication covers it, and it is incapable of being hacked remotely. At surface level, not looking into any details yet, the current front runners are: D-Bus: local system only used by qt, gnome and skype bindings: c, python, java, c++, php listed as "in progress" .net listed as unmaintained not sure how ready it is on windows XML-RPC: widely used, built in libraries on PHP it's more for web clients to talk to server, transport is http, so its a security question Is it possible to open a socket that can only be accessed locally? _mmalmi@cc.hut.fi wrote:_ _> Have you decided upon the inter-process calling method of the Bitcoin_ _> API yet? An easy solution would be the socket interface provided by_ _> wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The_ _> Bitcoin program running a wxServer could be then accessed by calling the_ _> bitcoin executable from the command line or by coding your own wxClient_ _> app._ _>_ _> Another option would be to just use the plain BSD sockets._ _>_ _> Can you send me a 64-bit Linux binary of Bitcoin if you have one? I_ _> tried compiling on the VPS, but it ran out of memory. Tried the 32-bit_ _> version (with ia32-libs) also, but it didn't find the shared libraries._ _>_ **BitcoinTalk** Re: Bitcoin crash when sending coins _2010-02-03 23:29:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=27.msg219#msg219) I uploaded this fix to the SVN. It watches for spent coins and updates your wallet on load and also continuously as blocks come in. I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once. If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit). **BitcoinTalk** Re: Win32 CPU Cycles vs 'Live Protection' Engines ? _2010-02-03 23:36:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=35.msg220#msg220) Thanks for that. Which version of Windows? **BitcoinTalk** Re: Questions about Addresses _2010-02-04 00:07:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=34.msg222#msg222) Port forwarding forwards a port to one computer. It tells the router which computer handles connections to that port. So that's the computer receiving. If you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent. When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted. Someone should post their static IP so people can try out sending by IP and also give that user free money. There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address. If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost. A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation". **BitcoinTalk** Re: TOR and I2P _2010-02-04 00:30:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=22.msg223#msg223) When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes. If you're using another port, it would assume it might be a regular old normal proxy and would keep retrying IRC at longer and longer intervals. You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin might be trying to overcome it by reconnecting. You should use port 9050. As riX says, the "is giving Tor only an IP address. Apps that do DNS..." warnings are nothing to worry about. Bitcoin doesn't use DNS at all in proxy mode. Since Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes. It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected. It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected. For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts. Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old. **Martii Malmi (AKA Sirius) “COPA trial” email #142** _Editor’s note: this email appears timestamped PRIOR to email #141, however it was listed AFTER email #141 in Martii Malmi’s COPA trial email documents._ **Date: Thu, 04 Feb 2010 01:32:50 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Exchange options** **To: Martti Malmi <mmalmi@cc.hut.fi>** Don't rush ahead and get yourself rejected from all the payment options before you've had time to see if there's a better approach. I suggest you wait before contacting any more payment processors. You may get ideas from things other users come up with and try. Just some random incomplete ideas: There may be a way to position it as an intermediate credit for micropayments for some virtual good or something. Or maybe if the payments are only in one direction. If you only buy bitcoins, then you're only sending money out not taking people's money, that would still be useful to peg the currency. That might be payment for computer time. Credit card is only one way. Don't even talk about the idea of returning money to customer's credit cards. Credit card companies hate that. In any case, any payment processor is going to expect you to be selling something real. Do you have electronic transfer or paper cheque in your country? (even if only within Europe) **Martii Malmi (AKA Sirius) “COPA trial” email #141** **Date: Thu, 04 Feb 2010 02:20:10 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Exchange ideas** **To: Martti Malmi <mmalmi@cc.hut.fi>** You could always exchange for Liberty Reserve. It's an online currency similar to e-Bullion, Pecunix or Webmoney that allows exchanges no questions asked and with privacy. LR and the others are hard to buy but easy to cash out. Hard to buy because exchangers are very cautious about getting ripped off by reversed payments, so they require more details and holding time. Cashing out is very easy. LR is non-reversible, so there are oodles of exchanges eager to turn LR into any kind of payment. Bitcoin is the reverse, in that it's easy to get Bitcoins just by generating them. It would be easy for customers to go bitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they just want to save the money, then just bitcoin->LR. There's also the idea BTC2PSC had to sell paysafecards for bitcoins. Either online delivery by sending the card number by e-mail, or delivery of the unopened physical card in the mails. There are many variations of these cards. In some countries, they're called Gift Cards, and can be used wherever credit cards are accepted. I think they're used more by people who don't have the credit history to get a real credit card, so they buy gift cards themselves to pay for things that require a credit card. **Martii Malmi (AKA Sirius) “COPA trial” email #145** **Date: Thu, 04 Feb 2010 18:50:35 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API** **To: mmalmi@cc.hut.fi** I must have accidentally typed j instead of z. It's bz2 format. Rename to .tar.bz2 or just do tar -jxvf _> The package doesn't open, it says "not in gzip format"._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #146** **Date: Thu, 04 Feb 2010 19:33:26 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: UTF-8 to ANSI hack in CAboutDialog** **To: Martti Malmi <mmalmi@cc.hut.fi>** What was the reason for this change? #if !wxUSE_UNICODE ... if (str.Find('Â') != wxNOT_FOUND) str.Remove(str.Find('Â'), 1); to: if (str.Find('�') != wxNOT_FOUND) str.Remove(str.Find('�'), 1); wxFormBuilder turns the (c) symbol into UTF-8 automatically. On wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash character, which this hack fixes up for the non-unicode (ansi) case. **Martii Malmi (AKA Sirius) “COPA trial” email #147** Date: Thu, 04 Feb 2010 19:59:48 +0000 From: Satoshi Nakamoto <satoshin@gmx.com> Subject: Re: Bitcoin API To: mmalmi@cc.hut.fi Good, then no need to consider d-bus. Is there something like IPC sockets on Windows? I guess we could look how wx does it, or maybe the XML-RPC library will already know what to do. Windows has named pipes, maybe that's the best analogue. I don't think I want to invent my own RPC protocol, I want to use an existing standard. PHP, Java, Python or anything will be able to talk to the server directly the same way the command line commands do. I'm going to start reading on XML-RPC. It's coming up in searches as the most widely used protocol and widely supported. PHP includes it in its standard libraries. _>> Is it possible to open a socket that can only be accessed locally?_ _>_ _> Yes, you can use IPC sockets ("Unix domain sockets") which are local_ _> only. That's done in the wx-api by using a filename in place of a port_ _> number. I committed an example of how the wxServer-Client communication_ _> is used, you can revert if you want to. Now there's the -blockamount_ _> command line option which asks the running instance for the block chain_ _> length._ _>_ _> I think this command line method could already be used from PHP, but it_ _> might be lighter if php itself could call the socket server directly._ _> The wx's IPC overview mentions wxSocketEvent, wxSocketBase,_ _> wxSocketClient and wxSocketServer as being "Classes for the low-level_ _> TCP/IP API", which might be easier to use from php than what I used now_ _> (wxServer, wxClient, wxConnection). I'll look more into it._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #148** **Date: Fri, 05 Feb 2010 04:08:54 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API research status** **To: Martti Malmi <mmalmi@cc.hut.fi>** I noticed this in the docs for wxSocketServer::Accept(bool wait = true): "If wait is true and there are no pending connections to be accepted, it will wait for the next incoming connection to arrive. **Warning: This will block the GUI." wxWidgets is pathologically single-threaded. Not only single-threaded, but must-be-the-GUI-thread-ed. Even for something as non-UI as wxStandardPaths I got nailed. All this is fine for UI code, since this is the same constraint placed by Windows anyway, but for UI-less server daemon code, wx calls are uncertain. Status of my research currently: For PHP, Python, etc to access the server, we need to use regular sockets. I think we can make it local-only by binding to localhost only, so it can only be accessed through the loopback. They say it's also watertight to simply check the IP of connections received and disconnect anything not 127.0.0.1. May as well do both. XML-RPC is a bit fat. There are 4 libraries for C++ but they're all big and hard to build, dependencies, license issues. Some posters complain all the C++ and PHP XML-RPC libraries are buggy. JSON-RPC is a simpler more elegant standard. It's simple enough I could use a generic JSON parser. PHP, Python and Java all have good implementations of JSON-RPC. I'm currently leaning towards JSON-RPC. **Martii Malmi (AKA Sirius) “COPA trial” email #151** **Date: Fri, 05 Feb 2010 18:29:12 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Exchange options** **To: mmalmi@cc.hut.fi** Maybe the current difficulty of buying LR is already the limit of how easy it can get in that direction. Every conventional payment method has refutability as their way to cope with their lack of passwords and crypto. The system is wide open to copying plaintext credit card numbers and account numbers, and they deal with it by reversing the transaction after the fact. The system works for physical goods that have to be delivered somewhere, and services which can't be resold. It's a problem when it interfaces with precious metals and currency conversion. The first step of being easy in one direction, bitcoin->LR or anything of established value, goes a long way. Even those who don't use the conversion still benefit from knowing that they could. Trading bitcoin becomes an easier way to trade the ability to claim LR, similar to how paper money was once the right to claim gold. Nobody has to ever actually claim the LR to get the benefit of having the option that they could if they wanted to. A lot of times you just need a minuscule amount of online currency. The hassle of buying the other online currencies is too much for buying a small amount. The ease of getting a small amount of bitcoin may help bootstrap an ecosystem of sellers of micropayment sized online goods selling to that market. If the sellers can get LR for bitcoins, they're happy, and that may be subsidized at first by investors who want to buy bc in large lots. The main thing holding online currencies back is the lack of an easy way to get a small amount of currency. Bitcoin opens that up. It'll be the only online currency that's both easy to cash out and easy to get a small amount. It'll just be the usual harder difficulty to buy a large amount. _mmalmi@cc.hut.fi wrote:_ _> Liberty Reserve sounds good. I could first make a service that only_ _> accepts LR, and add more options later. The weakness is that buying LR_ _> is an extra step of inconvenience when the customer just wants to get_ _> Bitcoins. But maybe I don't have too much choice here._ _>_ _>> Do you have electronic transfer or paper cheque in your country? (even_ _>> if only within Europe)_ _>_ _> Yes, electronic bank transfer is available. During 2010 most European_ _> countries will become a part of SEPA (Single Euro Payments Area), which_ _> means that all payments within Europe are to be considered domestic._ _> Banks will have to apply the same fees and standards to all domestic_ _> transfers, so they'll probably all be free of charge and complete in one_ _> bank day. For international transfers there's the SWIFT/IBAN system,_ _> which usually costs some extra._ _>_ _> A longer term project for my exchange service would be to see what kinds_ _> of integration options the banks have to offer. Bank transfers would_ _> reach nearly as many customers as credit cards do._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #152** **Date: Fri, 05 Feb 2010 18:39:18 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: UTF-8 to ANSI hack in CAboutDialog** **To: mmalmi@cc.hut.fi** Right, I'll change it to this so it doesn't get broken again: if (str.Find('\xC2') != wxNOT_FOUND) str.Remove(str.Find('\xC2'), 1); _mmalmi@cc.hut.fi wrote:_ _> I didn't change it knowingly, must have been some encoding problem._ _>_ _>> What was the reason for this change?_ _>>_ _>> #if !wxUSE_UNICODE_ _>> ..._ _>> if (str.Find('Â') != wxNOT_FOUND)_ _>> str.Remove(str.Find('Â'), 1);_ _>> to:_ _>> if (str.Find('�') != wxNOT_FOUND)_ _>> str.Remove(str.Find('�'), 1);_ _>>_ _>> wxFormBuilder turns the (c) symbol into UTF-8 automatically. On_ _>> wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra_ _>> trash character, which this hack fixes up for the non-unicode (ansi)_ _>> case._ _>_ **BitcoinTalk** Proof-of-work difficulty increasing _2010-02-05 19:19:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg249#msg249) We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009. The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that. For most of last year, we were hovering below the minimum. On 30 Dec we broke above it and the algorithm adjusted to more difficulty. It's been getting more difficult at each adjustment since then. The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year. That means you generate only 55% as many coins for the same amount of work. The difficulty adjusts proportionally to the total effort across the network. If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate. For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log. It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block. It gets adjusted every 2016 blocks, typically two weeks. That's when it prints "GetNextWorkRequired RETARGET" in debug.log. minimum 00000000ffff0000000000000000000000000000000000000000000000000000 30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000 11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000 25/01/2010 00000000be710000000000000000000000000000000000000000000000000000 04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000 14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000 08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000 21/03/2010 0000000038137500000000000000000000000000000000000000000000000000 01/04/2010 000000002a111500000000000000000000000000000000000000000000000000 12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000 21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000 04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000 19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000 29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000 11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000 24/06/2010 000000000d314200000000000000000000000000000000000000000000000000 06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000 13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000 16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000 27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000 05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000 15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000 26/08/2010 0000000000692000000000000000000000000000000000000000000000000000 date, difficulty factor, % change 2009 1.00 30/12/2009 1.18 +18% 11/01/2010 1.31 +11% 25/01/2010 1.34 +2% 04/02/2010 1.82 +36% 14/02/2010 2.53 +39% 24/02/2010 3.78 +49% 08/03/2010 4.53 +20% 21/03/2010 4.57 +9% 01/04/2010 6.09 +33% 12/04/2010 7.82 +28% 21/04/2010 11.46 +47% 04/05/2010 12.85 +12% 19/05/2010 11.85 -8% 29/05/2010 16.62 +40% 11/06/2010 17.38 +5% 24/06/2010 19.41 +12% 06/07/2010 23.50 +21% 13/07/2010 45.38 +93% 16/07/2010 181.54 +300% 27/07/2010 244.21 +35% 05/08/2010 352.17 +44% 15/08/2010 511.77 +45% 26/08/2010 623.39 +22% **BitcoinTalk** Re: Questions about Addresses _2010-02-05 19:44:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=34.msg250#msg250) [_**Quote from: Sabunir on February 05, 2010, 05:31:30 PM**_](https://bitcointalk.org/index.php?topic=34.msg246#msg246) _Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?_ That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it. It's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost. **BitcoinTalk** Re: Repost: Request: Make this anonymous? _2010-02-06 21:06:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=7.msg264#msg264) When you send to a bitcoin address, you don't connect to the recipient. You send the transaction to the network the same way you relay transactions. There's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast. With a very small network though, someone might still figure it out by process of elimination. It'll be better when the network is larger. If you send by IP, the recipient sees you because you connect to their IP. You could use TOR to mask that. You could use TOR if you don't want anyone to know you're even using Bitcoin. Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution. **BitcoinTalk** Re: How divisible are bitcoins and other market/economic questions _2010-02-06 23:25:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=44.msg267#msg267) Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge. But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places. If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the ","'s and "."'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00. **Martii Malmi (AKA Sirius) “COPA trial” email #153** **Date: Sun, 07 Feb 2010 06:12:04 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: JSON-RPC status** **To: Martti Malmi <mmalmi@cc.hut.fi>** The JSON-RPC implementation is going well. I'm using boost::asio for sockets. JSON-RPC can be plain socket or HTTP, but it seems most other implementations are HTTP, so I made my own simple HTTP headers. For JSON parsing I'm using JSON Spirit, which makes full use of STL and has been really nice to use. It's header-only so it's no added build work, and small enough to just add it to our source tree. MIT license. This should all be working in a few more days. The forum sure is taking off. I didn't expect to have so much activity so fast. **BitcoinTalk** Re: Make your "we accept Bitcoin" logo _2010-02-08 01:22:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=45.msg278#msg278) No, sorry. I've been meaning to redo it. The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME. Any larger than that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right. If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in "BC" don't land square on a pixel. The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't like the 32x32 version. I'm attaching bitcoin20x20.png, the 20x20 version with full transparency. **BitcoinTalk** Bitcoin client and website translation _2010-02-08 01:27:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=47.msg279#msg279) 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](https://www.bitcoin.org/smf/index.php?topic=44). sirius-m **Martii Malmi (AKA Sirius) “COPA trial” email #155** **Date: Mon, 08 Feb 2010 15:28:52 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Translation** **To: Martti Malmi <mmalmi@cc.hut.fi>** Does Drupal have any special multi-language support, or do you just create copies of pages by hand? BlueSky offered to do translation on the forum. If you create a www.bitcoin.org/zh/ copy of the site and give him an account with just the ability to create new pages and edit text, he'll probably translate the site into Chinese for you and maybe maintain it. **BitcoinTalk** Bitcoin client and website translation _2010-02-08 16:10:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=47.msg283#msg283) 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. ----

Kicking the Hornet's Nest - part 7

# Kicking the Hornet's Nest - third edition - part 7 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 125 - 150 ---- Getting antsy to port to Linux? It's not a decision to be taken lightly because once it's done, it doubles my testing and building workload. Although I am worried about Liberty's Wine crashes. I've tried to be as portable as possible and use standard C stuff instead of Windows calls. The threading is _beginthread which is part of the standard C library. wxWidgets has wxCriticalSection stuff we can use. The sockets code is send/recv stuff which I think is the same as unix because Microsoft ported sockets from BSD. We need direct control over sockets, it wouldn't be a good idea to get behind an abstraction layer. wxWidgets is a good place to look for cross-platform support functions. I want to avoid #ifdefing up the code if we can. Anything that's used more than once probably becomes a function in util.cpp that has the #ifdef in it. BTW, I have a lot of uncommitted changes right now because it includes some crucial protocol transitions that can't be unleashed on the network until I've tested the heck out of it. It shouldn't be too much longer. Can you make the setup uninstall the Startup folder icon? I figure it should install and uninstall an icon in a regular program group, and just uninstall the Startup folder one. I guess it doesn't matter that much whether it installs and uninstalls the Startup folder icon or just uninstalls it. **Martii Malmi (AKA Sirius) “COPA trial” email #46** **Date: Thu, 29 Oct 2009 02:05:30 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Fw: bitcoin.sourceforge.net** **To: mmalmi@cc.hut.fi** I'll convert the CriticalSection code to wxCriticalSection and upload it to SVN (it's a little tricky). I don't know what to do for TryEnterCriticalSection though. I think I'm almost ready to check everything in. You're probably right, it's about time to do a linux build. I've been working on getting my linux machine set up and building the dependencies. > Ok. I replaced the Windows thread and socket library includes with their > POSIX equivalents, and now it only gives a few errors, mostly from the > CriticalSections. If I make it work, I'll put it into svn/branches, it > doesn't need to be an official release yet. **Martii Malmi (AKA Sirius) “COPA trial” email #48** **Date: Thu, 29 Oct 2009 06:38:30 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** The easy solution I took was to look at the wxWidgets source code and see how they did it. They just mapped it to wxMutex on non-MSW, which does have TryEnter, so that mapped in perfectly. I checked in all my backlog of changes to SVN, including the overhaul of CCriticalSection in util.h and OpenSSL's mutex callback in util.cpp to do everything with wxWidgets when not on Windows. If we get it working on Linux, I'll run my test suite against it here off-network first, then we can give an unreleased build to LibertyStandard to test for a while before going public. **Martii Malmi (AKA Sirius) “COPA trial” email #49** **Date: Fri, 30 Oct 2009 01:05:45 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: Martti Malmi <mmalmi@cc.hut.fi>** I fixed some non-portable stuff I came across: QueryPerformanceCounter %I64d in printf format strings Sleep CheckDiskSpace If there's any other unportable stuff you know of I should fix, let me know. I think I'll move debug.log and db.log into the same directory as the data files (%appdata%\Bitcoin), rather than whatever the current directory happens to be. **Martii Malmi (AKA Sirius) “COPA trial” email #51** **Date: Sat, 31 Oct 2009 20:09:58 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** heapchk() is just a MSVCRT debugging thing that's not being used. It can be a no-op on Linux. OpenSSL automatically uses /dev/urandom to seed on Linux, so RandAddSeedPerfmon can also be a no-op. Don't let it connect to the network before we've tested it thoroughly off-net. If you have two computers, unplug the internet and use "bitcoin -connect=<ip>" to connect to each other, one windows and one linux. -connect will allow you to connect to non-routable addresses like 192.168.x.x. We don't want to reflect badly on the reliability of the network if it throws off some malformed crud we hadn't thought to check for yet, or discovers something else anti-social to do on the network. I have time that I can do some testing when you've got something buildable to test. I can include it in the stress test I'm currently running on the changes so far. _mmalmi@cc.hut.fi wrote:_ _> I made an #ifdef to replace QueryPerformanceCounter with Linux's_ _> gettimeofday in util.h. Some Unicode/ANSI errors were resolved without_ _> code changes when I updated to wxWidgets 2.9. The only compile error I'm_ _> getting in Linux at the moment is from heapchk() in util.h._ _>_ _>> I fixed some non-portable stuff I came across:_ _>> QueryPerformanceCounter_ _>> %I64d in printf format strings_ _>> Sleep_ _>> CheckDiskSpace_ _>>_ _>> If there's any other unportable stuff you know of I should fix, let me_ _>> know._ _>>_ _>> I think I'll move debug.log and db.log into the same directory as the_ _>> data files (%appdata%\Bitcoin), rather than whatever the current_ _>> directory happens to be._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #53** **Date: Tue, 03 Nov 2009 15:53:25 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build, proxy** **To: mmalmi@cc.hut.fi** Great, I've been looking forward to working on the Linux build. If you connect to Freenode's hidden service, then they tell you they've also banned TOR from that due to abuse and it kicks you off. There's a several step procedure you can do to run a password utility on unix and e-mail request an account that you could login with, but that's getting pretty complicated. I wonder if we could get away with applying for one account and then everyone use the same account? I suppose the IRC server probably limits accounts to one login, or some admin might not like to see a dozen logins on the same account. Besides the IRC part, how did your test of proxy go? Since you've been connected before, your addr.dat contains known node addresses, but without IRC to know which ones are online, it takes a long time to find them. There are normally 1 to 3 other nodes besides you that can accept incoming connections, and existing nodes that already know you would eventually connect to you. How many connections did you get, and how long did it take? I guess to know whether it successfully connected outbound through TOR you'd need to search debug.log for "connected". To originally connect with TOR without connecting normally once to get seeded, you'd have to know the address of an existing node that can accept incoming connections and seed it like this: bitcoin -proxy=127.0.0.1:9050 -addnode=<ip of a node> If some nodes that accept incoming connects were willing to have their IP coded into the program, it could seed automatically. Or some IP seed addresses posted on a Wiki page with the instructions. Another option is to search the world again for an IRC server that doesn't ban TOR nodes. Or if we could get someone to set one up. IRC servers ban TOR because they have actual text chat on them... if there was one with just bots and junk then it wouldn't care. Probably should post a question on the forum or the mailing list and see if anyone knows one. Another problem is that TOR users can't accept incoming connections, and we have so few that can. If everyone goes to TOR, there won't be any nodes to connect to. We have a shortage of nodes that can accept incoming connections. It generally ranges from 2 to 4 lately. We need to emphasize the importance to people of setting up port forwarding on their router. Every P2P file sharing program has instructions how to do it. We should have a paragraph on the bitcoin.sourceforge.net homepage urging people to set up port forwarding to accept incoming connections, and a link to a site that describes how to do it for each router. _mmalmi@cc.hut.fi wrote:_ _> I uploaded what I've ported so far to the svn/branches. Util, script, db_ _> and the headers compile fully now and net.cpp partially, so there's_ _> still work to do._ _>_ _> _beginthread doesn't have a direct Linux equivalent, so I used Boost_ _> threads instead._ _>_ _> I couldn't get connected using the Tor SOCKS proxy. That might be_ _> because of the Freenode Tor policy which requires connecting to their_ _> hidden service: http://freenode.net/irc_servers.shtml#tor_ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #54** **Date: Wed, 04 Nov 2009 05:38:17 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** It was almost there. I fixed a few things and got it to finish compiling but I don't know the system libraries to link to so there's undefined references galore. I changed the makefile to look for things under /usr/local and in their default "make install" locations. I wrote what I did and switches I used in build-unix.txt. I'm currently using wxWidgets 2.8.9 for now because it's the same version as on Windows and I don't want to wonder if there's version change issues at the same time as platform change. 2.8.10 or 2.9.0 are probably fine though. I went with the single-library compile of wxWidgets since we're linking to almost every library anyway. I added xpm files, which is what they use everywhere else but Windows instead of RC files. They're clever C files that define graphics in static arrays. The bitcoin icon has 5 different versions but I couldn't figure out how that works in xpm so I only put the biggest one. Maybe on GTK it scales it for you. I don't know if these are right or what, but they compile. _mmalmi@cc.hut.fi wrote:_ _> I uploaded what I've ported so far to the svn/branches. Util, script, db_ _> and the headers compile fully now and net.cpp partially, so there's_ _> still work to do._ _>_ _> _beginthread doesn't have a direct Linux equivalent, so I used Boost_ _> threads instead._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #55** **Date: Wed, 04 Nov 2009 20:38:03 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Linux build** **To: mmalmi@cc.hut.fi** Just letting you know I'm still working on the Linux build so we don't duplicate work. I got it linked and ran it and working through runtime issues like getting it switched to load bitmaps from xpm instead of resources. There are debian packages available for some of the dependencies instead of having to compile them ourselves: apt-get install build-essential apt-get install libgtk2.0-dev apt-get install libssl-dev I need to see if Berkeley DB or Boost have packages. We'll shared-link OpenSSL, I'm pretty sure it's always preinstalled on Linux. GTK has to be shared linked. I'm not completely sure if it's preinstalled by default. ----