All of satoshi's public messages since 2008

## 2008-10-31 18:10:00 UTC - [Cryptography Mailing List]Bitcoin P2P e-cash paper #

Cryptography Mailing List Bitcoin P2P e-cash paper

2008-10-31 18:10:00 UTC - Original Email

I’ve been working on a new electronic cash system that’s fully peer-to-peer, with no trusted third party.

The paper is available at: http://www.bitcoin.org/bitcoin.pdf

• The main properties:
• Double-spending is prevented with a peer-to-peer network.
• No mint or other trusted parties.
• Participants can be anonymous.
• New coins are made from Hashcash style proof-of-work.
• The proof-of-work for new coin generation also powers the network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System

Abstract.


A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without the burdens of going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as honest nodes control the most CPU power on the network, they can generate the longest chain and outpace any attackers. The network itself requires minimal structure. Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.

Full paper at: http://www.bitcoin.org/bitcoin.pdf

Satoshi Nakamoto

———————————————————————
The Cryptography Mailing List Unsubscribe by sending “unsubscribe cryptography” to majordomo at metzdowd.com

## 2008-11-03 01:37:43 UTC - [Cryptography Mailing List]Bitcoin P2P e-cash paper #

Cryptography Mailing List

Bitcoin P2P e-cash paper

2008-11-03 01:37:43 UTC - Original Email

——>Satoshi Nakamoto wrote:
——>> I’ve been working on a new electronic cash system that’s fully
——>> peer-to-peer, with no trusted third party.
——>>
——>> The paper is available at:
——>> http://www.bitcoin.org/bitcoin.pdf
——>
——>We very, very much need such a system, but the way I understand your
——>proposal, it does not seem to scale to the required size.
——>
——>For transferable proof of work tokens to have value, they must have
——>monetary value. To have monetary value, they must be transferred within
——>a very large network - for example a file trading network akin to
——>bittorrent.
——>
——>To detect and reject a double spending event in a timely manner, one
——>must have most past transactions of the coins in the transaction, which,
——> naively implemented, requires each peer to have most past
——>transactions, or most past transactions that occurred recently. If
——>hundreds of millions of people are doing transactions, that is a lot of
——>bandwidth - each must know all, or a substantial part thereof.
——>

Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.

BitcoinTalk

BitcoinTalk

