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