Re: A newb’s test - anyone want to buy a picture for $1? 2010-01-29 00:22:13 UTC - Original Post The recommended ways to do a payment for an order: 1. The merchant has a static IP, the customer sends to it with a comment. 2. The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it. RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been. We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message. ## 2010-01-29 00:42:49 UTC - Re: 64bit support # 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. ## 2010-02-03 23:29:57 UTC - Re: Bitcoin crash when sending coins # BitcoinTalk Re: Bitcoin crash when sending coins 2010-02-03 23:29:57 UTC - Original Post 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). ## 2010-02-03 23:36:54 UTC - Re: Win32 CPU Cycles vs ‘Live Protection’ Engines ? # BitcoinTalk Re: Win32 CPU Cycles vs ‘Live Protection’ Engines ? 2010-02-03 23:36:54 UTC - Original Post Thanks for that. Which version of Windows? ## 2010-02-04 00:07:07 UTC - Re: Questions about Addresses # 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”. ## 2010-02-04 00:30:50 UTC - Re: TOR and I2P # 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. ## 2010-02-05 19:19:12 UTC - Proof-of-work difficulty increasing # 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% ## 2010-02-05 19:44:46 UTC - Re: Questions about Addresses # Quote from: Sabunir on February 05, 2010, 05:31:30 PM Perhaps there should be a feature against this? For instance, if a transaction isn’t accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them? That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it. It's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost. ## 2010-02-06 21:06:32 UTC - Re: Repost: Request: Make this anonymous? # BitcoinTalk Re: Repost: Request: Make this anonymous? 2010-02-06 21:06:32 UTC - Original Post 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. ## 2010-02-06 23:25:53 UTC - Re: How divisible are bitcoins and other market/economic questions # BitcoinTalk Re: How divisible are bitcoins and other market/economic questions 2010-02-06 23:25:53 UTC - Original Post 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. BitcoinTalk Re: Make your “we accept Bitcoin” logo 2010-02-08 01:22:29 UTC - Original Post 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. ## 2010-02-08 01:27:02 UTC - Bitcoin client and website translation # BitcoinTalk Bitcoin client and website translation 2010-02-08 01:27:02 UTC - Original Post Thank you for the offer to help translate. That is probably the best way you could help. I will need to prepare the code for translation first. wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn’t be too hard. We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support. I’ve done test builds with 2.9.0 and there is one bug left to fix. What operating system are you using? Windows, Linux 32-bit or 64 bit? Split from another thread. sirius-m ## 2010-02-08 16:10:37 UTC - Bitcoin client and website translation # BitcoinTalk Bitcoin client and website translation 2010-02-08 16:10:37 UTC - Original Post 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. ## 2010-02-08 16:37:24 UTC - Re: Simple to implement feature requests # BitcoinTalk Re: Simple to implement feature requests 2010-02-08 16:37:24 UTC - Original Post There are command line options: bitcoin -addnode=1.2.3.4 to tell bitcoin about a node to connect to bitcoin -connect=1.2.3.4 connect only to the specified node(s) You can use more than one of these, for instance bitcoin -connect=(first to try) -connect=(next to try) … You can specify non-routable IPs with -connect like 192.168.x.x, so if you had a server farm and you wanted one server to connect to the world and the rest to connect to the one server, you could do that. In particular, -addnode is needed if you’re always going to connect through TOR, since the IRC server blocks all the TOR exit nodes. To connect through TOR, you could use: bitcoin -proxy=127.0.0.1:9050 -addnode=212.159.72.216 ## 2010-02-12 02:33:02 UTC - Re: DEB Package? # Are you just trying to run the program or do you really need to compile it? There’s a 32-bit linux binary that can be run on 64-bit ubuntu if you “sudo apt-get ia32-libs”. http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download I recently updated the SVN for building on 64-bit Karmic with wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did not build on 64-bit yet. Unfortunately there currently isn’t a -dev deb package of either of the versions of wxWidgets that we can use. On Karmic they only have the UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version or the UTF-8 (wxWidgets 2.9.0) version. We’re moving towards 2.9.0. I know you said you didn’t want VM, but as a last resort, last I checked the Windows version runs fine in Wine. ## 2010-02-12 03:08:08 UTC - Re: What’s with this odd generation? # BitcoinTalk Re: What’s with this odd generation? 2010-02-12 03:08:08 UTC - Original Post There’s a small transaction fee for very large transactions. The node that generates the block that contains the transaction gets the fee. If the same money gets sent again, it won’t incur the fee again. If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together. After that it’s just one line to send the combined unit. ## 2010-02-12 15:57:37 UTC - Re: DEB Package? # Quote from: soultcer on February 12, 2010, 02:31:50 PM If you want, I can provide you with a precompiled binary. Am I missing something? Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org? The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies. Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it. ## 2010-02-12 17:28:32 UTC - Re: Repost: Request: Make this anonymous? # BitcoinTalk Re: Repost: Request: Make this anonymous? 2010-02-12 17:28:32 UTC - Original Post True, sending by IP through Tor trades one problem for another. The Tor exit node can see the text of your message and potentially MITM you. Best to only send to bitcoin addresses then. Payments by bitcoin address are broadcast over the network as part of the normal network traffic. All communications with the network are broadcasts of public information. ## 2010-02-13 01:38:37 UTC - Re: DEB Package? # I couldn’t get wxWidgets 2.8.9 to compile on Karmic 64-bit either. I have been compiling the latest SVN on Karmic 64-bit with wxWidgets 2.9.0, which compiles fine on 64-bit. Read build-unix.txt and use the given ../configure parameters on wxWidgets so you can use the makefile.unix.wx2.9 as supplied. (–enable-debug –disable-shared –enable-monolithic) There’s one cosmetic bug with 2.9.0 I still need to fix where the status number display is bunched up for some reason. – fixed The download link on the homepage is to the sourceforge tar.gz archive which contains the 32-bit binary and the 0.2.0 sources, which were not yet buildable on 64-bit at the time. The SVN was first buildable on 64-bit with wx2.9.0 on 28 January 2010. Hopefully they’ll have a wxWidgets 2.9.0 debian package someday. ## 2010-02-14 06:28:03 UTC - Re: What’s with this odd generation? # BitcoinTalk Re: What’s with this odd generation? 2010-02-14 06:28:03 UTC - Original Post Quote from: theymos on February 12, 2010, 08:31:52 AM Does the sending client send more BitCoins to account for the fee (so the recipient gets what he’s expecting)? Yes. Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?! Almost all transactions are free. A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you’ve received to make up the amount. A transaction over the size limit can still be sent if a small fee is added. The average transaction, and anything up to 500 times bigger than average, is free. It’s only when you’re sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount. It’s not money sucked out of the system, it just goes to other nodes. If you’re sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself. ## 2010-02-14 15:52:23 UTC - Re: What’s with this odd generation? # BitcoinTalk Re: What’s with this odd generation? 2010-02-14 15:52:23 UTC - Original Post Right. Otherwise we couldn’t have a finite limit of 21 million coins, because there would always need to be some minimum reward for generating. In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes. I’m sure that in 20 years there will either be very large transaction volume or no volume. ## 2010-02-15 06:28:38 UTC - Re: Proof-of-work difficulty increasing # 14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 2009 1.00 30/12/2009 1.18 +18% 11/01/2010 1.31 +11% 25/01/2010 1.34 +2% 04/02/2010 1.82 +36% 14/02/2010 2.53 +39% Another big jump in difficulty yesterday from 1.82 times to 2.53 times, a 39% increase since 10 days ago. It was 10 days apart not 14 because more nodes joined and generated the 2016 blocks in less time. ## 2010-02-16 01:34:56 UTC - Re: Setting up multiple bitcoin machines behind NAT # BitcoinTalk Re: Setting up multiple bitcoin machines behind NAT 2010-02-16 01:34:56 UTC - Original Post Right now there isn’t a port number setting to do that. It’s a feature yet to be implemented. You can only set up your NAT to port-forward to one of the computers. (I said something earlier about NAT port translation, but that wouldn’t work, other nodes wouldn’t know to connect to that port) If you want, as a small optimization, you could run the rest of your computers as: bitcoin -connect= so they get all their network communication from the first computer and don’t all connect over the net individually for the same information. This saves bandwidth, although it doesn’t use much bandwidth to begin with, so it wouldn’t really matter unless you had tons of computers. For redundancy in case the first computer goes down, you could have two that connect out and the rest connect to both of them. The first two are run normally, the rest are run like: bitcoin -connect= -connect= ## 2010-02-16 17:36:40 UTC - Re: Proof-of-work difficulty increasing # Quote from: Suggester on February 16, 2010, 02:15:49 AM Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create \u0e3f50.00! With older PCs it will take forever. People like to feel that they “own” something as soon as possible, is there a way to make the generation more divisible? So say, instead of making \u0e3f50 every 20 hours, make \u0e3f5 every 2 hours? I thought about that but there wasn’t a practical way to do smaller increments. The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network. The algorithm aims for an average of 6 blocks per hour. If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long. It wouldn’t work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger. ## 2010-02-17 17:58:03 UTC - Re: Proof-of-work difficulty increasing # Quote from: Sabunir on February 16, 2010, 08:51:51 AM . Perhaps it has to do with my connection’s very high latency (2000ms or more on average) 2 seconds of latency in both directions should reduce your generation success by less than 1%. Quote from: Sabunir on February 16, 2010, 08:51:51 AM and/or my high packet loss (sometimes up to 10% loss)? Probably OK, but I’m not sure. The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you’re connected to until received. If you miss a block, it’ll also keep requesting it every time another blocks comes in and it sees there’s a gap. Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck. ## 2010-02-17 19:19:43 UTC - Re: Bitcoin client and website translation # BitcoinTalk Re: Bitcoin client and website translation 2010-02-17 19:19:43 UTC - Original Post I updated the SVN with changes to support translation. Translatable strings are all enclosed in _(””), and we’re using UTF-8 on all platforms. When the program runs, it looks in the directory of the EXE for the file: locale\\LC_MESSAGESitcoin.mo is the two letter code of the language your OS is set to, like “de” or “nl”. On Linux, it also looks for: /usr/share/locale//LC_MESSAGES/bitcoin.mo /usr/local/share/locale//LC_MESSAGES/bitcoin.mo (are there other standard places it should look on linux?) Here’s a quick walkthrough using poedit to make a .po and .mo file: • Download the bitcoin sourcecode from SVN • In the trunk directory, mkdir locale\\LC_MESSAGES • In poedit, File->New catalog->Paths tab • Click the “New item” dotted rectangle button • Put “../../..” and MAKE SURE TO PRESS ENTER to add the path • Click OK • Save the file as “bitcoin.po” in the LC_MESSAGES directory you made • It should then scan the sourcecode and find about 170 strings • If it didn’t find anything, check Catalog->Settings->Path tab, make sure the “../../..” was added When you're done translating, commit both bitcoin.po (the editable catalog file) and bitcoin.mo (compiled data used by the program). ## 2010-02-21 03:43:48 UTC - Re: Number of connections # Nodes stop trying to initiate connections once they have 15. If you can accept incoming connections, then you can get well above that from nodes connecting to you, otherwise you max out at 15. I don’t know if there’s any reason to have 15 connections. Maybe it should be 10. Since nodes that can only connect out are probably at or near 15 most of the time now, you should level off to an equilibrium. 45 suggests a ratio of 3 out-only nodes to every 1 in-accepting node. The number of connections won’t be a good gauge of the size of the network any more. Someone should periodically IRC to the bitcoin channel on chat.freenode.net and count the number of users. That gives you the total count of network nodes (except TOR nodes). Block generation is again running ahead of pace. We’re in for another big step up in difficulty at the next adjustment in about 5 days. ## 2010-02-21 04:19:53 UTC - Post your static IP # It would be nice to have a list of static IPs for new users to send test donations to so they can see how the software works. If you can accept incoming connections and you have a static IP address, post it here! Anything sent to these IPs should be considered a donation. If you do request a round-trip, be sure to include your return bitcoin address or IP in the comment, but please assume it’ll be one-way. They won’t necessarily be watching for incoming transactions to send back. ## 2010-02-21 05:44:24 UTC - Re: Current Bitcoin economic model is unsustainable # BitcoinTalk Re: Current Bitcoin economic model is unsustainable 2010-02-21 05:44:24 UTC - Original Post Excellent analysis, xc. A rational market price for something that is expected to increase in value will already reflect the present value of the expected future increases. In your head, you do a probability estimate balancing the odds that it keeps increasing. In the absence of a market to establish the price, NewLibertyStandard’s estimate based on production cost is a good guess and a helpful service (thanks). The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price. In later years, when new coin generation is a small percentage of the existing supply, market price will dictate the cost of production more than the other way around. At the moment, generation effort is rapidly increasing, suggesting people are estimating the present value to be higher than the current cost of production. ## 2010-02-21 21:48:01 UTC - UI improvements # Uploaded some UI changes to SVN as version 0.2.5. Instead of View->Show Generated, we now have tabs: • All Transactions • Sent/Received • Sent • Received Makes it a lot easier to flip to received and check for payments. Moved the "Your Addresses" book inside the main address book. It was confusing having two address books. I found the "To:" in "From: unknown, To: (one of your bitcoin addresses)" still confusing, so I changed it to "From: unknown, Received with:". The bitcoin address is abbreviated so you can see the label that you set in the Receiving tab of the address book. Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0. I haven't forgotten about you people who want non-UI, but I had to do some fun stuff before more build bashing. ## 2010-02-23 00:49:56 UTC - Re: generation slowed down dramatically # BitcoinTalk Re: generation slowed down dramatically 2010-02-23 00:49:56 UTC - Original Post Just a random streak of bad luck. It looks steady to me. Competition doesn’t have an effect until the next automatic retarget adjustment, and we haven’t reached the next one yet. The adjustments are every 2016 blocks. To calculate our progress towards the next one, divide the block total by 2016. The fractional part is how far we are to the next one. My back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85% of the way. About 1.5 days to go until the next one. That’ll only be about 10 days since the last one, the target is 14 days, so 14/10 = 1.4 = around 40% difficulty increase. ## 2010-02-23 01:16:28 UTC - Re: UI improvements # There are now “Sending” and “Receiving” tabs in the Address Book. Your addresses are referred to as “receiving addresses”. madhatter was working on building it on Mac. He had errors probably caused by UTF-16 wxWidgets 2.8. Should have better luck now with 2.9.0. wxWidgets 2.9.0 is UTF-8 and wouldn’t have that problem. I think he had it working on FreeBSD, but he wanted a non-UI version. I have the command line and JSON-RPC daemon version working now. Will SVN it in a day or two. I disabled gdm on my Ubuntu system so it boots into command line. I hope I will be able to get it enabled again with rcconf. ## 2010-02-23 16:26:09 UTC - Re: Bitcoin Address Collisions # There’s a separate public/private keypair for every bitcoin address. You don’t have a single private key that unlocks everything. Bitcoin addresses are a 160-bit hash of the public key, everything else in the system is 256-bit. If there was a collision, the collider could spend any money sent to that address. Just money sent to that address, not the whole wallet. If you were to intentionally try to make a collision, it would currently take 2^126 times longer to generate a colliding bitcoin address than to generate a block. You could have got a lot more money by generating blocks. The random seed is very thorough. On Windows, it uses all the performance monitor data that measures every bit of disk performance, network card metrics, cpu time, paging etc. since your computer started. Linux has a built-in entropy collector. Adding to that, every time you move your mouse inside the Bitcoin window you’re generating entropy, and entropy is captured from the timing of disk ops. ## 2010-02-23 16:53:27 UTC - Re: UI improvements # Quote from: Xunie on February 23, 2010, 12:28:27 PM /etc/init.d/gdm start and it will start gdm! Ah yes, there we go, back to normal again. The ctrl+alt+F[1-8] thing never worked on this computer. The screen just goes haywire. ## 2010-02-23 22:15:41 UTC - Command Line and JSON-RPC # Version 0.2.6 on SVN can now run as a daemon and be controlled by command line or JSON-RPC. On Linux it needs libgtk2.0-0 installed, but does not need a GUI running. Hopefully gtk can be installed without having a windowing system installed. The command to start as a daemon is: bitcoin -daemon [switches…] Or, to run the UI normally and also be able to control it from command line or JSON-RPC, use the “-server” switch. bitcoin -server [switches…] With either switch, it runs an HTTP JSON-RPC server that accepts local socket connections on 127.0.0.1:8332. The port is bound to loopback and can only be accessed from the local machine, but from any account, not just the user it’s running under. To control it from the command line, the interface is a command name without any switches, followed by parameters if any. bitcoin [params…] For example: bitcoin getinfo bitcoin getdifficulty bitcoin setgenerate true bitcoin stop It’s a simple JSON-RPC client and prints the JSON result. Look at rpc.cpp for the list of commands. Web apps or anything automated will normally use JSON-RPC directly, not command line. There are JSON-RPC libraries for all the major languages. In script languages like PHP and Python the syntax is as natural as calling a local function. ## 2010-02-23 22:24:00 UTC - Re: Bitcoin Address Collisions # Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window? No, each generated transaction uses a new, single-use address. Nothing uses the address in the main window, it’s just there for convenience for you to copy. 0.2.5 has a “New…” button next to it to make it easy to change each time you use it. ## 2010-02-24 05:57:43 UTC - Re: URI-scheme for bitcoin # That would be nice at point-of-sale. The cash register displays a QR-code encoding a bitcoin address and amount on a screen and you photo it with your mobile. ## 2010-02-24 06:17:23 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-02-24 06:17:23 UTC - Original Post Quote from: satoshi on February 23, 2010, 10:15:41 PM On Linux it needs libgtk2.0-0 installed Quote from: theymos on February 24, 2010, 03:07:37 AM Will this requirement be removed sometime? I’d rather not have to deal with GTK. How much “dealing with” does GTK actually require? Is it just a matter of “sudo apt-get install libgtk2.0-0” and having some extra libraries sitting around? GTK doesn’t have to do anything, just be there for bitcoin to link to when it loads up, have the gtk-init-check call fail because no GUI present, then it’s done. It saves us butchering everything with ifdefs and a separate compile and binary to use wxBase just to try to avoid linking GTK. New icons, what do you think? Better than the old one? Full size 530x529 image for scaling down to custom sizes: The perspective shadow was too thick on the larger sizes. I updated 32, 48 and the full size. I release these images into the public domain (copyright-free). I request that derivative works be made public domain. BitcoinTalk Re: Make your “we accept Bitcoin” logo 2010-02-24 21:53:52 UTC - Original Post If you GPL stuff, I have to avoid using it. Nothing against GPL per-se, but Bitcoin is an MIT license project. Anything GPL please clearly mark it as such. ## 2010-02-24 22:08:55 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-02-24 22:08:55 UTC - Original Post When and how fast did memory usage increase? Right away, slowly over a long time, or starting at some later event? I have -daemon running on ubuntu 9.10 64-bit and memory usage is steady. It has to be something about the difference on the server besides 64-bit. Maybe some malfunction from the lack of GUI. A memory leak debug tool could give a clue. ## 2010-02-24 22:42:24 UTC - Re: Proof-of-work difficulty increasing # The automatic adjustment happened earlier today. 24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000 24/02/2010 3.78 +49% I updated the first post. Quote from: Sabunir on February 25, 2010, 01:47:56 AM I like them. Do they come in higher resolutions? Yes, the original is 546x531 pixels. It looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first. I’ll post larger sizes and full size a little later. ## 2010-02-25 22:54:17 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-02-25 22:54:17 UTC - Original Post OK, I made a build target bitcoind that only links wxBase and does not link GTK. Version 0.2.7 on SVN. I split out the init and shutdown stuff from ui.cpp into init.cpp, so now ui.cpp is pure UI. ui.h provides inline stubs if wxUSE_GUI=0. We only have four functions that interface from the node to the UI. In the bitcoind build, we don’t link ui.o or uibase.o. Quote from: sirius-m on February 25, 2010, 04:32:17 PM It started increasing right away. I’ll see if valgrind can help me. Sure feels like it could be something in wxWidgets retrying endlessly because some UI thing failed or something wasn’t inited correctly. Our hack to ignore the initialize failure and run anyway means we’re in uncharted territory. We’re relying on the fact that we hardly use wx in this mode. We do still use a few things like wxGetTranslation and wxMutex. Another way to debug would be to run in gdb, wait until everything is quiet and all threads should be idle, and break it and see which thread is busily doing something and what it’s doing. I suspect bitcoind will probably work fine, but I hope you can still debug the problem. ## 2010-02-25 23:06:29 UTC - Re: Proof-of-work difficulty increasing # The formula is based on the time it takes to generate 2016 blocks. The difficulty is multiplied by 14/(actual days taken). For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49. Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase. I don’t know what you’re talking about accepting easier difficulties. ## 2010-02-26 16:29:21 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-02-26 16:29:21 UTC - Original Post wx/clipbrd.h isn’t used, move it inside the #if wxUSE_GUI. Updated headers.h on SVN. Sorry, I linked to wxbase but I had full wxWidgets on my computer. The db.h:140 class Db no member named “exisits” is stranger. pdb->get, pdb->put, pdb->del compiled before that. Do you have version 4.7.25 of Berkeley DB? Db::exists() http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/frame_main.html http://www.oracle.com/technology/documentation/berkeley-db/db/api_reference/CXX/dbexists.html I suppose they might have added exists recently, using get before that. Good suggestion. I made the B slightly lighter and the background slightly darker. Very slightly. The foreground is now exactly the same colour as the BC in the old one. It’s kind of OK if you can’t easily read the B in the 16x16. At that size, you just need to see that it’s a coin. It doesn’t matter so much what’s embossed on it, just that there be some detail there because it wouldn’t look like a coin if it was a blank smooth circle. It’s slightly wider than tall because the dark perspective under it goes more to the right than down. I finished and posted the 32x31 and 48x47 versions in the first message. I like the 48 a lot. How does everyone feel about the B symbol with the two lines through the outside? Can we live with that as our logo? ## 2010-02-26 23:48:44 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-02-26 23:48:44 UTC - Original Post Are you using wxWidgets 2.9.0? I don’t recommend using anything other than 2.9.0. It looks like they’ve got a reference in the wx headers (arrstr.h) to something outside of wxBase. Removing -D__WXDEBUG__ from bitcoin’s makefile would probably solve it. If that doesn’t work and you just want to get it working, you could edit wxWidgets include/wx/arrstr.h, line 167 and comment out the wxASSERT_MSG. Quote from: Cdecker on February 27, 2010, 03:24:07 AM How about an SVG version? That way we could automatically generate smaller and larger versions as needed. I don’t know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down. I’ll give the original when I’m finished. I had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they’re ugly blurry and inconsistent. Such is the challenge of making icons. The original will be good for scaling to custom sizes between 48 and 500 but not smaller. ## 2010-02-27 21:22:53 UTC - Re: wxWidgets 2.9.0 # Quote from: Cdecker on February 27, 2010, 05:09:59 PM Looking through the source of 2.8.10 it appears that unicode is possible with that version too. In the Windows world, “unicode” means UTF-16 (wchar). 2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16 version is the “unicode” version provided in the Debian package. I believe 2.8 and its UTF-16 build labelled simply “unicode” has been the source of build problems described in the forum. We were previously using 2.8 ANSI in anticipation of getting to UTF-8 without going through UTF-16 hell. We cannot compile with UTF-16. 2.9 has only one version, UTF-8. On Windows, we set the codepage to UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces with us in UTF-8. On Linux I assume the codepage is already UTF-8. By standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we need 2.9 for UTF-8 internationalization. Make sure you read build-unix.txt and configure wxWidgets using the configure parameters given. Curious, why is it incredibly hard to provide wxWidgets 2.9.0? If you mean for users, that’s why we static link it. It’s unfortunate that we require so many big dependencies, but we need them all. At least on Debian/Ubuntu, all but wxWidgets are available as packages. Eventually they’ll provide a 2.9 package. We have the standard icon sizes, and the full size scales nicely to anything else. I added the full size to the first post. ## 2010-03-03 04:28:56 UTC - Re: Money Transfer Regulations # When there’s enough scale, maybe there can be an exchange site that doesn’t do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works. To make it safer, the exchange site could act as an escrow for the bitcoin side of the payment. The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller. The exchange service doesn’t handle any real world money. This would be a step better than e-bay. E-bay manages to work fine even though shipped goods can’t be recovered if payment falls through. ## 2010-03-05 01:46:25 UTC - Re: Command Line and JSON-RPC # BitcoinTalk Re: Command Line and JSON-RPC 2010-03-05 01:46:25 UTC - Original Post Quote from: sirius-m on February 24, 2010, 06:17:35 PM This is strange… When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there’s something wrong with the build or something. sirius-m debugged this, it was 64-bit related. The fix is now available on SVN, file util.cpp. ## 2010-03-15 18:44:12 UTC - Re: bitcoin auto-renice-ing # It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal. #define THREAD_PRIORITY_LOWEST PRIO_MIN #define THREAD_PRIORITY_BELOW_NORMAL 2 #define THREAD_PRIORITY_NORMAL 0 The priorities converted from Windows priorities were probably from a table like this: “The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues. nice value Win32 Priority -20 to -16 THREAD_PRIORITY_HIGHEST -15 to -6 THREAD_PRIORITY_ABOVE_NORMAL -5 to +4 THREAD_PRIORITY_NORMAL +5 to +14 THREAD_PRIORITY_BELOW_NORMAL +15 to +19 THREAD_PRIORITY_LOWEST” If you have better values, suggestions welcome. Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that’s not true, maybe it accounts for unexpectedly setting the priority of the whole app. // threads are processes on linux, so PRIO_PROCESS affects just the one thread setpriority(PRIO_PROCESS, getpid(), nPriority); ## 2010-03-15 19:16:56 UTC - Idea for file hosting and proxy services # BitcoinTalk Idea for file hosting and proxy services 2010-03-15 19:16:56 UTC - Original Post When you want to upload an image to embed in a forum post, there are services like imageshack, but because they’re free, they limit the number of views. It’s a minuscule amount of bandwidth cost, but they can’t just give it away for free, there has to be something in it for them. It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing. It’s worse if you want to upload a file for others to download. There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads. It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins. Anyone with some extra bandwidth quota could throw it on their webserver and run it. Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles. Ideally, it should be MIT license or public domain. Services like this would be great for anonymous users, who have trouble paying for things. ## 2010-03-16 19:48:47 UTC - Re: On IRC bootstrapping # Thanks soultcer for talking with the Freenode staffer. Good to know it’s OK at the current size, and now they know who we are. They’re supportive of projects like TOR so I hope they would probably be friendly to us. We don’t want to overstay our welcome. If we get too big, then by the same token, we’re big enough that we don’t need IRC anymore and we’ll get off. We only needed IRC because nobody had a static IP. In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days. IRC was only intended as a temporary solution. Bitcoin’s built-in addr system is the main solution. Bitcoin can get the list of IPs from any bitcoin node. In that sense, every node serves as a directory server. When there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list. How do you think we should compile the seed list? Would it be OK to create it from the currently connected IPs that have been static for a while? BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC? IRC is a good directory server (I’ve heard it has other uses too), and there are mature IRC server implementations available that anyone can run. Bitcoin’s IRC client implementation is already thoroughly tested. ## 2010-03-16 20:17:34 UTC - Re: Idea for file hosting service # BitcoinTalk Re: Idea for file hosting service 2010-03-16 20:17:34 UTC - Original Post That’s a great idea. There’s a thriving business in those services, but I’ve always thought the standard payment methods are at odds with privacy minded customers. Would you consider making your software freely available so anyone could easily set one up? I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server. I wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system? ## 2010-03-23 15:22:41 UTC - Re: who is bitcoin.com # It’s unrelated. There wasn’t anything there when I started. The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it’s standard for open source projects to be .org. ## 2010-03-23 17:35:34 UTC - Re: Exchange Methods # LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that. The possibility to cash out through them would help support the value of bitcoins. Bitcoin has unique properties that would be complementary. LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts. Bitcoin, on the other hand, is easy to get in small amounts anonymously. It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods. Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it. ## 2010-03-24 18:01:57 UTC - Re: Idea for file hosting and proxy services # BitcoinTalk Re: Idea for file hosting and proxy services 2010-03-24 18:01:57 UTC - Original Post Title changed. It helps that we have someone with actual experience running a proxy service. Do you think Psiphon is the best one currently? (sometimes the one you run was the best when you started but you found better ones later) ## 2010-03-24 18:02:55 UTC - Re: Idea for file hosting and proxy services # BitcoinTalk Re: Idea for file hosting and proxy services 2010-03-24 18:02:55 UTC - Original Post Mihalism Multi Host is a popular open source PHP file hosting server. It’s geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting. They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed. It doesn’t have a bunch of client side scripting or anti-embedding junk to rip out. It generates standard links that work normally. There’s a turnover churn in these free hosting sites. Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth. Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs. It’s a perfect example of a service where the needed price point is in the no-man’s-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment. It’s in the gap between 0 and 19.95. The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders. It can’t really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site. An example of a site running the software: http://www.imagez.ws/ Forum: http://www.mihalism.net/ Download: http://code.google.com/p/mihalismmh/ What do you think? If I made a Bitcoin payment integration for this, would anyone be interested in running it? It might be the first fully automated service available to buy with Bitcoins. The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops. It would give a normal link directly to the file. ## 2010-05-16 21:01:44 UTC - Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add # BitcoinTalk Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add 2010-05-16 21:01:44 UTC - Original Post When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It’s like generating a new PGP private key, but less CPU intensive because it’s ECC. The address space is effectively unlimited. It doesn’t hurt anyone, so generate all you want. ## 2010-05-16 21:37:36 UTC - Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? # BitcoinTalk Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses? 2010-05-16 21:37:36 UTC - Original Post Quote from: Xunie on May 14, 2010, 09:52:53 PM I suggest we disable IP transactions while the user uses a Proxy! Just to be on the safe side. That’s a good idea. At the very least a warning dialog explaining that it’ll connect to the IP and send the information cleartext, giving the chance to cancel. ## 2010-05-16 22:37:21 UTC - Re: URI-scheme for bitcoin # Original Post Quote from: Karmicads on May 01, 2010, 06:06:53 AM There you go, we could easily do it the same way, like: http://127.0.0.1:8330/?to=;amount= Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332. It would give an HTTP answer. Quote from: DataWraith on May 02, 2010, 11:13:09 AM A bitcoin-link should be more like mailto: than magnet: IMHO. I think we can do that. Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server. The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page. Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in. It would work just like a mailto: link that pops up a new email with the address filled in. 127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog. You'd still have to press Send. We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter. ## 2010-05-16 22:53:59 UTC - Re: Exception: 9key_error error # Does it happen every time you run it, or just happened once at some random time? I’ve never seen that fail before. It’s a call to OpenSSL that I assumed would never fail, but I put an error check there just in case. I can’t imagine how it would fail. Out of memory maybe. The code is: key.h: EC_KEY* pkey; pkey = EC_KEY_new_by_curve_name(NID_secp256k1); if (pkey == NULL) throw key_error(“CKey::CKey() : EC_KEY_new_by_curve_name failed”); NID_secp256k1 is a constant. ## 2010-05-16 23:34:40 UTC - Re: removing bitcoin addresses # SheriffWoody: Bitcoin addresses you generate are kept forever. A bitcoin address must be kept to show ownership of anything sent to it. If you were able to delete a bitcoin address and someone sent to it, the money would be lost. They’re only about 500 bytes. sirius-m: Thousands of own addresses should not be any problem at all. If you’ve generated 50000 BTC, then you already have 1000 own addresses, one for each 50 generated. Those are hidden, they’re not shown in the UI. It would be a good idea to add a little code that keeps giving the same address to the same IP. Here’s what I did in C++ to keep giving the same key (aka bitcoin address) until they use it: // Keep giving the same key to the same ip until they use it if (!mapReuseKey.count(pfrom->addr.ip)) mapReuseKey[pfrom->addr.ip] = GenerateNewKey(); …sends the key mapReuseKey[pfrom->addr.ip] …later… // Received something with this key mapReuseKey.erase(pfrom->addr.ip); If it’s not convenient to know when you’ve received, just clear the cached keys every 20 minutes. I want to add a parameter to getnewaddress for number of days to expire if nothing is received with the address. ## 2010-05-16 23:56:03 UTC - Re: Setting up multiple bitcoin machines behind NAT # BitcoinTalk Re: Setting up multiple bitcoin machines behind NAT 2010-05-16 23:56:03 UTC - Original Post At the moment, it always assumes the incoming port is 8333, so it would tell other bitcoin nodes to connect to router:8333 even if you’re redirecting from another port number. I’m not in a big hurry to fix this because I can’t think of any benefit to having more than one incoming connection port. If you’re providing one incoming port, then you’ve done your bit to help the network. Having two incoming ports to the same person doesn’t help redundancy. If you have many computers, then using the -connect switch on most of them to connect locally makes more sense. ## 2010-05-18 02:58:11 UTC - Re: Is there a way to automate bitcoin payments for a website? # BitcoinTalk Re: Is there a way to automate bitcoin payments for a website? 2010-05-18 02:58:11 UTC - Original Post A little late, but in case anyone else has the same issue. The compile dump had 2 warnings (that were 20 lines long) and 2 link errors. The errors were: Quote obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function wxArrayString::Item(unsigned long) const’: /usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to wxTheAssertHandler’ obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function wxArrayString::Item(unsigned long) const’: /usr/src/bitcoin/trunk/uint256.h:526: undefined reference to wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)’ Those are probably due to switching to the release build of wxWidgets instead of debug. They're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff. There's nothing to fear about the debug build. It's fully suitable for releases. bitcoind runs as a daemon and can either be controlled by command line or JSON-RPC. Thanks madhatter and generica for detailing the instructions for building on freebsd. ## 2010-05-18 20:06:46 UTC - Re: Ummmm… where did my bitcoins go? # BitcoinTalk Re: Ummmm… where did my bitcoins go? 2010-05-18 20:06:46 UTC - Original Post It’s not the download so much as verifying all the signatures in all the blocks as it downloads that takes a long time. How long is the initial block download typically taking? Does it slow down half way through or is about the same speed the whole way? I’ve thought about ways to do a more cursory check of most of the chain up to the last few thousand blocks. It is possible, but it’s a lot of work, and there are a lot of other higher priority things to work on. Simplified Payment Verification is for lightweight client-only users who only do transactions and don’t generate and don’t participate in the node network. They wouldn’t need to download blocks, just the hash chain, which is currently about 2MB and very quick to verify (less than a second to verify the whole chain). If the network becomes very large, like over 100,000 nodes, this is what we’ll use to allow common users to do transactions without being full blown nodes. At that stage, most users should start running client-only software and only the specialist server farms keep running full network nodes, kind of like how the usenet network has consolidated. SPV is not implemented yet, and won’t be implemented until far in the future, but all the current implementation is designed around supporting it. In the meantime, sites like vekja.net and www.mybitcoin.com have been experimenting with account-based sites. You create an account on a website and hold your bitcoins on account there and transfer in and out. Creating an account on a website is a lot easier than installing and learning to use software, and a more familiar way of doing it for most people. The only disadvantage is that you have to trust the site, but that’s fine for pocket change amounts for micropayments and misc expenses. It’s an easy way to get started and if you get larger amounts then you can upgrade to the actual bitcoin software. ## 2010-05-20 21:43:42 UTC - Re: We accept Bitcoins # Quote from: DataWraith on May 19, 2010, 07:52:42 PM Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient. Almost but not quite. Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn’t use it because it’s an order of magnitude bigger and would have been impractical. ## 2010-05-26 18:27:25 UTC - JSON-RPC programming tips using labels # BitcoinTalk JSON-RPC programming tips using labels 2010-05-26 18:27:25 UTC - Original Post I added label related functions to help with managing multiple addresses per user. New or renamed functions are: getreceivedbyaddress – amount received on a single address getreceivedbylabel – amount received by all addresses with this label listreceivedbyaddress – list addresses and amounts they’ve received listreceivedbylabel – list labels and amounts they’ve received setlabel – misc label functions for completeness getlabel getaddressesbylabel For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress. The old names are still there so as not to break existing code, but they’re deprecated. The idea is that if you give the username whenever you call getnewaddress, you can get the user’s total received across all their addresses using the “bylabel” functions. You can freely change their address without worrying about tracking all their old addresses. A good way to automate changing the user’s receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one: // Get a new address whenever the current one has received anything if (strAddr == "” || getreceivedbyaddress(strAddr) > 0) strAddr = getnewaddress(strUsername); / Label the address with username Display(strAddr); / Display their current receiving address / Get total received by all the user’s addresses getreceivedbylabel(strUsername, 0) / unconfirmed getreceivedbylabel(strUsername, 1) // available balance If you’re just getting one particular user’s balance, such as in response to a page request by that user, use getreceivedbylabel, but if you’re scanning over all users, it’s better to use listreceivedbylabel to get the complete list and scan against the result. Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear). You should only really need to scan all users if you’re polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it. It’s not necessary to poll very frequently. If you require 1 confirmation, that’ll take an average of 10 minutes anyway, so there’s no point in polling more often than every few minutes. If you’re selling digital goods and services, where you don’t lose much if someone gets a free access, and it can’t be resold for profit, I think you’re fine to accept 0 confirmations. It’s mostly only if you were selling gold or currency that you’d need multiple confirmations. ## 2010-05-26 18:51:04 UTC - Re: Tracing a coin’s lineage # BitcoinTalk Re: Tracing a coin’s lineage 2010-05-26 18:51:04 UTC - Original Post Quote from: Xunie on May 26, 2010, 12:50:04 AM Can’t we force a user to use a new address for receiving payments? Every time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that’d be useless, right?) The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address. This is on my list. I will soon make the “Your Bitcoin Address:” window automatically change whenever you receive anything to the address displayed. I’m also recommending this approach for the implementation of web apps. I just posted some sample code showing a suggested way of implementing this. Versions on SVN since 0.2.4 already have a “New…” button next to the address bar to encourage changing it manually too. @theymos: If nothing else, we can fall back on that solution in the future. ## 2010-05-26 20:09:34 UTC - Re: CLI bitcoin generation # Quote from: molybdenum on May 22, 2010, 06:44:20 PM An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)? Yeah, that actually is what it is. getallreceived 0 should do what you want. (now it’s renamed to listreceivedbyaddress 0) The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations. Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through. listreceivedbyaddress [minconf=1] [includeempty=false] [minconf] is the minimum number of confirmations before payments are included. [includeempty] whether to include addresses that haven’t received any payments. Returns an array of objects containing: “address” : receiving address “label” : the label of the receiving address “amount” : total amount received by the address “confirmations” : number of confirmations of the most recent transaction included or listreceivedbylabel if you’re labelling addresses with their username. So far I’ve concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet. ## 2010-05-26 20:34:34 UTC - Re: Share database blocks ? # BitcoinTalk Re: Share database blocks ? 2010-05-26 20:34:34 UTC - Original Post It does in fact download 500 blocks at a time, then the counter counts one at a time as it verifies the blocks. The advantage of letting bitcoin download and verify the blocks is that you do not have to trust the person you’re downloading them from. If you downloaded the blk*.dat files from some site, you would have to trust that site, since you would be accepting the data without verifying it yourself. If you’re copying blk*.dat from another computer of yours, that should be fine. How long is the initial block download taking for you? ## 2010-05-26 21:16:34 UTC - Re: Website translations # Does anyone want to translate the Bitcoin client itself? It would be great to have at least one other language in the 0.3 release. All you have to do is get poedit and translate the po file I’m attaching to this post. It’s less than 750 words. Updated bitcoin.po attachment for 0.3.1 ## 2010-05-26 21:34:32 UTC - Re: Odd amount of generated coins # BitcoinTalk Re: Odd amount of generated coins 2010-05-26 21:34:32 UTC - Original Post In the SVN version, if a transaction requires a transaction fee, it says “This transaction is over the size limit. You can still send it for a fee of #, which goes to the nodes that process your transaction and helps to support the network. Do you want to pay the fee?" If you don’t have enough money with the fee added, it says “Total exceeds your balance when the # transaction fee is included " ## 2010-05-27 14:18:22 UTC - Re: Website translations # Hurray! We have our first language. I uploaded it to SVN to go in with the 0.3 release. ## 2010-06-02 18:18:15 UTC - Re: Hostnames instead of IP Addresses # BitcoinTalk Re: Hostnames instead of IP Addresses 2010-06-02 18:18:15 UTC - Original Post The current sending by IP is not very useful: it connects to the IP, so you’d like to use TOR for anonymity, but then it can totally be eavesdropped and man-in-the-middled. The future plan for sending to an IP is to make it a bitcoin address plus IP, like: 1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h1.2.3.4 or 1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4hdomain.com I need suggestions for the separator character. “:” is a candidate, but IPv6 has : in it and that might get confusing. Something that’s allowed in url parameters would be nice. I want to use SSL for the connection, using the bitcoin address’ public key as the cert. You would be certain you’re connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection. Since it’s authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup. ## 2010-06-02 18:45:38 UTC - Re: Proof-of-work difficulty increasing # That’s a good idea. I’m not sure where exactly to fit that in, but it could certainly calculate the expected average time between blocks generated, and then people would know what to expect. Every node and each processor has a different public key in its block, so they’re guaranteed to be scanning different territory. Whenever the 32-bit nonce starts over at 1, bnExtraNonce gets incremented, which is an arbitrary precision integer. ## 2010-06-02 22:18:09 UTC - Re: Website translations # I uploaded the 93% complete Dutch translation to SVN. Thanks! ## 2010-06-14 18:13:21 UTC - Re: On IRC bootstrapping # Bitcoin has its own distributed address directory using the “addr” message. It’s about time we coded in a list of the current long running static nodes to seed from. I can add code so new nodes do not preferentially stay connected to the seed nodes, just connect and get the list, so it won’t be a burden on them. What do you think, should I go ahead with adding the seeds? It’ll still try IRC first. The IRC has the advantage that it lists nodes that are currently online, since they have to stay connected to stay on the list, but the disadvantage that it’s a single point of failure. The “addr” system has no single point of failure, but can only tell you what nodes have recently been seen, so it takes a little longer to get connected since some of the nodes you try have gone offline. The combination of the two gets us the best of both worlds and more total robustness. Is there anyone who wants to volunteer to run an IRC server in case freenode gets tired of us? ## 2010-06-14 19:53:44 UTC - Re: Hostnames instead of IP Addresses # BitcoinTalk Re: Hostnames instead of IP Addresses 2010-06-14 19:53:44 UTC - Original Post SirArthur has a good point about the normal online merchant case, which is what the send-by-IP option is more suited to. This is the case where the merchant will have a server on a static IP and their own domain name and SSL cert. Instead of connecting by IP, we can connect to a domain name by SSL, using the existing CA infrastructure to authenticate that you’re connected to the owner of that domain. The user would send to domain.com (or www.domain.com is ok too). That would be very natural and users could see and verify that what they entered is who they intend to pay. The SSL also makes it safe for TOR users. Problem is, I think merchants would still prefer to use bitcoin addresses to be certain they know what the payment is for. You simply cannot count on users to enter the right thing in the comment fields to identify the transaction. It would only approach practical if we had a mailto style link that prepopulates the comment field with the order number, but then the link could just as well be a bitcoin address. Just having an open bitcoin server at domain.com that users could send unidentified payments to would be too much of a liability. Regular users aren’t used to the idea of having to identify the payment. Merchants would get too many blank payments followed by “I paid you, where’s my stuff?!” a week later. The payment sequence does have a step where the receiver verifies the order before accepting it. It can reject the payment and return an error message if it doesn’t contain a valid order number. That would require a difficult level of integration of custom code with the bitcoin server though. ## 2010-06-14 20:39:50 UTC - Re: Dealing with SHA-256 Collisions # BitcoinTalk Re: Dealing with SHA-256 Collisions 2010-06-14 20:39:50 UTC - Original Post SHA-256 is very strong. It’s not like the incremental step from MD5 to SHA1. It can last several decades unless there’s some massive breakthrough attack. If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function. If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can’t be used. ## 2010-06-14 22:21:55 UTC - Re: Technical clarifications # 1. Nothing, if sending by bitcoin address 2. It is decentralised. After you have connected to the network the first time, you no longer need IRC. ## 2010-06-14 22:40:14 UTC - Re: Can’t Build r80 from SVN # BitcoinTalk Re: Can’t Build r80 from SVN 2010-06-14 22:40:14 UTC - Original Post Sorry, I didn’t test compile on linux the last few revisions. Reverted makefile.unix. ## 2010-06-15 23:41:29 UTC - Re: What is the incentive to collect transactions? # BitcoinTalk Re: What is the incentive to collect transactions? 2010-06-15 23:41:29 UTC - Original Post Quote from: theymos on June 05, 2010, 04:26:09 PM Adding transactions to the block you’re working on will slow down your generation rate The premise is false. Adding more transactions to the block you’re working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a hash of the transactions (the Merkle root) and is only updated occasionally. If necessary I can write code to make nodes prefer not to use a block if it doesn’t contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there’s no real advantage for nodes not to include all transactions. ## 2010-06-16 00:15:47 UTC - Re: URI-scheme for bitcoin # http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345 or http://127.0.0.1:8330/?to=1.2.3.4&amount=200.00 But as long as the link is already doing the typing for you, I don’t see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can’t send an unidentified payment. They can’t send payment until they’ve been given a correct bitcoin address to send to. What would be nice about sending by domain is you could visually verify who it’s going to. A more crucial issue is what if the browser isn’t allowed to connect to 127.0.0.1: http://bitcointalk.org/index.php?topic=63.msg1589#msg1589 and if that’s true, then what about that example freenet link that had 127.0.0.1 in it? ## 2010-06-16 16:53:34 UTC - Re: Website translations # Thanks DataWraith! The German translation is uploaded to SVN. This is great, we’ve already got 3 major languages. ## 2010-06-17 17:07:56 UTC - Re: new binary release? # I’m working on getting version 0.3 released as soon as I can. Just a last few things left to do. It’s been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available. This time we’ll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release. Plus, we’ll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!). ## 2010-06-17 18:46:08 UTC - Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG # BitcoinTalk Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG 2010-06-17 18:46:08 UTC - Original Post The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender’s conditions are met. The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script. The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them. The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we’ll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later. I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint. ## 2010-06-18 16:17:14 UTC - Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG # BitcoinTalk Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG 2010-06-18 16:17:14 UTC - Original Post A second version would be a massive development and maintenance hassle for me. It’s hard enough maintaining backward compatibility while upgrading the network without a second version locking things in. If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version. If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there’s any disagreement, and that can be pretty ugly for the minority version and I’d rather not go into it, and I don’t have to as long as there’s only one version. I know, most developers don’t like their software forked, but I have real technical reasons in this case. Quote from: gavinandresen on June 17, 2010, 07:58:14 PM I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it. I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel. That’s a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends… That’s one of the reasons for transaction fees. There are other things we can do if necessary. Quote from: laszlo on June 17, 2010, 06:50:31 PM How long have you been working on this design Satoshi? It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first. Everyone has the obvious questions looking for holes in it but it is holding up well Since 2007. At some point I became convinced there was a way to do this without any trust required at all and couldn’t resist to keep thinking about it. Much more of the work was designing than coding. Fortunately, so far all the issues raised have been things I previously considered and planned for. ## 2010-06-18 17:28:18 UTC - Re: On IRC bootstrapping # The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes. There are enough seed nodes now that many of them should still be up by the time of the next release. It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while. At that point, be patient. It’s only slow to get connected the first time. This means TOR users won’t need to -addnode anymore, it’ll get connected automatically. ## 2010-06-18 23:08:34 UTC - Re: Get 5 free bitcoins from freebitcoins.appspot.com # BitcoinTalk Re: Get 5 free bitcoins from freebitcoins.appspot.com 2010-06-18 23:08:34 UTC - Original Post Excellent choice of a first project, nice work. I had planned to do this exact thing if someone else didn’t do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away. Donations should be able to keep it filled. The display showing the balance in the dispenser encourages people to top it up. You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something. ## 2010-06-21 17:20:21 UTC - Re: Bitcoin in Ubuntu 10.04 # BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-21 17:20:21 UTC - Original Post Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM Bitcoin looks ugly in Ubuntu’s new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They’re similar enough that it’s unreadable on my display. It should be fixed before the next stable release. This is now fixed in the SVN version. 1. Menu bar default color. 2. Balance bar not a different color. 3. Background behind bitcoin address and balance now the same color as toolbar. I checked all the standard themes and it seems reasonable with all of them. Ubuntu minimize,maximize,close buttons to the right: gconf-editor apps->metacity->general button_layout=menu:minimize,maximize,close They've got it awfully buried considering 9 out of 10 users are used to having it on the right. ## 2010-06-21 17:48:26 UTC - Re: Dying bitcoins # Lost coins only make everyone else’s coins worth slightly more. Think of it as a donation to everyone. Quote from: laszlo on June 21, 2010, 01:54:29 PM I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people’s coins instead? The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive? Maybe Satoshi can address this.. Computers have to get about 2^200 times faster before that starts to be a problem. Someone with lots of compute power could make more money by generating than by trying to steal. ## 2010-06-21 18:09:17 UTC - Re: Proof-of-work difficulty increasing # I integrated the hashmeter idea into the SVN version. It displays khash/s in the left section of the status bar. Two new log messages: 21/06/2010 01:23 hashmeter 2 CPUs 799 khash/s 21/06/2010 01:23 generated 50.00 grep your debug.log for “generated” to see what you’ve generated, and grep for “hashmeter” to see the performance. On windows, use: findstr “hashmeter generated” “%appdata%itcoin\debug.log” I have the hashmeter messages once an hour. How often do you think it should be? ## 2010-06-22 03:45:56 UTC - Re: Bitcoin in Ubuntu 10.04 # BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-22 03:45:56 UTC - Original Post On Ubuntu 10.04 it wouldn’t remove the taskbar button cleanly, so I made it leave it there. But now that you mention it, it’s probably better to have the feature, even if it’s messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it. Updated SVN. Thanks for testing. ## 2010-06-22 04:01:53 UTC - 0.3 almost ready – please test the Mac version! # BitcoinTalk 0.3 almost ready – please test the Mac version! 2010-06-22 04:01:53 UTC - Original Post I finished everything on my list to do for version 0.3. The code on SVN is about ready to release. Testing at this point is much appreciated. ## 2010-06-22 04:35:26 UTC - Re: How fast do the fastest computers generate bitcoins? # BitcoinTalk Re: How fast do the fastest computers generate bitcoins? 2010-06-22 04:35:26 UTC - Original Post I’ve noticed that hashing performance doesn’t vary as much between CPUs as you’d expect. Compared to an old CPU, a newer CPU doesn’t show as much of a speedup at hashing as it does on general benchmarks. I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction. Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long. The latest SVN version has a khash/s display. Around 400 khash/s per processor is typical. ## 2010-06-22 16:39:43 UTC - Re: Bitcoin in Ubuntu 10.04 # BitcoinTalk Re: Bitcoin in Ubuntu 10.04 2010-06-22 16:39:43 UTC - Original Post It’s too late now for feature changes to 0.3, but I’ll add that to the post-0.3 to do list. I never would have noticed that if you hadn’t pointed it out. ## 2010-06-22 16:51:14 UTC - Re: Proof-of-work difficulty increasing # Agree. Certainly too trivial to clutter the user’s attention with. I changed it to every 30 minutes. If I increased it to every 10 minutes, it would still be a small enough presence in the log file. Question is whether that would be more output than the user wants when they grep. ## 2010-06-22 17:02:07 UTC - Re: 0.3 almost ready # Quote from: lachesis on June 22, 2010, 06:20:02 AM It would be nice if the listtransactions RPC method were finished before the next release, though. My fear is too many programmers would latch onto that for checking for received payments. It can never be reliable that way. The list/getreceivedbyaddress/label functions are the only way to do it reliably. We shouldn’t delay forever until every possible feature is done. There’s always going to be one more thing to do. ## 2010-06-22 17:37:08 UTC - Re: 0.3 almost ready # Here’s RC1 for windows for testing: (removed, see RC2 below) Please only download this if you’re going to test and report back whether everything seems fine or not. Make sure to look through the files in “c:\program filesitcoin” ## 2010-06-22 19:11:41 UTC - Re: 0.3 almost ready # Quote from: davidonpda on June 22, 2010, 06:23:26 PM EXCEPTION: 22DbRunRecoveryException DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery C:\Program Files\Bitcoinitcoin.exe in OnInit() What operating system? Normally when it does that it’s because the directory where the data directory should go doesn’t exist. See if the “%appdata%” directory exists. Do you get that error with 0.2 also? It’s hard to see how you could get that with 0.3 and not with 0.2 since there’s nothing different in that regard. ## 2010-06-22 19:25:13 UTC - Re: 0.3 almost ready # davidonpda, were you also running laszlo’s build previously? Check if the “%appdata%” directory exists, and “%appdata%itcoin” Try: rename “%appdata%itcoin” bitcoin2 does it work then? ## 2010-06-22 19:46:23 UTC - Re: 0.3 almost ready # You figured it out faster than I could post a reply. It looks like laszlo’s build of Berkeley DB has database/log.* files that are not compatible with ours. The .dat files are fine, their format shouldn’t ever change. All data is stored in the .dat files. All your own data is stored in wallet.dat. If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded. When you copied the directory except log.0000000002, that’s the best solution. You should be good now. The database/log.* files only contain temporary database data. If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely. They’re only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data. Please keep running v0.3 if at all possible, don’t go back to v0.2.10. Anyone else who hits this problem, move the databaselog.000000000* files somewhere else. (if it works fine after that, you can delete them later) I’m reluctant to make the installer delete or move those files. If the previous run was stopped by crashing or killed, that would be the wrong thing to do. ## 2010-06-22 22:23:39 UTC - Re: 0.3 almost ready # Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build. 30khash increase to what total rate? (to figure the % increase) ## 2010-06-24 17:40:05 UTC - Re: 0.3 almost ready # Here’s RC1 for linux for testing: (link removed, see below) It contains both 32-bit and 64-bit binaries. Recent changes: build-unix.txt: • Added instructions for building wxBase, which is needed to compile bitcoind. • The package libboost-dev doesn’t install anything anymore, you need to get libboost-all-dev. • Updated version numbers. makefile.unix: • The libboost libraries have removed the “-mt” from their filenames in 1.40. If you’re compiling with Boost 1.38 or lower, like on Ubuntu Karmic, you would need to change it back to boost_system-mt and boost_filesystem-mt. ## 2010-06-25 02:17:41 UTC - Re: 0.3 almost ready # I don’t know. Maybe someone with more Linux experience knows how to install the library it needs. I built it on Ubuntu 10.04. I hope that wasn’t a mistake. Maybe it should have been built on an older version for more backward compatibility. Is this a problem on Linux, that if you build on the latest version, then it has trouble working on older versions? Is there any way I can downgrade to an older version of GCC on 10.04? The 64-bit version shouldn’t be any faster than the 32-bit version, but it would be great if someone could do a side-by-side comparison of the two linux versions and check. SHA-256 is a 32-bit algorithm and nothing in BitcoinMiner uses 64-bit at all. We don’t need to bother with a 64-bit version for Windows. 32-bit programs work on all versions of Windows. It’s not like Linux where the 64-bit OS wants 64-bit programs. I’m also curious if it’s a little faster on linux than windows. Do you think I should make the directories: bin32 bin64 instead of bin/32 bin/64 ## 2010-06-25 14:10:06 UTC - Re: 0.3 almost ready # Thanks virtualcoin, that’s a perfect comparison. The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5). The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The code is completely 32-bit. Hmm, I think the 8 extra registers added by x86-64 must be what’s helping. That would make a significant difference to SHA if it could hold most of the 16 state variables in registers. ## 2010-06-25 21:15:15 UTC - Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel # BitcoinTalk Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel 2010-06-25 21:15:15 UTC - Original Post We need more details about what happened MadHatter. Both 0.2 and 0.3 have a backup way of getting connected without IRC, it’s just slower to get connected. 0.2 can find other nodes without IRC if it’s ever been connected before, but a new install can’t discover the network for the first time without IRC. 0.3 can also seed without IRC. It can operate entirely without IRC if it needs to, but it’s better having IRC for redundancy. ## 2010-06-25 22:40:47 UTC - Re: On IRC bootstrapping # Quote from: laszlo on June 14, 2010, 06:30:58 PM I run an IRC server you can use, it’s fairly stable but it’s not on redundant connections or anything. It is only two servers right now but we don’t mess with it or anything, it just runs. My box is a dedicated irc server: 2:28PM up 838 days, 20:54, 1 user, load averages: 0.06, 0.08, 0.08 You can use irc.lfnet.org to connect. This seems like a good idea. What does everyone think, should we make the switch for 0.3? ## 2010-06-26 00:32:09 UTC - Re: 0.3 almost ready # Lets try using Laszlo’s irc.lfnet.org instead of freenode. Here’s RC2, that’s the only change in it: (see below for download links) ## 2010-06-26 14:28:06 UTC - Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel # BitcoinTalk Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel 2010-06-26 14:28:06 UTC - Original Post Freenode is too visible, right in the middle of where all those users and moderators are hanging out. Laszlo’s option is a much better fit for us. I made 0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to start switching over: http://bitcointalk.org/index.php?topic=199.msg1787#msg1787 ## 2010-06-26 15:10:10 UTC - Re: 0.3 almost ready # The first panel of the status bar is shared with the help description of menu items as you hover over them. Since all our menu item descriptions are blank, it replaces it with blank when you’re hovering in a menu. ## 2010-06-26 17:02:43 UTC - Beta? # Is it about time we lose the Beta? I would make this release version 1.3. ## 2010-06-26 19:21:05 UTC - Re: 1.3 almost ready # Changed the version number to 1.3 and removed “Beta”. (links removed, see below) Uses irc.lfnet.org. ## 2010-06-26 20:58:26 UTC - Re: Bitcoin mobile. # Quote from: sirius-m on June 10, 2010, 01:51:16 PM You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them. I think that’s the best option right now. Like cash, you don’t keep your entire net worth in your pocket, just walking around money for incidental expenses. They could make a smaller version of the site optimized for mobile. If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there’s already a universal QR-code reading app that web sites can be designed to accept scans from. If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis? It could always be an Android app instead. An app is not really necessary though, just a mobile sized website. A web interface to your own Bitcoin server at home wouldn’t be a solution for everyone. Most users don’t have a static IP, and it’s too much trouble to set up port forwarding. ## 2010-06-26 21:06:06 UTC - Re: Building BitCoin Client completely Headless # BitcoinTalk Re: Building BitCoin Client completely Headless 2010-06-26 21:06:06 UTC - Original Post The linux release candidate in the “1.3 almost ready” thread contains prebuilt bitcoind. ## 2010-06-26 21:39:52 UTC - Re: Bitcoin Faucet changes # Many big ISPs give you a new IP every time you connect, usually in the same class B (a.b.?.?). Maybe you should have a minimum time between payments per class-B. If you can’t solve the problem, you can always keep lowering the amount of bitcoins given until it’s manageable, and always require captcha. ## 2010-06-27 12:43:50 UTC - Re: Beta? # But 1.0 sounds like the first release. For some things newness is a virtue but for this type of software, maturity and stability are important. I don’t want to put my money in something that’s 1.0. 1.0 might be more interesting for a moment, but after that we’re still 1.0 and everyone who comes along thinks we just started. This is the third major release and 1.3 reflects that development history. (0.1, 0.2, 1.3) ## 2010-06-27 13:02:38 UTC - Re: IPv6, headless client, and more # BitcoinTalk Re: IPv6, headless client, and more 2010-06-27 13:02:38 UTC - Original Post Welcome, Harry. I hadn’t thought about starting out using bitcoind without using bitcoin first. I guess for now, this thread serves as the tutorial. The focus for bitcoind so far has been more on backend support for websites. There’s demand for things that would be nice for adminning headless generators like listgenerated. For the moment, you can grep the debug.log file for “generated” and “hashmeter” for some feedback. Generated blocks take about 24 hours before they’re credited to your balance. ## 2010-06-27 15:30:13 UTC - Re: 1.3 almost ready # MinGW still only has good old stable 3.4.5. There’s not much reason for them to update it. When I looked at the 3.4.5 compiled SHA disassembly, I couldn’t see any room for improvement at all. I can’t imagine how 8% more could be squeezed out of it. Is it possible Windows could have 8% more overhead? Not making system calls or anything, just plain busy computational code, could task switching and other housekeeping operations take away that much? ## 2010-06-27 19:06:09 UTC - Re: Major Meltdown # Here’s an answer to a similar question about how to recover from a major meltdown. https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585 Quote from: satoshi on June 14, 2010, 08:39:50 PM If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function. If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can’t be used. ## 2010-07-02 19:21:36 UTC - Re: Feature Request: Limiting Connections # BitcoinTalk Re: Feature Request: Limiting Connections 2010-07-02 19:21:36 UTC - Original Post Thanks for the feedback on this. One thing we could do is lower the outbound connections from 15 to 10 or maybe even 5. The choice of 15 was arbitrary. It just needs to be enough for redundancy and fast exponential propagation of messages. 10 would still be plenty. 5 should be fine. 10 is good as a nice round number so users can see that it stopped intentionally. It would help to implement UPnP so there would be more inbound accepting nodes. Your number of connections is the ratio of inbound accepting nodes to out-only times 15. We need to encourage more people to accept inbound connections. I will implement a feature to stop accepting inbound connections once you hit a certain number. Which version are you running? Anyone know how many connections typical P2P software like BitTorrent can get up to? ## 2010-07-02 20:37:17 UTC - Re: 1.3 almost ready # On a related note, is the thing compilable by Visual C++? I’m inclined to give it a try when I get around to it. ## 2010-07-02 21:57:45 UTC - Re: 0.3 almost ready # (reverted to rc2) Links removed, 0.3 is now released, so go to http://www.bitcoin.org to download it. ## 2010-07-02 22:03:41 UTC - Re: Beta? # OK, back to 0.3 then. Please download RC4 and check it over as soon as possible. I’d like to release it soon. http://bitcointalk.org/index.php?topic=199.msg1927#msg1927 Other than the version number change, which included changes in readme.txt and setup.nsi, I reduced the maximum number of outbound connections from 15 to 8 so nodes that accept inbound don’t get too many connections. 15 was a lot more than needed. 8 is still plenty for redundancy. ## 2010-07-02 22:20:20 UTC - Re: Feature Request: Limiting Connections # BitcoinTalk Re: Feature Request: Limiting Connections 2010-07-02 22:20:20 UTC - Original Post I reduced max outbound connections from 15 to 8 in RC4. 15 was way more than we needed for redundancy. 8 is still plenty of redundancy. As the nodes upgrade to this version, this will cut in half the number of connections that inbound accepting nodes get. If anyone wants more than 8 connections, they can open port 8333 on their firewall. ## 2010-07-04 21:52:28 UTC - Re: 0.3 almost ready – please test the Mac version! # BitcoinTalk Re: 0.3 almost ready – please test the Mac version! 2010-07-04 21:52:28 UTC - Original Post Laszlo’s build is going to be our first Mac release so please test it! ## 2010-07-05 21:31:14 UTC - Re: Slashdot Submission for 1.0 # BitcoinTalk Re: Slashdot Submission for 1.0 2010-07-05 21:31:14 UTC - Original Post BTW, I did come to my senses after that brief bout with 1.3, this release is still going to be 0.3 beta not 1.0. I really appreciate the effort, but there are a lot of problems. We don’t want to lead with “anonymous”. (I’ve been meaning to edit the homepage) “The developers expect that this will result in a stable-with-respect-to-energy currency outside the reach of any government.” – I am definitely not making an such taunt or assertion. It’s not stable-with-respect-to-energy. There was a discussion on this. It’s not tied to the cost of energy. NLS’s estimate based on energy was a good estimated starting point, but market forces will increasingly dominate. Sorry to be a wet blanket. Writing a description for this thing for general audiences is bloody hard. There’s nothing to relate it to. ## 2010-07-06 18:32:35 UTC - Bitcoin 0.3 released! # Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin’s total circulation is limited to 21 million coins. The coins are gradually released to the network’s nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time. What’s new: • Command line and JSON-RPC control • Includes a daemon version without GUI • Transaction filter tabs • 20% faster hashing • Hashmeter performance display • Mac OS X version (thanks to Laszlo) • German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at or read the forum to find out more. ## 2010-07-06 21:53:53 UTC - [bitcoin-list] Bitcoin 0.3 released! # Announcing version 0.3 of Bitcoin, the P2P cryptocurrency! Bitcoin is a digital currency using cryptography and a distributed network to replace the need for a trusted central server. Escape the arbitrary inflation risk of centrally managed currencies! Bitcoin’s total circulation is limited to 21 million coins. The coins are gradually released to the network’s nodes based on the CPU power they contribute, so you can get a share of them by contributing your idle CPU time. What’s new: • Command line and JSON-RPC control • Includes a daemon version without GUI • Transaction filter tabs • 20% faster hashing • Hashmeter performance display • Mac OS X version (thanks to Laszlo) • German, Dutch and Italian translations (thanks to DataWraith, Xunie and Joozero) Get it at http://www.bitcoin.org, and read the forum to find out more. ## 2010-07-06 19:43:18 UTC - Re: 0.3 almost ready – please test the Mac version! # Re: 0.3 almost ready – please test the Mac version! ## 2010-07-07 01:31:07 UTC - Re: On IRC bootstrapping # Everybody needs to connect to the same IRC server and channel so they can find each other. Quote from: Vasiliev on June 25, 2010, 11:50:15 PM You may want to leave Freenode in as a fallback server – if his server doesn’t work, use Freenode’s. It might not be good if we suddenly rushed freenode with a ton of users all at once. The fallback is our own seed system. irc.lfnet.org is pretty old and has impressive uptime. I think it’s going to be fine. We could take IRC out at some point if we want, but I’d rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems. ## 2010-07-08 18:24:19 UTC - Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username # BitcoinTalk Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username 2010-07-08 18:24:19 UTC - Original Post Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in version 0.3, so it must be related to that. Just to confirm, if you log in with the non-latin character username, not having an appdata/Bitcoin directory yet, and run Bitcoin and let it create the database from scratch, does it work or not? ## 2010-07-08 19:12:00 UTC - Re: Anonymity # It’s hard to imagine the Internet getting segmented airtight. It would have to be a country deliberately and totally cutting itself off from the rest of the world. Any node with access to both sides would automatically flow the block chain over, such as someone getting around the blockade with a dial-up modem or sat-phone. It would only take one node to do it. Anyone who wants to keep doing business would be motivated. If the network is segmented and then recombines, any transactions in the shorter fork that were not also in the longer fork are released into the transaction pool again and are eligible to get into future blocks. Their number of confirmations would start over. If anyone took advantage of the segmentation to double-spend, such that there are different spends of the same money on each side, then the double-spends in the shorter fork lose out and go to 0/unconfirmed and stay that way. It wouldn’t be easy to take advantage of the segmentation to double-spend. If it’s impossible to communicate from one side to the other, how are you going to put a spend on each side? If there is a way, then probably someone else is also using it to flow the block chain over. You would usually know whether you’re in the smaller segment. For example, if your country cuts itself off from the rest of the world, the rest of the world is the larger segment. If you’re in the smaller segment, you should assume nothing is confirmed. ## 2010-07-09 03:01:35 UTC - Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username # BitcoinTalk Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username 2010-07-09 03:01:35 UTC - Original Post I think I see where the problem is. Coincidentally, I recently coded a replacement for the function in question which should fix it. It’s not enabled yet, but in the SVN version it prints a debug message in debug.log showing the new directory value and old value for comparison. ## Massive Attack against BTC system. Is it really? - Re: BTC Vulnerability? ()/(2010-07-09 03:28:46 UTC)/ # BitcoinTalk Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?) 2010-07-09 03:28:46 UTC - Original Post What the OP described is called “cornering the market”. When someone tries to buy all the world’s supply of a scarce asset, the more they buy the higher the price goes. At some point, it gets too expensive for them to buy any more. It’s great for the people who owned it beforehand because they get to sell it to the corner at crazy high prices. As the price keeps going up and up, some people keep holding out for yet higher prices and refuse to sell. The Hunt brothers famously bankrupted themselves trying to corner the silver market in 1979: “Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the world silver markets in the late 1970s and early 1980s, at one stage holding the rights to more than half of the world’s deliverable silver.[1] During Hunt’s accumulation of the precious metal silver prices rose from$11 an ounce in September 1979 to nearly $50 an ounce in January 1980.[2] Silver prices ultimately collapsed to below$11 an ounce two months later,[2] much of the fall on a single day now known as Silver Thursday, due to changes made to exchange rules regarding the purchase of commodities on margin.[3]"

http://en.wikipedia.org/wiki/Cornering_the_market

## 2010-07-09 15:37:05 UTC - Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username #

BitcoinTalk

2010-07-09 15:37:05 UTC - Original Post

I tested this with a non-lower-ASCII account name on XP and confirmed the bug, then tested that the new GetDefaultDataDir fixed it. This change is revision 102 of the SVN.

## 2010-07-10 12:58:02 UTC - Re: Security #

I’ll start thinking about how to do this.

At the moment, you can kind of use -connect. You can use -connect to make it connect to local computers on your LAN, like -connect=192.168.0.100. If you start it out blank and don’t let it connect to the main network, the difficulty is still at the original low difficulty. If you’ve port-forwarded though, then outside nodes might still connect inward to you.

With -connect it still uses IRC, do you think it shouldn’t get on IRC when you’re telling it to only connect to specific nodes with -connect? The main scenario for -connect is where you have a server farm, with two connected to the network and the rest connected to the first two. In that case, you wouldn’t want the -connect computers on IRC.

{
if (mapArgs.count("-connect”))
return;

## 2010-07-10 13:36:17 UTC - Re: Major Meltdown #

Quote from: llama on July 01, 2010, 10:21:47 PM

However, if something happened and the signatures were compromised (perhaps integer factorization is solved, quantum computers?), then even agreeing upon the last valid block would be worthless.

True, if it happened suddenly. If it happens gradually, we can still transition to something stronger. When you run the upgraded software for the first time, it would re-sign all your money with the new stronger signature algorithm. (by creating a transaction sending the money to yourself with the stronger sig)

BitcoinTalk

2010-07-14 16:22:03 UTC - Original Post

The link: “Win32 CPU Cycles vs ‘Live Protection’ Engines”

For BitcoinFX, Live Protection was keeping it from getting CPU for generating coins. You said your friend was getting 1400-1600 khash/s, so it was getting CPU. I guess Live Protection must have been blocking some other part of the program then?

## 2010-07-14 16:29:39 UTC - Re: resource hog #

In Windows, you select the process in the task manager, right click, Set Priority. Set it to BelowNormal or Low. That shouldn’t make a difference though.

If you turn off Generate Coins, does the CPU usage go flat? That would confirm that all the CPU time it’s taking is generate, which is idle priority already.

It could be it’s slow just because you have too many things running at once and you’re out of memory. When you switch from one thing to another, it has to page it in from disk.

## 2010-07-14 17:04:02 UTC - Re: stopped prodicing coins #

Thanks for making that calculator.

The difficulty doubled a day or two ago, plus it’s just random and you can have surprisingly long dry spells.

## 2010-07-14 17:34:50 UTC - Re: Building Bitcoin 0.3 #

It doesn’t work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately, there isn’t a Debian package of wxWidgets 2.9 yet.

## 2010-07-14 17:38:31 UTC - Re: bitcoin auto-renice-ing #

Laszlo corrected this, but unfortunately it was too late to make it into 0.3.0. There will probably be a 0.3.1 soon though.

The problem is I used PRIO_MIN, I should have used PRIO_MAX for the lowest priority. The OS isn’t supposed to let you increase priority, so the PRIO_MIN ought to leave it at priority 0.

## 2010-07-14 18:02:28 UTC - Re: Stuck on 513 blocks #

BitcoinTalk

Re: Stuck on 513 blocks

2010-07-14 18:02:28 UTC - Original Post

This is the second time I’ve seen this “Live Protection” problem reported.

It must be blocking the program’s network communication. It sounds like it’s allowing connections to be made, hence the 10 connections shown, but not allowing any data to be sent or received on them.

We need to understand this problem better.

Can someone write some instructions on the wiki explaining how to turn off or add an exclusion to Live Protection or whatever its full proper name is.

## 2010-07-14 18:25:41 UTC - Re: Error on Ubuntu 10.04 #

BitcoinTalk

Re: Error on Ubuntu 10.04

2010-07-14 18:25:41 UTC - Original Post

What language is your computer set to? Is it set to German, Dutch or Italian? Is it one of those sub-languages like “nl-??”?

It’s trying to load a translation and failing. You could delete the locale directory that came with bitcoin so it doesn’t try to use it.

Can someone test each language on Ubuntu and see if there’s a problem with just one of them or maybe all three?

## ) - Linux Client - Re: Runaway CPU usage for 64bit BitCoin ((2010-07-14 18:45:53 UTC)#

BitcoinTalk

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

2010-07-14 18:45:53 UTC - Original Post

After it initially tries incorrectly to set itself to the lowest priority, the generate thread only changes its priority again temporarily when it finds a block. When you’ve found a block, you should want it to hurry up and broadcast it as soon a possible before someone else finds one and makes yours invalid. The generate thread only changes to higher priority for less than a second every few days.

There should be a 0.3.1 release for this soon. There are a few other issues we need to look at fixing in 0.3.1 before making a release.

Quote from: knightmb on July 12, 2010, 10:39:13 PM

On a side note, I’ve tracked down the other GUI issue.

The “minimize to tray instead of taskbar” is what was eating up all the CPU on my system. After I turned this off, the issue was resolved with Runaway CPU.

This only seems to affect the 64 bit Client, as the 32 bit Clients I have don’t seem to be affected by this.

I did notice on the 64 bit Client, what happens is, it spawns multiple “tray” icons until X server finally kills over, so I guess I should submit that as a bug to somewhere?

That’s interesting. I know the minimize to tray on Ubuntu is very clunky, but I didn’t know it had a CPU peg problem too. Anyone else able to reproduce this problem? We had this feature disabled on Linux before, but then it seemed better to have the imperfect UI than to lose the feature entirely. I’m thinking we should disable it again on Linux.

## ) - 2010-07-14 18:56:29 UTC - Re: Warning this block was not received by any other nodes/(/ #

BitcoinTalk

Re: Warning this block was not received by any other nodes

2010-07-14 18:56:29 UTC - Original Post

Microsoft Security Essentials Live Protection is blocking your communication with the network. You have connections, which tricks Bitcoin into thinking it’s connected, but they are silent because the data is being blocked.

You need to make bitcoin.exe an excluded process in Live Protection.

This is becoming a common problem. Someone should write this up in a pegged thread.

The message “Warning: This block was not received by any other nodes” occurs when Bitcoin broadcasts a block, but nobody confirms they received it. The warning is there just for this kind of situation, where for some reason you have connections, but they have gone dead and nobody can hear you. Your block will never become valid because nobody received it.

## 2010-07-14 20:25:06 UTC - Re: Hash/sec Throttling for Democracy #

BitcoinTalk Re: Hash/sec Throttling for Democracy 2010-07-14 20:25:06 UTC - Original Post

Quote from: knightmb on July 14, 2010, 07:17:43 PM

So if your computer was only 1% towards solving block 68000

This is a common point of confusion. There’s no such thing as being 1% towards solving a block. You don’t make progress towards solving it. After working on it for 24 hours, your chances of solving it are equal to what your chances were at the start or at any moment.

It’s like trying to flip 37 coins at once and have them all come up heads. Each time you try, your chances of success are the same.

The RNG is the OpenSSL secure random number generator. On Windows it’s seeded with the complete set of all hardware performance counters since your computer started, on Linux it’s dev/random.

## 2010-07-14 21:10:52 UTC - Re: Scalability #

The design outlines a lightweight client that does not need the full block chain. In the design PDF it’s called Simplified Payment Verification. The lightweight client can send and receive transactions, it just can’t generate blocks. It does not need to trust a node to verify payments, it can still verify them itself.

The lightweight client is not implemented yet, but the plan is to implement it when it’s needed. For now, everyone just runs a full network node.

I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it’s not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.

At equilibrium size, many nodes will be server farms with one or two network nodes that feed the rest of the farm over a LAN.

## 2010-07-15 00:18:23 UTCLinux Client - Re: Runaway CPU usage for 64bit BitCoin #

BitcoinTalk

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

2010-07-15 00:18:23 UTC - Original Post

OK, the undocumented switch “-minimizetotray” which re-enables the option.

I uploaded the change to SVN.

## 2010-07-15 14:05:20 UTC - Re: [Bitcoin 0.3.0] Runtime error #

BitcoinTalk

Re: [Bitcoin 0.3.0] Runtime error

2010-07-15 14:05:20 UTC - Original Post

More directly, this:
http://bitcointalk.org/index.php?topic=246.0

I will be posting release candidate of 0.3.1 with this fix shortly. Please try that and let me know if it fixes the problem.

## 2010-07-15 14:33:04 UTC - Re: Static Linux x86_64 bins for those having libcrypto troubles #

BitcoinTalk

Re: Static Linux x86_64 bins for those having libcrypto troubles

2010-07-15 14:33:04 UTC - Original Post

We don’t even specify linking glibcxx_3.4.11, so gcc must automatically link it behind the scenes. There’s probably a compiler switch that would tell it to static link it. I’m not sure what the licensing issues would be. Typically, compiler stuff is fully redistributable.

## 2010-07-15 14:59:00 UTC - Re: resource hog #

Then all the CPU time is the generate thread, which definitely runs at the lowest possible priority, idle priority. It’s normal that your CPU meter is 100%. Since it’s idle priority, it won’t actually slow anything else down, even though the CPU meter is 100%.

## 2010-07-15 17:05:54 UTC - Bitcoin 0.3.1 released #

This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn’t need any fixes so we don’t really need to update it, 0.3.0 is still good.

Changes:

• Added Portuguese translation by Tiago Faria

Windows

• Fix for 22DbRunRecoveryException if your username has non-ascii characters in it

Linux

• Laszlo’s fix for lowering generate thread to lowest priority
• Fix for if you’re having trouble with libcrypto linkage
• Gavin Andresen’s implementation of “start on windowing system startup” option

## 2010-07-15 17:23:48 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 17:23:48 UTC - Original Post

Well, it can’t hurt to do a backup and it’s a good idea to backup regularly, but no, a backup is not required before installing this.

## 2010-07-15 17:56:43 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 17:56:43 UTC - Original Post

I don’t think you have a particular problem, I think your system is laggy because you’re running a lot of things at once and hitting the pagefile because memory is full. You confirmed when you shut off generation that your CPU drops to 0%, so the CPU usage is definitely all idle priority. There’s nothing in the 0.3.1 that would affect these things.

## 2010-07-15 18:30:22 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-07-15 18:30:22 UTC - Original Post

Quote from: aidos on July 15, 2010, 12:49:11 AM

Ok here is the .po file for French. While I’m at it, I noted a couple of issues:

1. The “About” box didn’t take the translation into account, it still displays the english version to me, even though the rest of the software is using the translated strings, and the .po file contains the translation string of the “About” box message. Same problem with the “Apply” button in the Settings window.

I need to give an updated .po file.

Quote from: aidos on July 15, 2010, 12:49:11 AM

1. If an transaction’s description in the list of transaction in the main window contains a diacritical character (such as “\u00e9\u00e0\u00e8\u00e7”), it’s not displayed. I suppose the string is not being properly handled as UTF8 somewhere.

OK, this must be a problem somewhere, I’ll have to take a look at it or one of the other devs can.

Quote from: aidos on July 15, 2010, 12:49:11 AM

1. About the .po file :
2. There are a few strings in the .po file that don’t needs translation (ie: “Bitcoin”). Maybe those shouldn’t be inside _(”…”) ?
3. Others shouldn’t be split. I can remember one message about transaction fee where the string is split in two to insert the fee value, where you could simply have put a %s. It makes the message harder to translate as I had to go in the source to find exactly what was going on.
4. Some strings have whitespace at the end or start, which necessity is very debatable, and it’s easy to miss in PoEdit.

Many of the strings are in code automatically generated from uiproject.fbp where nothing can be done about these things. I have a program I use to find all the spacing inconsistencies at the beginning and ending of strings in your .po file and manually fix them up before I upload them to SVN.

## 2010-07-15 18:37:13 UTCRe: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-07-15 18:37:13 UTC - Original Post

I uploaded an updated bitcoin.po for 0.3.1 attached to this message:
http://bitcointalk.org/index.php?topic=151.msg1259#msg1259

please use it if you’re starting a new translation.

If you already have a po file, poedit can update it.

• Get the src directory from the 0.3.1 release candidate posted in the development forum, any version will do:
• Make a subdirectory under src: locale/??/LC_MESSAGES

(?? could be anything really, “en” or your language 2-letter code)

• Put your .po file there
• Open it with poedit
• In poedit, Catalog->Update from sources

The key is that the src directory with the sourcefiles needs to be 3 directories up from the .po file.

## 2010-07-15 18:43:54 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-07-15 18:43:54 UTC - Original Post

Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PM

As you can see the links on the English page points to the new 0.3 release, but the other languages only contain links for the old 0.2 version.
There’s a download box with the current releases on the right anyway, so why not remove the links from the translated pages.

I updated them to 0.3.0.

I am tempted to remove the download links from the other languages and only keep it on English.

They will need to be updated for 0.3.1 soon. Perhaps there’s a way for someone to manage the updating of the translated drupal pages.

## 2010-07-15 19:12:14 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-07-15 19:12:14 UTC - Original Post

Thanks for the Spanish and French translations! The edited and updated .po files are attached.

I uploaded these to the SVN.

## 2010-07-15 21:40:34 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 21:40:34 UTC - Original Post

Quote from: knightmb on July 15, 2010, 07:37:10 PM

On Windows, the priority of the Coin Generation is still net for normal. If you run BitCoin in Generate Coin mode, then load up something to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you’ll see that both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking all the CPU and BitCoin running only on idle/low process. The khash/s is also reduced in half, so further evidence that the threads are not running in a lower than normal prioirty.

I was not able to reproduce this. I have dual-proc, so I ran two memory hogs. Bitcoin got 0% of CPU according to the task manager. The khash/sec meter stayed stuck because it couldn’t get any CPU to update it.

Do you have dual-proc? Are you sure you weren’t running a single processor hog?

## 2010-07-15 22:07:35 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 22:07:35 UTC - Original Post

Quote from: knightmb on July 15, 2010, 08:15:46 PM

On the Linux client (64 bit), the “minimize on close” will still minimize to tray (causing X server hang after a short while by spawning multiple tray icons).

I updated the first post with a link to rc2 for linux with the fix for this. Please check that this is fixed for you. Thanks!

## 2010-07-15 22:10:19 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 22:10:19 UTC - Original Post

Quote from: db on July 15, 2010, 08:39:08 PM

Yes a bug. It’ll have to be fixed in the next version.

## 2010-07-15 22:18:26 UTC - Re: “SetIcons(): icon bundle doesn’t contain any suitable icon” #

BitcoinTalk

Re: “SetIcons(): icon bundle doesn’t contain any suitable icon”

2010-07-15 22:18:26 UTC - Original Post

That’s surprising that we’ve never heard of that before now.

Maybe you’re the first person to ever run it on Vista

I have to guess it has something to do with your display color depth selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a weird video card, display setup or running it on a tablet or mobile or something?

## 2010-07-15 22:22:30 UTC - Re: Runaway CPU usage for 64bit BitCoin (Linux Client) #

BitcoinTalk

Re: Runaway CPU usage for 64bit BitCoin (Linux Client)

2010-07-15 22:22:30 UTC - Original Post

The fix for the thread priority level on linux is available in the 0.3.1 release candidate here:
http://bitcointalk.org/index.php?topic=383.msg3198#msg3198

## 2010-07-15 23:23:04 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-15 23:23:04 UTC - Original Post

Quote from: RHorning on July 15, 2010, 10:29:28 PM

I don’t see either happening, although it did get put into the “Startup” folder. That is so Windows 95ish (just kidding….. Microsoft has so screwed this up that it isn’t even funny). I would recommend the registry settings for a number of reasons including the fact that most software puts the startup in that location, even though I personally find the startup folder to be more attractive and how most software on Windows should behave.

It could go either way. The Startup folder has the advantage that the end user can see it and manually remove it with the regular UI (not regedit) if they already blew away the Bitcoin directory and its uninstaller. Bitcoin will not relentlessly keep re-adding it if you delete it manually.

OpenOffice is another example of something that puts its link in the Startup folder.

## 2010-07-15 23:41:23 UTC - Re: “SetIcons(): icon bundle doesn’t contain any suitable icon” #

BitcoinTalk

Re: “SetIcons(): icon bundle doesn’t contain any suitable icon”

2010-07-15 23:41:23 UTC - Original Post

Quote from: bdonlan on July 15, 2010, 11:27:14 PM

in 120DPI mode.

What is “120DPI mode”? Is that an actual setting somewhere? Sounds like an obscure enough candidate. I suppose it needs twice the resolution icon to fill the size of the upper left corner icon. Only one size is provided.

## 2010-07-16 00:44:32 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-16 00:44:32 UTC - Original Post

Run it with the undocumented switch -minimizetotray and the option is available in the options menu.

I don’t know how to fix it. It’s something wrong deep inside wxWidgets or GTK or Gnome.

## 2010-07-16 02:02:07 UTC - Re: Donations to freebitcoins.appspot.com needed! #

BitcoinTalk

Re: Donations to freebitcoins.appspot.com needed!

2010-07-16 02:02:07 UTC - Original Post

5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2 BTC.

This is an important service so new users can at least get something if generating is too hard.

## 2010-07-16 02:43:29 UTC - Re: “SetIcons(): icon bundle doesn’t contain any suitable icon” #

BitcoinTalk

Re: “SetIcons(): icon bundle doesn’t contain any suitable icon”

2010-07-16 02:43:29 UTC - Original Post

That must be it then.

It must be looking for a larger icon like 20x20 but we don’t have one.

## 2010-07-16 14:46:12 UTC - Re: Proof-of-work difficulty increasing #

The proof-of-work difficulty is currently 45.38. (see http://www.alloscomp.com/bitcoin/calculator.php)

It’s about to increase again in a few hours. It’s only been 3-4 days since the last increase, so I expect it will increase by the max of 4 times, or very nearly the max. That would put it at 181.54.

The target time between adjustments is 14 days, 14/3.5 days = 4.0 times increase.

## 2010-07-16 14:52:04 UTC - Re: Assertion Failure - Ubuntu Lucid #

BitcoinTalk

Re: Assertion Failure - Ubuntu Lucid

2010-07-16 14:52:04 UTC - Original Post

That’s the first time I’ve seen this error.

How many blocks do you have? (in the status bar)

You should move your blk*.dat files (in ~/.bitcoin) to another directory and let it start over downloading the block chain again. If you don’t mind, could you keep the old blk*.dat files for a little while in case I need to look at them?

## 2010-07-16 14:55:23 UTC - Re: Fedora 13 libcrypto #

Please try the 0.3.1 release candidate, it should at least resolve the libcrypto dependency:

http://bitcointalk.org/index.php?topic=383.0

Let me know if that works.

## 2010-07-16 15:01:33 UTC - Re: Resending transaction #

Bitcoin automatically rebroadcasts your transactions if it receives new blocks that don’t contain them. It may take about an hour to get rebroadcasted. It is relentless though. It will keep nagging the network forever until your transaction gets into a block.

## 2010-07-16 15:09:59 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-16 15:09:59 UTC - Original Post

Because of all the dependencies that different systems don’t have. It’s easier to just static link what we can. It doesn’t increase the size by very much.

## 2010-07-16 15:37:00 UTC - Re: Source code documentation #

I like that in libraries for the external API’s, but you can probably tell from the code that I’m not a fan of it for interior functions. Big obligatory comment headers for each function space out the code and make you hesitate about creating a small little function where the comment header would be bigger than the function. They’re some trouble for maintenance, as changes to the function then require duplicate changes in the comment header. I like to keep code compact so you can see more code on the screen at once.

To add them now at this point, what would be written would just be what’s obvious from looking at the function.

The external API we have, in rpc.cpp, the usage documentation is in the help string.

Sorry to be a wet blanket.

## 2010-07-16 16:13:53 UTC - Re: Hash() function not secure #

BitcoinTalk

Re: Hash() function not secure

2010-07-16 16:13:53 UTC - Original Post

SHA256 is not like the step from 128 bit to 160 bit.

To use an analogy, it’s more like the step from 32-bit to 64-bit address space. We quickly ran out of address space with 16-bit computers, we ran out of address space with 32-bit computers at 4GB, that doesn’t mean we’re going to run out again with 64-bit anytime soon.

SHA256 is not going to be broken by Moore’s law computational improvements in our lifetimes. If it’s going to get broken, it’ll be by some breakthrough cracking method. An attack that could so thoroughly vanquish SHA256 to bring it within computationally tractable range has a good chance of clobbering SHA512 too.

If we see a weakness in SHA256 coming gradually, we can transition to a new hash function after a certain block number. Everyone would have to upgrade their software by that block number. The new software would keep a new hash of all the old blocks to make sure they’re not replaced with another block with the same old hash.

## 2010-07-16 16:47:14 UTC - Re: Request: expected bitcoins per day display #

BitcoinTalk

Re: Request: expected bitcoins per day display

2010-07-16 16:47:14 UTC - Original Post

Many businesses are like that. For a car salesman, when will the next customer walk in the door?

On the OP’s question, it’s a good feature, but the question is, how would we word it so people don’t expect to get something after that specific amount of time? “it said 7 days and I waited more than a week and didn’t get anything!” Approx, average, but still they’re going to think that way. It can’t be a whole sentence, unless we think of somewhere else to put it, but where would that be? Suggestions?

The difficulty quadrupled a few minutes ago to 181.54. It’s going to take typically about a week to generate now.

## 2010-07-16 16:56:54 UTC - Re: Proof-of-work difficulty increasing #

It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a week now.

The difficulty can adjust down as well as up.

The network should be generating close to 6 blocks per hour now.

## 2010-07-16 17:15:47 UTC - Re: Source code documentation #

It’s in init.cpp.

It’s a wxWidgets app, so it doesn’t have a main() function. It may in a little while, since I’m pretty close to making bitcoind build w/o wxBase. (it’ll be in init.cpp)

Sorry about my choice of the filename “main.cpp”, another possible name would have been “core.cpp”. It’s much too late to change. I still prefer main.cpp.

We’re still in great need of sample code showing the recommended way to use the JSON-RPC functions, like for a basic account system on a typical storefront website. Using getreceivedbylabel using the username as the label, changing to a new bitcoin address once the stored one for that account gets used. I posted a sample code fragment on the forum somewhere. (search on getreceivedbylabel or getnewaddress) The sample code could be a plain vanilla bank site where you can deposit and send payments.

## 2010-07-16 17:26:17 UTC - Re: 0.3.1 release candidate, please test #

BitcoinTalk

Re: 0.3.1 release candidate, please test

2010-07-16 17:26:17 UTC - Original Post

Good point. If you’re going to have more than 8 LAN nodes connect to one gateway node, then you’d better have the gateway node set up so it can receive incoming connections. Otherwise, while the gateway node has 8 or more connections, it will not try to add any more outbound connections. As the outside nodes you’re connected to come and go, it doesn’t make new outbound connections to replace them. You’ll be fine if you can accept incoming connections, then there will be plenty of others connecting to you.

## 2010-07-16 17:29:28 UTC - Re: Proof-of-work difficulty increasing #

Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That’s the normal length of time before you can spend it. You know long before that that you won one.

## 2010-07-16 17:47:05 UTC - Re: bitcoin trademark? #

https://bitcointalk.org/index.php?topic=378.msg3540#msg3540 No, not related at all.

## 2010-07-16 17:58:44 UTC - Re: The dollar cost of bitmining energy #

BitcoinTalk

Re: The dollar cost of bitmining energy

2010-07-16 17:58:44 UTC - Original Post

Neat chart.

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.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. 1. Upgrade to 0.3.10. 2. 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. ## 2010-08-15 23:17:24 UTC - Re: overflow bug SERIOUS # Quote from: knightmb on August 15, 2010, 10:59:04 PM  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. 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. ## 2010-08-15 23:36:10 UTC - Re: overflow bug SERIOUS # 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.zip 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 ## 2010-08-15 23:37:07 UTC - Re: overflow bug SERIOUS # Quote from: Joozero on August 15, 2010, 11:32:43 PM I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0 There must be a label on the client that show a warning message if needed 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 ## 2010-08-15 23:48:22 UTC - Version 0.3.10 - block 74638 overflow PATCH! # BitcoinTalk Version 0.3.10 - block 74638 overflow PATCH! 2010-08-15 23:48:22 UTC - Original Post Version 0.3.10 patches the block 74638 overflow bug. 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/ 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. ## 2010-08-16 00:28:28 UTC - Re: 0.3.10.1 Question on where block should be # BitcoinTalk Re: 0.3.10.1 Question on where block should be 2010-08-16 00:28:28 UTC - Original Post 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. ## 2010-08-16 00:37:20 UTC - Re: 0.3.10.1 Question on where block should be # BitcoinTalk Re: 0.3.10.1 Question on where block should be 2010-08-16 00:37:20 UTC - Original Post 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. ## 2010-08-16 01:00:45 UTC - Re: overflow bug SERIOUS # Quote from: Ground Loop on August 16, 2010, 12:29:55 AM 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. ## 2010-08-16 01:02:24 UTC - Re: overflow bug SERIOUS # Quote from: kosovito on August 16, 2010, 12:39:17 AM 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 ## 2010-08-16 01:12:05 UTC - Re: overflow bug SERIOUS # Quote from: trebronics on August 16, 2010, 01:02:35 AM 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. ## 2010-08-16 02:16:10 UTC - Re: overflow bug SERIOUS # 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. ## 2010-08-16 02:38:21 UTC - Re: overflow bug SERIOUS # 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 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. ## 2010-08-16 02:57:57 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 2010-08-16 02:57:57 UTC - Original Post Quote from: tcatm on August 16, 2010, 12:43:39 AM 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 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? ## 2010-08-16 03:23:04 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 2010-08-16 03:23:04 UTC - Original Post Quote from: Vasiliev on August 16, 2010, 03:17:07 AM 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. ## 2010-08-16 04:36:59 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 2010-08-16 04:36:59 UTC - Original Post 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. ## 2010-08-16 12:59:38 UTC - Re: overflow bug SERIOUS # 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! ## 2010-08-16 13:38:01 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 2010-08-16 13:38:01 UTC - Original Post I wrapped sha256.cpp in #ifdef FOURWAYSSE2 #endif // FOURWAYSSE2 try it now. ## 2010-08-16 15:25:54 UTC - Re: [PATCH] Automatic block validation # BitcoinTalk Re: [PATCH] Automatic block validation 2010-08-16 15:25:54 UTC - Original Post 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 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; } ## 2010-08-16 15:59:25 UTC - blocks minus 1 # Original Post 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: davidonpda on August 15, 2010, 11:31:37 PM … It already is on block 74638. I assume that means that block is now a good one? Quote from: kencausey on August 15, 2010, 11:45:26 PM 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. ## 2010-08-16 17:06:27 UTC - Re: blocks minus 1 # https://bitcointalk.org/index.php?topic=837.msg9774#msg9774 Done in SVN rev 137 ## 2010-08-16 17:08:02 UTC - Re: [PATCH] Automatic block validation # BitcoinTalk Re: [PATCH] Automatic block validation 2010-08-16 17:08:02 UTC - Original Post Quote from: satoshi on August 16, 2010, 03:25:54 PM 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. ## 2010-08-16 20:07:46 UTC - Checking the block chain on load # BitcoinTalk Re: checkpointing the block chain 2010-08-16 20:20:53 UTC - Original Post 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. ## 2010-08-16 22:54:55 UTC - Re: overflow bug SERIOUS # 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. ## 2010-08-16 23:01:48 UTC - Re: checkpointing the block chain # 2010-08-16 23:01:48 UTC - Original Post Quote from: NewLibertyStandard on August 16, 2010, 10:42:28 PM How is the strength of the chain calculated? Total proof-of-work. ## 2010-08-18 16:58:44 UTC - Re: New screenshots to the front page? # BitcoinTalk Re: New screenshots to the front page? 2010-08-18 16:58:44 UTC - Original Post 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. ## 2010-08-18 18:01:40 UTC - Re: Difficulty: More nodes active, or faster nodes? # BitcoinTalk Re: Difficulty: More nodes active, or faster nodes? 2010-08-18 18:01:40 UTC - Original Post 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. ## 2010-08-18 18:28:28 UTC - Re: Checking the block chain on load # BitcoinTalk Re: Checking the block chain on load 2010-08-18 18:28:28 UTC - Original Post 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. ## 2010-08-19 18:44:36 UTC - Re: Convert Bitcoin to GTK: Yes? No? wx is better? # BitcoinTalk Re: Convert Bitcoin to GTK: Yes? No? wx is better? 2010-08-19 18:44:36 UTC - Original Post Quote from: BioMike on August 19, 2010, 08:05:18 AM 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. ## 2010-08-19 18:55:48 UTC - Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic) # BitcoinTalk Re: HOWTO: Compiling Bitcoin on Ubuntu 10.04 (Karmic) 2010-08-19 18:55:48 UTC - Original Post That’s a really well written walkthough. Someone should confirm if they followed it and didn’t run into any snags. ## 2010-08-19 19:07:43 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 2010-08-19 19:07:43 UTC - Original Post Quote from: Ground Loop on August 18, 2010, 11:14:26 PM 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 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. ## 2010-08-19 19:40:30 UTC - Re: 28 days without generation, i have 4200khash/s # BitcoinTalk Re: 28 days without generation, i have 4200khash/s 2010-08-19 19:40:30 UTC - Original Post Make sure your computer’s date and time are correct. ## 2010-08-19 20:14:01 UTC - Need a post writing up some things users should know # BitcoinTalk Need a post writing up some things users should know 2010-08-19 20:14:01 UTC - Original Post 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. ## 2010-08-19 20:28:50 UTC - Re: Hypothetical question on lost coins / transfers # BitcoinTalk Re: Hypothetical question on lost coins / transfers 2010-08-19 20:28:50 UTC - Original Post 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. ## 2010-08-22 22:51:00 UTC - Re: Need a post writing up some things users should know # BitcoinTalk Re: Need a post writing up some things users should know 2010-08-22 22:51:00 UTC - Original Post 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. ## 2010-08-22 23:01:02 UTC - Re: 28 days without generation, i have 4200khash/s # BitcoinTalk Re: 28 days without generation, i have 4200khash/s 2010-08-22 23:01:02 UTC - Original Post 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 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. ## 2010-08-22 23:21:50 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 2010-08-22 23:21:50 UTC - Original Post 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. ## 2010-08-22 23:55:06 UTC - Development of alert system # 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 ## 2010-08-22 23:57:32 UTC - Re: integrating digital payments into p2p protocols # BitcoinTalk Re: integrating digital payments into p2p protocols 2010-08-22 23:57:32 UTC - Original Post 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. ## 2010-08-24 22:43:56 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 # BitcoinTalk Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 2010-08-24 22:43:56 UTC - Original Post Quote from: ArtForz on August 21, 2010, 04:56:31 PM • 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. ## 2010-08-24 23:51:12 UTC - Re: Development of alert system # BitcoinTalk Re: Development of alert system 2010-08-24 23:51:12 UTC - Original Post 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. ## 2010-08-25 00:06:36 UTC - Re: Development of alert system # BitcoinTalk Re: Development of alert system 2010-08-25 00:06:36 UTC - Original Post This is in SVN rev 142 as version 0.3.11. ## 2010-08-25 15:17:37 UTC - Re: Development of alert system # BitcoinTalk Re: Development of alert system 2010-08-25 15:17:37 UTC - Original Post 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. ## 2010-08-25 16:40:20 UTC - Re: Development of alert system # https://bitcointalk.org/index.php?topic=898.msg11151#msg11151 I changed the switch name to -disablesafemode. ## 2010-08-25 16:56:15 UTC - Re: Development of alert system # BitcoinTalk Re: Development of alert system 2010-08-25 16:56:15 UTC - Original Post Quote from: BioMike on August 23, 2010, 05:15:43 AM @mizerydearia, I think the quote button is easier to find then the reply one. So, theoretical this is a first control system where 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 get? Quote from: jimbobway on August 25, 2010, 04:45:22 PM 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 So, theoretical this is a first control system where 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”. ## 2010-08-25 17:59:30 UTC - Re: Development of alert system # BitcoinTalk Re: Development of alert system 2010-08-25 17:59:30 UTC - Original Post Quote from: nelisky on August 25, 2010, 01:28:32 AM 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 I just discovered 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. ## 2010-08-26 00:08:12 UTC - Re: Development of alert system # Original Post Quote from: BioMike on August 23, 2010, 05:15:43 AM So, theoretical this is a first control system where 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 get? Quote from: satoshi on August 25, 2010, 04:56:15 PM 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”. Quote from: BioMike on August 23, 2010, 06:23:45 PM I’ve never objected this change/idea, just asking if this was possible and to what extent. What’s wrong with getting informed? My apologies, your post was indeed a question not a statement. ## 2010-08-26 00:33:28 UTC - Re: RFC: remove DB_PRIVATE flag # BitcoinTalk Re: RFC: remove DB_PRIVATE flag 2010-08-26 00:33:28 UTC - Original Post 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. ## 2010-08-26 00:44:05 UTC - Re: Need a post writing up some things users should know # BitcoinTalk Re: Need a post writing up some things users should know 2010-08-26 00:44:05 UTC - Original Post 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. ## 2010-08-26 00:57:40 UTC - Re: auto backing up of wallet.dat # BitcoinTalk Re: auto backing up of wallet.dat 2010-08-26 00:57:40 UTC - Original Post 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 ## 2010-08-27 00:49:43 UTC - Re: Gentoo Linux Ebuild # 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.

## 2010-08-27 01:13:42 UTC - Re: auto backing up of wallet.dat #

BitcoinTalk

Re: auto backing up of wallet.dat

2010-08-27 01:13:42 UTC - Original Post

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

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.

## 2010-08-27 02:54:07 UTC - Re: auto backing up of wallet.dat #

BitcoinTalk

Re: auto backing up of wallet.dat

2010-08-27 02:54:07 UTC - Original Post

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

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.

## 2010-08-27 15:47:57 UTC - Re: auto backing up of wallet.dat #

BitcoinTalk

Re: auto backing up of wallet.dat

2010-08-27 15:47:57 UTC - Original Post

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.

## 2010-08-27 16:13:16 UTC - Re: New web service: obtain dump of bitcoin block NNNN #

BitcoinTalk

Re: New web service: obtain dump of bitcoin block NNNN

2010-08-27 16:13:16 UTC - Original Post

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.

## 2010-08-27 16:39:26 UTC - Re: Bitcoins are most like shares of common stock #

BitcoinTalk

Re: Bitcoins are most like shares of common stock

2010-08-27 16:39:26 UTC - Original Post

Bitcoins have no dividend or potential future dividend, therefore not like a stock.

More like a collectible or commodity.

## 2010-08-27 17:32:07 UTC - Re: Bitcoin does NOT violate Mises’ Regression Theorem #

BitcoinTalk

Re: Bitcoin does NOT violate Mises’ Regression Theorem

2010-08-27 17:32:07 UTC - Original Post

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

2010-08-27 21:54:12 UTC - Original Post

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

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:
getbalance

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.

## 2010-08-28 14:27:15 UTC - Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10 #

BitcoinTalk

Re: tcatm’s 4-way SSE2 for Linux 32/64-bit is in 0.3.10

2010-08-28 14:27:15 UTC - Original Post

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.

## 2010-08-28 14:54:04 UTC - Re: Version 0.3.11 with upgrade alerts #

BitcoinTalk

2010-08-28 14:54:04 UTC - Original Post

Quote from: torservers on August 28, 2010, 01:00:37 PM

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

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.

## 2010-08-29 22:14:36 UTC - Re: Big endian code problems #

BitcoinTalk

Re: Big endian code problems

2010-08-29 22:14:36 UTC - Original Post

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.

## 2010-09-05 23:25:32 UTC - Re: CryptoPP Assertion Error #

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.

## 2010-09-05 23:36:20 UTC - Re: Warning : Check your system ( Help me ) #

BitcoinTalk

Re: Warning : Check your system ( Help me )

2010-09-05 23:36:20 UTC - Original Post

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

1. the user (asking the user to fix the system clock)

I've thought about NTP, but this is more secure.

## 2010-09-06 21:21:21 UTC - Re: HTTP status codes from the JSON-RPC api #

BitcoinTalk

Re: HTTP status codes from the JSON-RPC api

2010-09-06 21:21:21 UTC - Original Post

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 " command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy.

## 2010-09-06 21:41:06 UTC - Re: Warning : Check your system ( Help me ) #

Quote from: satoshi on September 05, 2010, 11:36:20 PM

Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

Quote from: Insti on September 06, 2010, 12:51:37 PM

“Please check that your computer’s date and time are correct. If your clock is wrong Bitcoin will not work properly."

Thanks.

## 2010-09-06 21:45:10 UTC - Re: auto backing up of wallet.dat #

BitcoinTalk

Re: auto backing up of wallet.dat

2010-09-06 21:45:10 UTC - Original Post

rpc backupwallet is in SVN rev 147.

## 2010-09-06 21:52:45 UTC - Re: bitcoind as daemon in OSX #

BitcoinTalk

Re: bitcoind as daemon in OSX

2010-09-06 21:52:45 UTC - Original Post

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.

## 2010-09-07 16:32:21 UTC - Re: Always pay transaction fee? #

BitcoinTalk

Re: Always pay transaction fee?

2010-09-07 16:32:21 UTC - Original Post

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.

## 2010-09-07 19:17:55 UTC - Version 0.3.12 #

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":,"message":}, which is the standard. See this thread:

## 2010-09-08 17:30:14 UTC - Re: Always pay transaction fee? #

BitcoinTalk

Re: Always pay transaction fee?

2010-09-08 17:30:14 UTC - Original Post

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.

## 2010-09-08 18:06:04 UTC - Re: Version 0.3.12 #

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.

## 2010-09-08 20:27:39 UTC - Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins? #

BitcoinTalk

Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?

2010-09-08 20:27:39 UTC - Original Post

Quote from: BitLex on September 07, 2010, 08:10:54 PM

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

## 2010-09-09 01:04:05 UTC - Auto-detect for 128-bit 4-way SSE2 #

BitcoinTalk

Auto-detect for 128-bit 4-way SSE2

2010-09-09 01:04:05 UTC - Original Post

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.

## 2010-09-10 00:23:24 UTC - Re: Won’t let me send coins because it requires a transaction fee? #

BitcoinTalk

Re: Won’t let me send coins because it requires a transaction fee?

2010-09-10 00:23:24 UTC - Original Post

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.

## 2010-09-10 00:46:37 UTC - Re: Won’t let me send coins because it requires a transaction fee? #

BitcoinTalk

Re: Won’t let me send coins because it requires a transaction fee?

2010-09-10 00:46:37 UTC - Original Post

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.

## 2010-09-10 17:12:33 UTC - Re: Won’t let me send coins because it requires a transaction fee? #

BitcoinTalk

Re: Won’t let me send coins because it requires a transaction fee?

2010-09-10 17:12:33 UTC - Original Post

The fix is in SVN rev 151.

You will be able to send your stuck 0.01 (actually 0.01000010) when you next upgrade.

## 2010-09-10 18:11:06 UTC - Re: Auto-detect for 128-bit 4-way SSE2 #

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.

## 2010-09-12 17:40:20 UTC - Re: Running on a port other than 8333 #

BitcoinTalk

Re: Running on a port other than 8333

2010-09-12 17:40:20 UTC - Original Post

Quote from: lachesis on August 10, 2010, 03:24:55 PM

Also, does Bitcoin open the BerkeleyDB as exclusive, precluding the need for a file lock? 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.

## 2010-09-12 18:00:39 UTC - Re: RFC: remove DB_PRIVATE flag #

BitcoinTalk

Re: RFC: remove DB_PRIVATE flag

2010-09-12 18:00:39 UTC - Original Post

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.

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.

## 2010-09-12 19:24:53 UTC - Re: Switch to GPL #

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.

## 2010-09-19 17:22:03 UTC - Re: Memory leak #

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)
{
}

If that doesn’t work right, then it would be possible for it to spin through the loop as fast as it can.

## 2010-09-19 18:46:46 UTC - Re: Issues building bitcoin on Windows 7 #

BitcoinTalk

Re: Issues building bitcoin on Windows 7

2010-09-19 18:46:46 UTC - Original Post

The lines it’s tripping on:

Code:

ERROR extern vector 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.

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.

## 2010-09-19 19:58:11 UTC - Re: Bug? /usr/bin/bitcoind "” #

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.

## 2010-09-19 21:49:30 UTC - Re: The case for removing IP transactions #

BitcoinTalk

Re: The case for removing IP transactions

2010-09-19 21:49:30 UTC - Original Post

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.

## 2010-09-19 22:47:00 UTC - Re: Message Encryption as a built-in feature? #

BitcoinTalk

Re: Message Encryption as a built-in feature?

2010-09-19 22:47:00 UTC - Original Post

Theymos already said this… ECDSA does not support encrypting messages. Only digital signatures.

## 2010-09-23 16:08:35 UTC - Re: Always pay transaction fee? #

BitcoinTalk

Re: Always pay transaction fee?

2010-09-23 16:08:35 UTC - Original Post

Quote from: satoshi on September 08, 2010, 05:30:14 PM

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.

## 2010-09-23 16:19:08 UTC - Internal version number #

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.

## 2010-09-23 16:28:25 UTC - Re: Warning : Check your system ( Help me ) #

BitcoinTalk

Re: Warning : Check your system ( Help me )

2010-09-23 16:28:25 UTC - Original Post

I don’t understand, are you under the impression that the program sets the system clock? It doesn’t.

Quote from: Cdecker on September 19, 2010, 08:14:08 PM

We already have ways to synchronize (approximately) the clients, so why not make use of that?

We use an internal offset based on the median of other nodes’ times, but for security reasons we don’t let them offset us by more than an hour. If they indicate we’re off by more than an hour, then we resort to alerting the user to fix their clock.

## 2010-09-23 17:56:55 UTC - Re: Porn #

Bitcoin would be convenient for people who don’t have a credit card or don’t want to use the cards they have, either don’t want the spouse to see it on the bill or don’t trust giving their number to “porn guys”, or afraid of recurring billing.

## 2010-09-23 18:39:56 UTC - Re: How divisible are bitcoins - the technical side #

BitcoinTalk

Re: How divisible are bitcoins - the technical side

2010-09-23 18:39:56 UTC - Original Post

I would not encourage using the extra decimal places. They’re only intended for future use.

You are correct that above 0.01 can still have additional precision, but the recipient won’t be able to see it. The UI will show it rounded down.

## 2010-09-23 18:46:20 UTC - Re: Internal version number #

I don’t think it should cause any problems for version comparisons. 31300 > 312.

## 2010-09-26 17:34:26 UTC - Re: How To Make a Distributed BitCoin Escrow Service #

BitcoinTalk

Re: How To Make a Distributed BitCoin Escrow Service

2010-09-26 17:34:26 UTC - Original Post

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

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.

## 2010-09-30 16:38:53 UTC - Re: I broke my wallet, sends never confirm now. #

BitcoinTalk

Re: I broke my wallet, sends never confirm now.

2010-09-30 16:38:53 UTC - Original Post

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;

## 2010-09-30 16:59:00 UTC - Re: I broke my wallet, sends never confirm now. #

https://bitcointalk.org/index.php?topic=1306.msg14720#msg14720

Re: I broke my wallet, sends never confirm now.

## 2010-09-30 17:04:15 UTC - 0.3.13 RC1 for Windows, please test #

BitcoinTalk

0.3.13 RC1 for Windows, please test

2010-09-30 17:04:15 UTC - Original Post

0.3.13 release candidate, to be released soon so please test:

• 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

BitcoinTalk

2010-09-30 17:50:32 UTC - Original Post

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:

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.

## 2010-09-30 18:11:56 UTC - Re: Prioritized transactions, and tx fees #

BitcoinTalk

Re: Prioritized transactions, and tx fees

2010-09-30 18:11:56 UTC - Original Post

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.

## 2010-09-30 18:22:22 UTC - Re: Prioritized transactions, and tx fees #

BitcoinTalk

Re: Prioritized transactions, and tx fees

2010-09-30 18:22:22 UTC - Original Post

True, the switch should be something more dynamic that pays per KB. It’s harder to think of how to explain it.

## 2010-09-30 18:27:41 UTC - Re: Remote RPC access #

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:

## 2010-10-01 00:32:46 UTC - Re: 0.3.13 RC1 for Windows, please test #

BitcoinTalk

Re: 0.3.13 RC1 for Windows, please test

2010-10-01 00:32:46 UTC - Original Post

Too late for 0.3.13, but I’ll try to find time to add it to the next version.

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.

(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:

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:

## 2010-10-03 18:17:06 UTC - Re: Version 0.3.13 #

Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM

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

2010-10-03 19:39:06 UTC - Original Post

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.

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.

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

## 2010-10-03 21:07:28 UTC - Re: [PATCH] increase block size limit #

BitcoinTalk

Re: [PATCH] increase block size limit

2010-10-03 21:07:28 UTC - Original Post

Quote from: theymos on October 03, 2010, 08:28:39 PM

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.

BitcoinTalk

2010-10-03 21:43:20 UTC - Original Post

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.

BitcoinTalk

2010-10-03 20:54:07 UTC - Original Post

Quote from: theymos on October 03, 2010, 08:09:51 PM

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

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

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.

## 2010-10-03 21:30:04 UTC - Re: How to overthrow the GPU Oligarchs #

BitcoinTalk

Re: How to overthrow the GPU Oligarchs

2010-10-03 21:30:04 UTC - Original Post

Quote from: lzsaver on October 02, 2010, 05:49:47 AM

Can you tell more about it:
“they have to do weird things with extraNonce, which increases the size of the block header”.

Quote from: theymos on October 02, 2010, 06:11:11 AM

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.

## 2010-10-03 22:07:00 UTC - Re: Memory leak #

You’re connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.

IRC seems to be working. It ought to have other nodes to try.

There may be something I need to do to make sure it doesn’t try to connect to itself again right away after disconnecting. I can’t see how it’s happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn’t show it.

You can try moving addr.dat aside. Maybe there’s something wrong in it.

BitcoinTalk

2010-10-03 23:46:19 UTC - Original Post

Make sure you keep your node online so it’ll keep rebroadcasting transaction b412a0. It haven’t seen it rebroadcast since 29/09/2010 16:41.

## 2010-10-04 01:44:41 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-10-04 01:44:41 UTC - Original Post

Thanks eurekafag, Russian translation added to SVN rev 160.

## 2010-10-04 19:21:01 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-10-04 19:21:01 UTC - Original Post

Quote from: eurekafag on October 04, 2010, 10:55:56 AM

Where can I find the latest English .po file to keep the translation up-to-date?

poedit does it. Either get the src directory from a release, or download it with SVN. Place your .po file 3 directories deep under the src directory. Open it with poedit and do Catalog->Update from sources.

So for example, you have:
src
srcase58.h
srcignum.h

src\util.cpp
src\util.h
src\xpm
src\localeu\LC_MESSAGESitcoin.po

Open bitcoin.po with poedit, do Catalog->Update from sources. It looks for the sourcecode up 3 directories (..\..\..) from where bitcoin.po is.

This updates your existing .po file you already worked on and adds any news strings. It may try to match close strings, so check things over and make sure it didn’t make any bad guesses.

Make sure you use the .po file I uploaded to SVN or in a release, because I always fix up at least a few things. I’m attaching your Russian one to this message.

## 2010-10-04 19:48:40 UTC - Re: [PATCH] increase block size limit #

BitcoinTalk

Re: [PATCH] increase block size limit

2010-10-04 19:48:40 UTC - Original Post

It can be phased in, like:

if (blocknumber > 115000)
maxblocksize = largerlimit

It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don’t have it are already obsolete.

When we’re near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade.

## 2010-10-06 15:42:39 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-10-06 15:42:39 UTC - Original Post

poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it’s fine now. Did you run it on a drive where files aren’t sorted alphabetically, like a FAT drive or USB flash drive?

Strings aren’t added or changed very often. It’s months before enough changes build up.

This Windows build has the Russian translation in it:

## 2010-10-06 16:54:23 UTC - Re: I broke my wallet, sends never confirm now. #

BitcoinTalk

Re: I broke my wallet, sends never confirm now.

2010-10-06 16:54:23 UTC - Original Post

That’s going to be more of a SelectCoins thing.

SVN rev 161 has a refinement to recursively determine if your own unconfirmed transactions can be spent. This is needed because you should be able to spend your own change right away.

The new recursive determination is: 0/unconfirmed can be spent if it’s yours and all its dependencies are either in a block or also yours.

Here’s a Windows build:

This version is an improvement if you already had a 0/unconfirmed transaction and might have already spent it. If you were the original creator of a 0/unconfirmed transaction, you still need theymos’ patch instead.

## 2010-10-06 17:36:41 UTC - Re: Tor connections not working reliably, many seednodes offline #

BitcoinTalk

Re: Tor connections not working reliably, many seednodes offline

2010-10-06 17:36:41 UTC - Original Post

Maybe you were just unlucky to have an exit node without reverse lookup.

The IRC server’s response doesn’t look like it was disconnecting you for that. It’s supposed to go IRC SENDING: NICK after that, and it doesn’t so it gets timed out.

I see the problem. The IRC code is looking for various phrases to see when the server is ready to receive your NICK, but it’s not looking for that particular phrase. I’ll fix it.

I don’t know if it’s really required to wait for the server to finish looking up hostname before sending nick.

How long did it take to get connected with TOR the first time, having to use the seed nodes?

## 2010-10-06 23:10:31 UTC - Re: The Niche List #

Original Post

Quote from: kiba on September 23, 2010, 04:00:16 PM

1. Download site like rapidshare and other crappy host. Inconvenient captcha and required paypal. Bitcoin can possibly take both roles and streamline the whole process.

Repeating myself here, but there is open source software for that, so it would just be a matter of bolting on a Bitcoin payment mechanism. One good one I found was Mihalism Multi Host. It’s designed as a free host, so it would just need a few tweaks to loosen up restrictions consistent with paid use.

## 2010-10-09 20:19:33 UTC - Key pool feature for safer wallet backup #

BitcoinTalk

Key pool feature for safer wallet backup

2010-10-09 20:19:33 UTC - Original Post

SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated new keys are aged in a queue before use, so that backups of wallet.dat hold keys you’ll use in the future.

For now I made the default pool size 100. It can be configured with -keypool=. Be aware, it takes a little time to increase the pool size, so don’t go crazy with it. Disk space is about 1K per key.

I have not addressed the recovery side of this yet. If you actually did restore an old wallet.dat, I think you may have to delete blk*.dat to rediscover your own transactions during the redownload.

I’ve only tested this moderately. You might not want to use this for a website server until it’s had some more testing.

## 2010-10-21 16:39:27 UTC - Version 0.3.14 #

Version 0.3.14 is now available
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/

Changes:

• Key pool feature for safer wallet backup

Gavin Andresen:

• TEST network mode with switch -testnet
• Option to use SSL for JSON-RPC connections on unix/osx

eurekafag:

• Russian translation

## 2010-10-21 22:50:47 UTC - Re: Website and software translations #

BitcoinTalk

Re: Website and software translations

2010-10-21 22:50:47 UTC - Original Post

The order matters not to the program, but it matters to me maintaining it. If it jumbles the order of the .po file then I can’t diff for changes. I have to update all 7 translation files when I change the English text in the program, and it’s easier when they’re all in the same order.

I can still put it back into normal order by making poedit rescan it.

It is normal that untranslated strings are shown on top.

Quote from: eurekafag on October 06, 2010, 07:39:36 PM

By the way, there are some similar lines that possibly may be replaced by one. They are very close by meaning and differs only by 1-2 words. Just a suggestion of course.

I know, but not easily without complicating the sourcecode.

BitcoinTalk

2010-10-23 18:22:49 UTC - Original Post

Quote from: theymos on October 21, 2010, 10:00:26 PM

his block count remains “stuck” at 1698.

He was generating invalid blocks at difficulty 1.0. He must have a corrupted entry in his blk0001.dat or blkindex.dat file. He just needs to delete blk*.dat and let it redownload.

The safety lockdown detected the problem and was displaying “WARNING: Displayed transactions may not be correct!” because it saw a longer chain existed that it was unable to accept. The safety lockdown cannot stop generation or it would create an attack possibility.

Quote from: gavinandresen on October 22, 2010, 02:25:14 PM

The Bitcoin client really shouldn’t allow coin generation until you have all of the blocks up to the last block checkpoint.

Good idea, I made a change to make sure it won’t generate before checkpoint block 74000.

BitcoinTalk

2010-10-23 18:38:04 UTC - Original Post

OK, if it really won’t get past block 1698 on redownload, then we’re in stranger territory.

Yes, possibly he has antivirus software or even a router or filewall that is pattern matching a sequence of bytes and censoring it.

It would be instructive to get knightmb’s blk*.dat and see if that gets him past that point.

## 2010-10-23 18:52:02 UTC - Re: Win7 64bit since last patch Tues now crashes #

BitcoinTalk

Re: Win7 64bit since last patch Tues now crashes

2010-10-23 18:52:02 UTC - Original Post

Quote from: Odin on October 22, 2010, 09:24:38 PM

Fault Module Name: mingwm10.dll

This is the important clue. I believe it’s saying it crashed in that. Maybe there are other versions of it to try. mingwm10.dll is just a simple placeholder thing that satisfies some callback requirement for multithreaded apps.

Is anyone else running OK on Windows 64-bit?

## 2010-10-23 19:02:57 UTC - Re: Suggestion: Allow short messages to be sent together with bitcoins ? #

BitcoinTalk

Re: Suggestion: Allow short messages to be sent together with bitcoins ?

2010-10-23 19:02:57 UTC - Original Post

ECDSA can’t encrypt messages, only sign signatures.

It would be unwise to have permanently recorded plaintext messages for everyone to see. It would be an accident waiting to happen.

If there’s going to be a message system, it should be a separate system parallel to the bitcoin network. Messages should not be recorded in the block chain. The messages could be signed with the bitcoin address keypairs to prove who they’re from.

## 2010-10-24 19:17:51 UTC - Re: Multiple Wallets, one computer #

BitcoinTalk

Re: Multiple Wallets, one computer

2010-10-24 19:17:51 UTC - Original Post

I have the beginning of something like this. It’s mostly like what Gavin described.

Some more rpc interface:

move
Move from one internal account to another. I think blank account name (””) will be your default account. If you sell something to a user, you could do move “theiraccount” "" 123.45.
Is “move” the best name for this? I shied away from “transfer” because that sounds too close to sending a transaction.

Gives you an address allocated from getnewaddress . It’ll keep giving the same address until something is received on the address, then it allocates a new address. (It automatically does what the sample code I posted some time ago did)

Would these commands make it possible in simple cases to implement your website without needing a database of your own?

## 2010-10-25 16:53:53 UTC - Re: Multiple Wallets, one computer #

BitcoinTalk

Re: Multiple Wallets, one computer

2010-10-25 16:53:53 UTC - Original Post

Here’s some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.

print “balance: " + getbalance(username, 0)
print “available balance: " + getbalance(username, 6)

// if you make a sale, move the money out of their account

// withdrawal

## 2010-10-25 17:27:47 UTC - Re: Win7 64bit since last patch Tues now crashes #

BitcoinTalk

Re: Win7 64bit since last patch Tues now crashes

2010-10-25 17:27:47 UTC - Original Post

The only thing I can think of is to see if there are other versions of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came with the MinGW compiler that you need when you build for multi-thread. I don’t know exactly what it does, but it probably just says something like “yes Windows, see I’m in a DLL like you insisted."

The end of your debug.log file might show the last thing it was doing before it crashed.

I’m happy if someone with artistic skill wants to contribute alternatives. The icon/logo was meant to be good as an icon at the 16x16 and 20x20 pixel sizes. I think it’s the best program icon, but there’s room for improvement at larger sizes for a graphic for use on websites.

It’ll be a lot simpler if authors could make their graphics public domain.

## 2010-11-13 23:25:26 UTC - Re: Some testing that I did on the testnetwork, my findings. #

BitcoinTalk

Re: Some testing that I did on the testnetwork, my findings.

2010-11-13 23:25:26 UTC - Original Post

Thank you for limiting flood tests to the testnet.

Version 0.3.15 combines several features to help legitimate transactions jump the queue during a flood attack. The key was Gavin’s idea for prioritising transactions based on the age of their dependencies. Every coin is entitled to turn over so often. The longer waited, the more priority accumulates. Priority is sum(valuein * age) / txsize. Transaction fee still takes precedence over priority, and priority determines the order of processing within a fee strata.

In support of the priority feature, SelectCoins only uses your own 0 conf transactions only as a last resort if that’s all you have left. This helps keep you from turning your coins over rapidly unless you’re forcing it by actually turning all your coins over rapidly.

## 2010-11-13 23:26:40 UTC - Version 0.3.15 #

Version 0.3.15 is now available.

Changes:

• paytxfee switch is now per KB, so it adds the correct fee for large transactions
• sending avoids using coins with less than 6 confirmations if it can
• BitcoinMiner processes transactions in priority order based on age of dependencies
• bugfixes by Dean Gores
• testnet, keypoololdest and paytxfee added to getinfo

## 2010-11-14 16:53:19 UTC - Re: Some testing that I did on the testnetwork, my findings. #

BitcoinTalk

Re: Some testing that I did on the testnetwork, my findings.

2010-11-14 16:53:19 UTC - Original Post

Quote from: ByteCoin on November 13, 2010, 11:55:11 PM

Of course, if the network is not being flooded and you’re not overly concerned about the current transaction getting held up then it’s probably worth preferring to use your 0 conf transactions so that you can “save” the higher priority coins for when the network is being flooded.

You should use at least some priority in case a flood comes along before the next block.

As long as all dependencies have at least 1 conf, if the transaction doesn’t have enough priority at first, the dependencies will age until it does.

Quote

Gaming the system by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!

Or managing how much priority you spend on a transaction. The software would have to know your future plans to know whether to spend your priority now or save it for later. I don’t think we’ll need to get into that much detail though. There’s a wide enough difference between normal users and flooders.

Priority doesn’t have to do everything. Once you know there’s a flood, you can add -paytxfee=0.01. Hopefully with priority, your transactions before that should be at worst slow, not stuck.

## 2010-11-15 18:37:44 UTC - Re: Need OP_BLOCKNUMBER to allow “time” limited transactions #

BitcoinTalk

Re: Need OP_BLOCKNUMBER to allow “time” limited transactions

2010-11-15 18:37:44 UTC - Original Post

We can’t safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn’t be fair to later owners of the coins who weren’t involved in the time limited transaction.

nTimeLock does the reverse. It’s an open transaction that can be replaced with new versions until the deadline. It can’t be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn’t enabled or used yet, but the support is there so it could be implemented later.

## 2010-11-19 23:50:24 UTC - Re: Transaction / spam flood attack currently under way #

BitcoinTalk

Re: Transaction / spam flood attack currently under way

2010-11-19 23:50:24 UTC - Original Post

Quote from: creighto on November 19, 2010, 08:29:12 PM

Perhaps in addition to the age priority rule recently implimented, there should be a minimum age rule without a transaction fee. Said another way, perhaps a generation rule that says that a free transaction must be 3 blocks deep before it can be transfered again for free. This will still allow real users to immediately spend new funds if they have to, while still permitting real users to reshuffle funds to suit their needs without an overhead cost. I think that this would significantly inhibit the type of spamming attack that is currently underway.

I’m doing something like that. Priority is a more formalised version of the concept you’re describing.

Quote from: FreeMoney on November 19, 2010, 05:39:44 PM

As it stands now 3.15 has a lot of free transaction space and that space is given first to transactions with the highest [age]*[value]/[size] correct? Would it be reasonable to make some arbitrary portion of the free space require [age]*[value]/[size] > C ?

Maybe set C so that a standard 1BTC transaction can get into the main free area on the next block. And a .1 can get in after waiting about 10 blocks. And make the area which allows [age]*[value]/[size] < C to let in about a dozen transactions or so.

Yes, like this. And the no-priority-requirement area is 3K, about a dozen transactions per block.

I just uploaded SVN rev 185 which has a minimal priority requirement for free transactions. Transaction floods are made up of coins that are re-spent over and over, so they depend on their own 0 conf transactions repeatedly. 0 conf transactions have 0 priority, so free transactions like that will have to wait for one transaction to get into a block at a time.

Version 0.3.15 doesn’t write transactions using 0 conf dependencies unless that’s all it has left, so normal users shouldn’t usually have a problem with this.

I think this is a good compromise short of making the default fee 0.01. It’s not so much to ask that free transactions can only be used to turn coins over so often. If you’re using free transactions, you’re taking charity and there has to be some limit on how often you can use it with the same coins.

We’ve always said free transactions may be processed more slowly. You can help ensure your transactions go through quickly by adding -paytxfee=0.01.

## 2010-11-20 17:24:20 UTC - Re: OpenCL miner for the masses #

BitcoinTalk

Re: OpenCL miner for the masses

2010-11-20 17:24:20 UTC - Original Post

Quote from: m0mchil on November 20, 2010, 10:16:19 AM

updated to SVN 186

Thanks m0mchil for keeping up on the updates!

GPU miners, please upgrade as soon as possible to shut down the free transaction abuse! This version has the new priority-based limit on free transaction spam.

Quote from: m0mchil on November 16, 2010, 10:30:41 AM

Just updated to SVN 181 and fixed getwork patch to wait 60 seconds between rebuilding the block with new transactions. This is actually the behavior of the original client, was forgotten in the patch by mistake. Fixes heavy CPU usage on every getwork request (this became obvious with recent heavy transaction spam). Please upgrade.

Before SVN 184, compiling transactions into a block used an n^2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100 times quicker)

## 2010-11-23 19:50:12 UTC - New getwork #

I uploaded a redesign of m0mchil’s getwork to SVN rev 189 (version 31601)

m0mchil’s external bitcoin miner idea has solved a lot of problems. GPU programming is immature and hard to compile, and I didn’t want to add additional dependencies to the build. getwork allows these problems to be solved separately, with different programs for different hardware and OSes. It’s also convenient that server farms can run a single Bitcoin node and the rest only run getwork clients.

The interface has a few changes:

getwork [data]
If [data] is not specified, returns formatted hash data to work on:
“midstate” : precomputed hash state after hashing the first half of the data
“data” : block data
“hash1” : formatted hash buffer for second hash
“target” : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful. [data] is the same 128 byte block data that was returned in the “data” field, but with the nonce changed.

Notes:

• It does not return work when you submit a possible hit, only when called without parameter.
• The block field has been separated into data and hash1.
• data is 128 bytes, which includes the first half that’s already hashed by midstate.
• hash1 is always the same, but included for convenience.
• Logging of “ThreadRPCServer method=getwork” is disabled, it would be too much junk in the log.

## 2010-11-23 20:55:27 UTC - Re: New getwork #

It’s not an exact drop-in replacement. I wanted to clean up the interface a little. It only requires a few changes.

ScanHash_ functions aren’t going away. BTW, the interface of this is designed to mirror the parameters of that (midstate, data, hash1).

## 2010-11-24 17:21:01 UTC - Re: New getwork #

Quote from: jgarzik on November 24, 2010, 04:47:42 AM

I suspect something weird going on with ByteReverse (or lack thereof). It’s quite unclear whether or not ‘data’ and ’nonce’ must be byte-reversed, and in what way.

getwork does the byte-reversing. midstate, data and hash1 are already big-endian, and you pass data back still big-endian, so you work in big-endian and don’t have to do any byte-reversing. They’re the same data that is passed to the ScanHash_ functions. You can take midstate, data and hash1, put them in 16-byte aligned buffers and pass them to a ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1, nHashesDone). If a nonce is found, patch it into data and call getwork.

I should probably change the ScanHash_ functions to use pdata instead of pdata + 64 so they’re consistent.

target is little endian, it’s supposed to be the same as how m0mchil’s did it. (if it’s not, then it should be fixed) That’s the only case where you would use byte reverse. I think you do it like: if ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].

Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM

Satoshi, please fix your implementation of getwork so it complies with m0mchill’s specification

This is the new spec. It shouldn’t be hard to update your miner to use it.

The changes are:

• It does not return work when you submit a possible hit, only when called without parameter.
• The block field has been split into data and hash1.
• state renamed to midstate for consistency.
• extranonce not needed.

## 2010-11-24 17:53:09 UTC - Re: OpenCL miner for the masses #

BitcoinTalk

Re: OpenCL miner for the masses

2010-11-24 17:53:09 UTC - Original Post

A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.

## 2010-11-25 17:51:39 UTC - Re: RFC: ship block chain 1-74000 with release tarballs? #

BitcoinTalk

Re: RFC: ship block chain 1-74000 with release tarballs?

2010-11-25 17:51:39 UTC - Original Post

Bandwidthwise, it’s more efficient than if you downloaded an archive. Bitcoin only downloads the data in blk0001.dat, which is currently 55MB, and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is what causes all the disk activity.

During the block download, it only flushes the database to disk every 500 blocks. You may see the block count pause at ??499 and ??999. That’s when it’s flushing.

Doing your own verifying and indexing is the only way to be sure your index data is secure. If you copy blk0001.dat and blkindex.dat from an untrusted source, there’s no way to know if you can trust all the contents in them.

Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.

## 2010-11-25 20:07:36 UTC - Version 0.3.17 #

Version 0.3.17 is now available.

Changes:

• new getwork, thanks m0mchil
• free transaction limits

The UI transaction fee setting was easy since it was still there from 0.1.5 and all I had to do was re-enable it.

The accounts-based commands: move, sendfrom and getbalance will be in the next release. We still have some more changes to make first.

## 2010-11-26 17:32:01 UTC - Re: RFC: ship block chain 1-74000 with release tarballs? #

BitcoinTalk Re: RFC: ship block chain 1-74000 with release tarballs? 2010-11-26 17:32:01 UTC - Original Post I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes.

If it’s taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.

Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that’s how it should work.

Quote from: satoshi on November 25, 2010, 05:51:39 PM

Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.

Quote from: jgarzik on November 26, 2010, 02:07:43 AM

It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can’t assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.

Someone should experiment with different Berkeley DB settings and see if there’s something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.

Quote

Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.

We checkpoint every 500 blocks.

## 2010-11-26 18:23:30 UTC - Re: Version 0.3.17 #

Laszlo does them, but I haven’t asked him to do one for a while because there wasn’t anything major. I’ll ask him to do this version.

## 2010-11-26 21:31:13 UTC - Re: New getwork #

https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708 That’s what it does, it returns true/false.

## 2010-11-26 22:02:41 UTC - Re: New demonstration CPU miner available #

BitcoinTalk

Re: New demonstration CPU miner available

2010-11-26 22:02:41 UTC - Original Post

You should try it with tcatm’s 4-way SSE2 SHA in sha256.cpp. It compiles fine as a C file, just rename sha256.cpp to sha256.c. I was able to get it to work in simple tests on Windows, but not when linked in with Bitcoin. It may have a better chance of working as part of a C program instead of C++.

Currently it’s only enabled in the Linux build, so if you get it to work you could make it available to Windows users. It’s about 100% speedup on AMD CPUs.

## 2010-11-28 16:03:30 UTC - Re: Cooperative mining #

ribuck’s description is spot on.

Pool operators can modify their getwork to take one additional parameter, the address to send your share to.

The easy way for the pool operator would be to wait until the next block is found and divy it up proportionally as:
user’s near-hits/total near-hits from everyone

That would be easier and safer to start up. It also has the advantage that multiple hits from the same user can be combined into one transaction. A lot of your hits will usually be from the same people.

The instant gratification way would be to pay a fixed amount for each near-hit immediately, and the operator takes the risk from randomness of having more or less near-hits before a block is found.

Either way, the user who submits the hit that solves the block should get an extra amount off the top, like 10 BTC.

New users wouldn’t really even need the Bitcoin software. They could download a miner, create an account on mtgox or mybitcoin, enter their deposit address into the miner and point it at anyone’s pool server. When the miner says it found something, a while later a few coins show up in their account.

Miner writers better make sure they never false-positive near-hits. Users will depend on that to check if the pool operator is cheating them. If the miner wrongly says it found something, users will look in their account, not find anything, and get mad at the pool operator.

## 2010-11-28 17:13:01 UTC - Re: RFC: ship block chain 1-74000 with release tarballs? #

BitcoinTalk

Re: RFC: ship block chain 1-74000 with release tarballs?

2010-11-28 17:13:01 UTC - Original Post

Despite everything else said, the current next step is:

Quote

Someone should experiment with different Berkeley DB settings and see if there’s something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.

In particular, I suspect that more read caching might help a lot.

Quote from: jgarzik on November 28, 2010, 02:33:29 AM

Then something more specific was wrong. That’s not due to normal initial download time. Without more details, it can’t be diagnosed. If it was due to slow download, did it speed up after 10-20 minutes when the next block broadcast should have made it switch to a faster source? debug.log might have clues. How fast is their Internet connection? Was it steadily slow, or just slow down at one point?

Quote

We have the hashes for genesis block through block 74000 hardcoded (compiled) into bitcoin, so there’s no reason why we shouldn’t be able to automatically download a compressed zipfile of the block database from anywhere, unpack it, verify it, and start running.

The 74000 checkpoint is not enough to protect you, and does nothing if the download is already past 74000. -checkblocks does more, but is still easily defeated. You still must trust the supplier of the zipfile.

If there was a “verify it” step, that would take as long as the current normal initial download, in which it is the indexing, not the data download, that is the bottleneck.

Quote from: jgarzik on November 28, 2010, 07:33:55 AM

Presumably at some point there will be a lightweight client that only downloads block headers, but there will still be hundreds of thousands of those…

80 bytes per header and no indexing work. Might take 1 minute.

Quote

uncompressed data using a protocol (bitcoin P2P) that wasn’t designed for bulk data transfer.

The data is mostly hashes and keys and signatures that are uncompressible.

The speed of initial download is not a reflection of the bulk data transfer rate of the protocol. The gating factor is the indexing while it downloads.

## 2010-11-28 18:06:39 UTC - Re: Is safe running bitcoins with the same wallet on more computers simultaneously? #

BitcoinTalk

Re: Is safe running bitcoins with the same wallet on more computers simultaneously?

2010-11-28 18:06:39 UTC - Original Post

Quote

Will it be synchronized automatically?

Very much not. Using multiple copies of wallet.dat is not recommended or supported, in fact all of Bitcoin is designed to defeat that. Both copies will get screwed up.

If you’re trying to consolidate your generated coins into one wallet, a better solution now is to run getwork miners on the additional systems. jgarzik has a CPU miner, and it supports tcatm’s 4-way SSE2, so on Windows it’s up to twice as fast as the built-in SHA if you have an AMD or recent Intel (core 3, 5 or 7).

New demonstration CPU miner available:
http://bitcointalk.org/index.php?topic=1925.0

## 2010-11-29 20:19:12 UTC - Re: RFC: ship block chain 1-74000 with release tarballs? #

BitcoinTalk

Re: RFC: ship block chain 1-74000 with release tarballs?

2010-11-29 20:19:12 UTC - Original Post

It seems like you’re inclined to assume everything is wrong more than is actually so.

Writing the block index is light work. Building the tx index is much more random access per block. I suspect reading all the prev txins is what’s slow. Read caching would help that. It’s best if the DB does that. Maybe it has a setting for how much cache memory to use.

Quote

1. bitcoin should be opening databases, not just environment, at program startup, and closing database at program shutdown.

Already does that. See CDB. The lifetime of the (for instance) CTxDB object is only to support database transactions and to know if anything is still using the database at shutdown.

Quote

If it was doing that it would be much slower. It’s supposed to be only once a minute or 500 blocks:

if (strFile = "blkindex.dat" && IsInitialBlockDownload() && nBestHeight % 500 ! 0)
nMinutes = 1;
dbenv.txn_checkpoint(0, nMinutes, 0);

dbenv.txn_checkpoint(0, nMinutes, 0);

Quote

1. For the initial block download, txn commit should occur once every N records, not every record. I suggest N=1000.

Does transaction commit imply flush? That seems surprising to me. I assume a database op wrapped in a transaction would be logged like any other database op. Many database applications need to wrap almost every pair of ops in a transaction, such as moving money from one account to another. (debit a, credit b) I can’t imagine they’re required to batch all their stuff up themselves.

In the following cases, would case 1 flush once and case 2 flush twice?

case 1:
write
write
write
write
checkpoint

case 2:
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint

Contorting our database usage will not be the right approach. It’s going to be BDB settings and caching.

## 2010-11-30 19:02:31 UTC - Re: Incompatible wallet format with latest bitcoin-git ? #

BitcoinTalk

Re: Incompatible wallet format with latest bitcoin-git ?

2010-11-30 19:02:31 UTC - Original Post

What was this wallet used with? An early accounts patch or git build?

It’s while loading the wallet. I assume it must be in this:

else if (strType == “acentry”)
{
string strAccount;
ssKey >> strAccount;
uint64 nNumber;
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}

You could check that with this:

else if (strType == “acentry”)
{
string strAccount;
assert(!ssKey.empty());
ssKey >> strAccount;
uint64 nNumber;
if (ssKey.size() != 8 )
printf(” %s %d “, strAccount.c_str(), ssKey.size());
assert(ssKey.empty() == false);
ssKey >> nNumber;
if (nNumber > nAccountingEntryNumber)
nAccountingEntryNumber = nNumber;
}

Was there an interim version of accounts on git at some point that had just (“acentry”, “account”) for the key?

If you have gdb, you could run it in gdb and do a backtrace.

gdb –args bitcoin …
run
(wait for exception)
bt

## 2010-12-01 21:25:39 UTC - Re: RFC: ship block chain 1-74000 with release tarballs? #

BitcoinTalk

Re: RFC: ship block chain 1-74000 with release tarballs?

2010-12-01 21:25:39 UTC - Original Post

That’s a good optimisation. I’ll add that next time I update SVN.

More generally, we could also consider this:

dbenv.set_lk_max_objects(10000);
dbenv.set_errfile(fopen(strErrorFile.c_str(), “a”)); / debug
dbenv.set_flags(DB_AUTO_COMMIT, 1);

• dbenv.set_flags(DB_TXN_NOSYNC, 1);

DB_CREATE |
DB_INIT_LOCK |
DB_INIT_LOG |

We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.

## 2010-12-05 09:08:08 UTC - Re: Wikileaks contact info? #

Original Post

Quote from: RHorning on December 04, 2010, 10:17:44 PM

Basically, bring it on. Let’s encourage Wikileaks to use Bitcoins and I’m willing to face any risk or fallout from that act.

No, don’t “bring it on”.

The project needs to grow gradually so the software can be strengthened along the way.

I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is a small beta community in its infancy. You would not stand to get more than pocket change, and the heat you would bring would likely destroy us at this stage.

## 2010-12-08 20:21:49 UTC - Re: JSON-RPC method idea: list transactions newer than a given txid #

BitcoinTalk

Re: JSON-RPC method idea: list transactions newer than a given txid

2010-12-08 20:21:49 UTC - Original Post

It’s not safe to use listtransactions this way.

I know I’ve been criticized for being reluctant about listtransactions. Let me explain my reluctance.

Transactions are dynamic. Past transactions can become unconfirmed, go away and come back, become invalid and disappear, or be replaced by a different double-spend. Their date can change, their order can change.

Programmers are naturally inclined to want to use listtransactions like this: feed me the new transactions since I last asked, and I’ll keep my own tally or static record of them. This will seem to work in all regular use, but if you use the amounts for anything, it is highly exploitable:

1. How do you know if a past transaction becomes invalid and disappears?
2. When there’s a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.
3. A transaction can be replaced by a double-spend with a different txid. You would count both spends.

The model where you assume you only need to see new transactions because you've already seen previous transactions is not true. Old transactions can change at any time.

Any time you take an action based on payment amounts received, you always need to go back to bitcoin and ask for a current balance total (or use move or sendfrom), and be ready for the possibility that it can go down.

Now that we have the Accounts feature making it easier to do it the right way, we're better prepared to have listtransactions.

## 2010-12-08 22:36:45 UTC - Re: JSON-RPC method idea: list transactions newer than a given txid #

BitcoinTalk

Re: JSON-RPC method idea: list transactions newer than a given txid

2010-12-08 22:36:45 UTC - Original Post

Then how do you cope with the issues I listed in the message you quoted?

## 2010-12-08 23:11:55 UTC - [bitcoin-list] Bitcoin 0.3.18 is released #

bitcoin-list

[bitcoin-list] Bitcoin 0.3.18 is released

2010-12-08 23:11:55 UTC - Original Email -

Version 0.3.18 is now available.

Changes:

• Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17

• IsStandard() check to only include known transaction types in blocks
• Jgarzik’s optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-based JSON-RPC
commands that Gavin's been working on (more details at
).
• sendfrom
• move
• getbalance
• listtransactions

## 2010-12-08 23:19:24 UTC - Version 0.3.18 #

Changes:

• Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17 and then upgraded again
• IsStandard() check to only include known transaction types in blocks
• Jgarzik’s optimisation to speed up the initial block download a little

The main addition in this release is the Accounts-Based JSON-RPC commands that Gavin's been working on (more details at ).
• sendfrom
• move
• getbalance
• listtransactions

## 2010-12-09 00:12:17 UTC - Re: JSON-RPC method idea: list transactions newer than a given txid #

BitcoinTalk

Re: JSON-RPC method idea: list transactions newer than a given txid

2010-12-09 00:12:17 UTC - Original Post

I’m not talking about the normal risk for a given minconf level, I’m talking about additional pitfalls from listtransactions when used this way.

Quote from: satoshi on December 08, 2010, 10:36:45 PM

1. When there’s a block-chain reorg, it would be easy to double-count transactions when they get confirmed again.

The OP’s example of listtransactions [count=10] [txid] seems to imply and it would be very easy for programmers to assume that if they pass in the last txid of the previous call to listtransactions, they will never see the same transaction more than once, which is not the case. It would be very easy to double-count payments if you don’t maintain your own persistent map or dictionary to track which txid’s you’ve already accepted.

It doesn’t seem right to have a function that seems tailor made to be used a certain obvious way, and that way is a non-obvious trap.

Quote from: satoshi on December 08, 2010, 10:36:45 PM

1. A transaction can be replaced by a double-spend with a different txid. You would count both spends.

Quote from: jgarzik on December 08, 2010, 11:07:22 PM

Suppose both spends are to the same address. getreceivedbyaddress would always count only one or the other spend at any given time, never both.

Using listtransactions, it would be very easy to count both. You see the first spend, you count it. You see the second spend, you count it. Total is double counted.

## 2010-12-09 14:37:05 UTC - Re: Version 0.3.18 #

Original Post

New transaction templates can be added as needed. Within a few days, there will be plenty of GPU power that accepts and works on it. Network support will be thorough long before there’ll be enough clients who understand how to receive and interpret the new transaction.

Timestamp hashes are still already possible:

txin: 0.01
txout: 0.00 OP_CHECKSIG
fee: 0.01

If there’s an actual application like BitDNS getting ready to actually start inserting hashes, we can always add a specific transaction template for timestamps.

I like Hal Finney’s idea for user-friendly timestamping. Convert the hash of a file to a bitcoin address and send 0.01 to it:

Quote from: Hal on December 05, 2010, 11:43:56 PM

I thought of a simple way to implement the timestamp concept I mentioned above. Run sha1sum on the file you want to timestamp. Convert the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a small payment to that address.

The money will be lost forever, as there is no way to spend it further, but the timestamp Bitcoin address will remain in the block chain as a record of the file’s existence.

I understand that this is arguably not a good use of the Bitcoin distributed database, but nothing stops people from doing this so we should be aware that it may be done.

## 2010-12-09 15:17:53 UTC - Re: Version 0.3.18 #

Original Post

I came to agree with Gavin about whitelisting when I realized how quickly new transaction types can be added.

Quote from: nanotube on December 09, 2010, 06:19:05 AM

why not make it easier on everyone and just allow say, 64 or 128 bytes of random data in a transaction?

That’s already possible. OP_CHECKSIG. can be 33 to 120 bytes.

I also support a third transaction type for timestamp hash sized arbitrary data. There’s no point not having one since you can already do it anyway. It would tell nodes they don’t need to bother to index it.

## 2010-12-09 18:08:08 UTC - Re: JSON-RPC method idea: list transactions newer than a given txid #

BitcoinTalk

Re: JSON-RPC method idea: list transactions newer than a given txid

2010-12-09 18:08:08 UTC - Original Post

Quote from: jgarzik on December 09, 2010, 12:58:05 AM

I agree with you and satoshi about “txs after “. My listtransactions (now xlisttransactions) patch pointedly does not have that feature, and never has.

As long as the interface is designed for things like showing the user the last N transactions history, it’s fine, now that we have the Accounts feature making it easier to do payment detection the right way.

Gavin, could listtransactions have an option to list transactions for all accounts?

I’m not sure what the interface could be, maybe:
listtransactions [count]

It would be hard to do that from the command line though.

I can’t think of a good solution for the interface, that’s the problem. Maybe “” special case like "” is. Everyone would have to make sure no user can create account name “”.

Quote from: jgarzik on December 09, 2010, 04:13:50 PM

Sure, and that’s easy enough to track with transactions.

I don’t get how that’s “easy” to track with transactions.

## 2010-12-09 18:28:45 UTC - Re: Automated nightly builds #

Thanks for setting this up Cdecker.

Is there any chance of getting it to build the GUI version also? If this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of following the steps in build-unix.txt exactly. Is this an environment where you can build wxWidgets once and leave it there and just keep using it?

## 2010-12-09 21:02:42 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-09 21:02:42 UTC - Original Post

I think it would be possible for BitDNS to be a completely separate network and separate block chain, yet share CPU power with Bitcoin. The only overlap is to make it so miners can search for proof-of-work for both networks simultaneously.

The networks wouldn’t need any coordination. Miners would subscribe to both networks in parallel. They would scan SHA such that if they get a hit, they potentially solve both at once. A solution may be for just one of the networks if one network has a lower difficulty.

I think an external miner could call getwork on both programs and combine the work. Maybe call Bitcoin, get work from it, hand it to BitDNS getwork to combine into a combined work.

Instead of fragmentation, networks share and augment each other’s total CPU power. This would solve the problem that if there are multiple networks, they are a danger to each other if the available CPU power gangs up on one. Instead, all networks in the world would share combined CPU power, increasing the total strength. It would make it easier for small networks to get started by tapping into a ready base of miners.

## 2010-12-09 22:46:50 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-09 22:46:50 UTC - Original Post

Quote from: nanotube on December 09, 2010, 09:20:40 PM

seems that the miner would have to basically do “extra work”. and if there’s no reward from the bitdns mining from the extra work (which of course, slows down the main bitcoin work), what would be a miner’s incentive to include bitdns (and whatever other side chains) ?

The incentive is to get the rewards from the extra side chains also for the same work.

While you are generating bitcoins, why not also get free domain names for the same work?

If you currently generate 50 BTC per week, now you could get 50 BTC and some domain names too.

You have one piece of work. If you solve it, it will solve a block from both Bitcoin and BitDNS. In concept, they’re tied together by a Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch, and to hand it in to BitDNS, you break off the Bitcoin branch.

In practice, to retrofit it for Bitcoin, the BitDNS side would have to have maybe ~200 extra bytes, but that’s not a big deal. You’ve been talking about 50 domains per block, which would dwarf that little 200 bytes per block for backward compatibility. We could potentially schedule a far in future block when Bitcoin would upgrade to a modernised arrangement with the Merkle Tree on top, if we care enough about saving a few bytes.

Note that the chains are below this new Merkle Tree. That is, each of Bitcoin and BitDNS have their own chain links inside their blocks. This is inverted from the common timestamp server arrangement, where the chain is on top and then the Merkle Tree, because that creates one common master chain. This is two timestamp servers not sharing a chain.

## 2010-12-09 23:58:54 UTC - Re: Fees in BitDNS confusion #

BitcoinTalk

Re: Fees in BitDNS confusion

2010-12-09 23:58:54 UTC - Original Post

Not locktime.

There’s a possible design for far in the future:

You intentionally write a double-spend. You write it with the same inputs and outputs, but this time with a fee. When your double-spend gets into a block, the first spend becomes invalid. The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.

It’s easier said than implemented. There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases. Every assumption in the existing code is that you’re not trying to write double-spends.

There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher. Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.

## 2010-12-10 17:29:28 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-10 17:29:28 UTC - Original Post

Piling every proof-of-work quorum system in the world into one dataset doesn’t scale.

Bitcoin and BitDNS can be used separately. Users shouldn’t have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.

The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it’s easy for lots of users and small devices.

Fears about securely buying domains with Bitcoins are a red herring. It’s easy to trade Bitcoins for other non-repudiable commodities.

If you’re still worried about it, it’s cryptographically possible to make a risk free trade. The two parties would set up transactions on both sides such that when they both sign the transactions, the second signer’s signature triggers the release of both. The second signer can’t release one without releasing the other.

## 2010-12-10 19:21:03 UTC - Accounts example code #

Some sample pseudocode using the new Accounts based commands in 0.3.18.

print “balance: " + getbalance(username, 0)
print “available balance: " + getbalance(username, 6)

// if you make a sale, move the money from their account to your "” account
if (move(username, “”, amount, 6, “purchased item”))
SendTheGoods()

// withdrawal

You can use listtransactions(username) to show them a list of their recent transactions.

## 2010-12-10 19:55:12 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-10 19:55:12 UTC - Original Post

Quote from: Hal on December 10, 2010, 07:14:04 PM

additional block chains would each create their own flavor of coins, which would trade with bitcoins on exchanges? These chain-specific coins would be used to reward miners on those chains, and to purchase some kinds of rights or privileges within the domain of that chain?

Right, the exchange rate between domains and bitcoins would float.

A longer interval than 10 minutes would be appropriate for BitDNS.

So far in this discussion there’s already a lot of housekeeping data required. It will be much easier if you can freely use all the space you need without worrying about paying fees for expensive space in Bitcoin’s chain. Some transactions:

Changing the IP record.

Name change. A domain object could entitle you to one domain, and you could change it at will to any name that isn’t taken. This would encourage users to free up names they don’t want anymore. Generated domains start out blank and the miner sells it to someone who changes it to what they want.

Renewal. Could be free, or maybe require consuming another domain object to renew. In that case, domain objects (domaincoins?) could represent the right to own a domain for a year. The spent fee goes to the miners in the next block fee.

## 2010-12-10 20:19:39 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-10 20:19:39 UTC - Original Post

I agree. All transactions, IP changes, renewals, etc. should have some fee that goes to the miners.

You might consider a certain amount of work to generate a domain, instead of a fixed total circulation. The work per domain could be on a schedule that grows with Moore’s Law. That way the number of domains would grow with demand and the number of people using it.

## 2010-12-11 13:08:30 UTC - Re: BitDNS and Generalizing Bitcoin #

BitcoinTalk

Re: BitDNS and Generalizing Bitcoin

2010-12-11 13:08:30 UTC - Original Post

@dtvan: all 3 excellent points.

1. IP records don’t need to be in the chain, just do registrar function not DNS. And CA problem solved, neat.
2. Pick one TLD, .web +1.
3. Expiration and significant renewal costs, very important.

Quote from: joe on December 11, 2010, 10:53:58 AM

However, thinking more about this now I support inclusion of additional coinbases / tracking systems in the main network. The reason for doing this is so as not to water down CPU power into multiple networks. We want one strong network, so the network should be versatile.

Avoiding CPU power fragmentation is no longer a reason. Independent networks/chains can share CPU power without sharing much else. See: http://bitcointalk.org/index.php?topic=1790.msg28696#msg28696 and http://bitcointalk.org/index.php?topic=1790.msg28715#msg28715

## 2010-12-11 13:32:37 UTC - Re: Bitcoin and buffer overflow attacks #

BitcoinTalk

Re: Bitcoin and buffer overflow attacks

2010-12-11 13:32:37 UTC - Original Post

Quote from: da2ce7 on December 11, 2010, 05:49:22 AM

direct to IP address transfers seems like a obvious surface area to attack.

If you ever find anyone who turned it on. It’s disabled by default.

Quote from: witchspace on December 11, 2010, 09:59:40 AM

There is no way to be absolutely sure that there are no buffer overflow attacks. Although it would help to implement the client in a language that doesn’t have buffer overflows because it checks array indices (Python, Java, C#, …).

It’s all STL. There are almost no buffers.

## 2010-12-11 22:07:04 UTC - Re: minimalistic bitcoin client on D language? #

BitcoinTalk

Re: minimalistic bitcoin client on D language?

2010-12-11 22:07:04 UTC - Original Post

Quote from: Hal on December 11, 2010, 08:08:45 PM

I’d like to hear some specific criticisms of the code. To me it looks like an impressive job, although I’d wish for more comments. Now I’ve mostly studied the init, main, script and a bit of net modules. This is some powerful machinery.

That means a lot coming from you, Hal. Thanks.

## 2010-12-11 23:39:16 UTC - Re: PC World Article on Bitcoin #

BitcoinTalk

Re: PC World Article on Bitcoin

2010-12-11 23:39:16 UTC - Original Post

It would have been nice to get this attention in any other context. WikiLeaks has kicked the hornet’s nest, and the swarm is headed towards us.

## 2010-12-12 18:22:33 UTC - Added some DoS limits, removed safe mode (0.3.19) #

BitcoinTalk

Added some DoS limits, removed safe mode (0.3.19)

2010-12-12 18:22:33 UTC - Original Post

There’s more work to do on DoS, but I’m doing a quick build of what I have so far in case it’s needed, before venturing into more complex ideas. The build for this is version 0.3.19.

As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.

I’m leaving the -limitfreerelay part as a switch for now and it’s there if you need it.

“safe mode” alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with “-disablesafemode”, but it’s better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.

Builds:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/

## 2010-12-13 16:12:09 UTC - [bitcoin-list] Bitcoin 0.3.19 is released #

bitcoin-list

[bitcoin-list] Bitcoin 0.3.19 is released

2010-12-13 16:12:09 UTC - Original Email

This is a minor release to add some DoS protection.

Changes:

• Added some DoS limits, though it’s still far from DoS resistant.