Kicking the Hornet's Nest - part 20
# Kicking the Hornet's Nest - third edition - part 20
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by [crrdlx](@crrdlx), npub:
```
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
```
### Kicking the Hornet's Nest pages 450 - 475
##### BitcoinTalk
#### Re: Memory leak
##### 2010-10-03 22:07:00 UTC - [-](https://bitcointalk.org/index.php?topic=1023.msg15150#msg15150)
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.
Are you using -addnode?
##### BitcoinTalk
#### Re: Version 0.3.13, please upgrade
##### 2010-10-03 23:46:19 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15167#msg15167)
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.
##### BitcoinTalk
#### Re: Website and software translations
##### 2010-10-04 01:44:41 UTC - [-](https://bitcointalk.org/index.php?topic=151.msg15176#msg15176)
Thanks eurekafag, Russian translation added to SVN rev 160.
##### BitcoinTalk
#### Re: Website and software translations
##### 2010-10-04 19:21:01 UTC - [-](https://bitcointalk.org/index.php?topic=151.msg15360#msg15360)
[Quote from: eurekafag on October 04, 2010, 10:55:56 AM](https://bitcointalk.org/index.php?topic=151.msg15248#msg15248)
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\locale u\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.
##### BitcoinTalk
#### Re: [PATCH] increase block size limit
##### 2010-10-04 19:48:40 UTC - [-](https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366)
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.
Martii Malmi (AKA Sirius) “COPA trial” email #237
Date: Mon, 04 Oct 2010 20:05:26 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: Re: SMF php code
To: mmalmi@cc.hut.fi
I reuploaded the changes. For future reference, the files in Sources
with customisations are:
Register.php
PersonalMessage.php
ManageRegistration.php
Subs.php
Let me know whenever you do an upgrade so I can make sure all my changes
survived.
Hopefully the 1.1.x line is mature and updates are infrequent. We
shouldn't upgrade to 2.0. I made a ton of customisations that wouldn't
be compatible, and I kind of prefer the look of 1.1 over 2.0 anyway.
The captcha url has mycode=4 added to it, and the register page has
extra hidden mycode=2 through 5 images so any automated thing wouldn't
know which one to pick. Everything that uses captcha has to have that
mycode=4 thing added. Something in sending personal messages also uses
captcha.
mmalmi@cc.hut.fi wrote:
> Sorry, I didn't notice your custom code when updating. Re-integration is
> a good idea if it's not too much work. I've removed hundreds of spam
> accounts by making a search for old accounts that have a webpage url and
> 0 posts.
>
##### BitcoinTalk
#### Re: Website and software translations
##### 2010-10-06 15:42:39 UTC - [-](https://bitcointalk.org/index.php?topic=151.msg15660#msg15660)
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.
I uploaded the changes.
This Windows build has the Russian translation in it:
[http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe)
##### BitcoinTalk
#### Re: I broke my wallet, sends never confirm now.
##### 2010-10-06 16:54:23 UTC - [-](https://bitcointalk.org/index.php?topic=1306.msg15672#msg15672)
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:
[http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe)
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.
##### BitcoinTalk
#### Re: Tor connections not working reliably, many seednodes offline
##### 2010-10-06 17:36:41 UTC - [-](https://bitcointalk.org/index.php?topic=1375.msg15682#msg15682)
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?
##### BitcoinTalk
#### Re: The Niche List
##### 2010-10-06 23:10:31 UTC - [-](https://bitcointalk.org/index.php?topic=1268.msg15741#msg15741)
[Quote from: kiba on September 23, 2010, 04:00:16 PM](https://bitcointalk.org/index.php?topic=1268.msg13828#msg13828)
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.
##### BitcoinTalk
#### Key pool feature for safer wallet backup
##### 2010-10-09 20:19:33 UTC - [-](https://bitcointalk.org/index.php?topic=1414.msg16316#msg16316)
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.
##### BitcoinTalk
#### Version 0.3.14
##### 2010-10-21 16:39:27 UTC - [-](https://bitcointalk.org/index.php?topic=1528.msg17924#msg17924)
Version 0.3.14 is now available
[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.14/](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
- validateaddress RPC command
eurekafag:
- Russian translation
##### BitcoinTalk
#### Re: Website and software translations
##### 2010-10-21 22:50:47 UTC - [-](https://bitcointalk.org/index.php?topic=151.msg17965#msg17965)
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](https://bitcointalk.org/index.php?topic=151.msg15697#msg15697)
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
#### Re: ERROR - PLEASE HELP ME!
##### 2010-10-23 18:22:49 UTC - [-](https://bitcointalk.org/index.php?topic=1530.msg18241#msg18241)
[Quote from: theymos on October 21, 2010, 10:00:26 PM](https://bitcointalk.org/index.php?topic=1530.msg17955#msg17955)
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](https://bitcointalk.org/index.php?topic=1530.msg18074#msg18074)
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
#### Re: ERROR - PLEASE HELP ME!
##### 2010-10-23 18:38:04 UTC - [-](https://bitcointalk.org/index.php?topic=1530.msg18245#msg18245)
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.
##### BitcoinTalk
#### Re: Win7 64bit since last patch Tues now crashes
##### 2010-10-23 18:52:02 UTC - [-](https://bitcointalk.org/index.php?topic=1540.msg18246#msg18246)
[Quote from: Odin on October 22, 2010, 09:24:38 PM](https://bitcointalk.org/index.php?topic=1540.msg18105#msg18105)
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?
##### BitcoinTalk
#### Re: Suggestion: Allow short messages to be sent together with bitcoins ?
##### 2010-10-23 19:02:57 UTC - [-](https://bitcointalk.org/index.php?topic=1545.msg18250#msg18250)
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.
##### BitcoinTalk
#### Re: Multiple Wallets, one computer
##### 2010-10-24 19:17:51 UTC - [-](https://bitcointalk.org/index.php?topic=665.msg18349#msg18349)
I have the beginning of something like this. It's mostly like what Gavin described.
Some more rpc interface:
move <fromaccount> <toaccount> <amount>
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.
I'm thinking a new function getaccountaddress instead of overloading getnewaddress:
getaccountaddress <account>
Gives you an address allocated from getnewaddress <account>. 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?
##### BitcoinTalk
#### Re: Multiple Wallets, one computer
##### 2010-10-25 16:53:53 UTC - [-](https://bitcointalk.org/index.php?topic=665.msg18508#msg18508)
Here's some pseudocode of how you would use the account based commands. It sure makes website integration a lot easier.
print "send to " + getaccountaddress(username) + " to fund your account"
print "balance: " + getbalance(username, 0)
print "available balance: " + getbalance(username, 6)
// if you make a sale, move the money out of their account
move(username, "", amount, 6)
// withdrawal
sendfrom(username, bitcoinaddress, amount, 6)
##### BitcoinTalk
#### Re: Win7 64bit since last patch Tues now crashes
##### 2010-10-25 17:27:47 UTC - [-](https://bitcointalk.org/index.php?topic=1540.msg18511#msg18511)
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.
##### BitcoinTalk
#### Re: New icon/logo
##### 2010-11-13 00:55:51 UTC - [-](https://bitcointalk.org/index.php?topic=64.msg21766#msg21766)
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.
##### BitcoinTalk
#### Re: Some testing that I did on the testnetwork, my findings.
##### 2010-11-13 23:25:26 UTC - [-](https://bitcointalk.org/index.php?topic=1668.msg21896#msg21896)
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.
##### BitcoinTalk
#### Version 0.3.15
##### 2010-11-13 23:26:40 UTC - [-](https://bitcointalk.org/index.php?topic=1780.msg21897#msg21897)
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
- make sure generation doesn't start before block 74000 downloaded
- bugfixes by Dean Gores
- testnet, keypoololdest and paytxfee added to getinfo
##### BitcoinTalk
#### Re: Some testing that I did on the testnetwork, my findings.
##### 2010-11-14 16:53:19 UTC - [-](https://bitcointalk.org/index.php?topic=1668.msg21959#msg21959)
[Quote from: ByteCoin on November 13, 2010, 11:55:11 PM](https://bitcointalk.org/index.php?topic=1668.msg21899#msg21899)
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.
##### BitcoinTalk
#### Re: Need OP_BLOCKNUMBER to allow "time" limited transactions
##### 2010-11-15 18:37:44 UTC - [-](https://bitcointalk.org/index.php?topic=1786.msg22119#msg22119)
We can't safely do OPBLOCKNUMBER. 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 OPBLOCKNUMBER 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.
##### BitcoinTalk
#### Re: Transaction / spam flood attack currently under way
##### 2010-11-19 23:50:24 UTC - [-](https://bitcointalk.org/index.php?topic=1850.msg22952#msg22952)
[Quote from: creighto on November 19, 2010, 08:29:12 PM](https://bitcointalk.org/index.php?topic=1850.msg22896#msg22896)
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](https://bitcointalk.org/index.php?topic=1842.msg22844#msg22844)
_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.
##### BitcoinTalk
#### Re: OpenCL miner for the masses
##### 2010-11-20 17:24:20 UTC - [-](https://bitcointalk.org/index.php?topic=1334.msg23097#msg23097)
[Quote from: m0mchil on November 20, 2010, 10:16:19 AM](https://bitcointalk.org/index.php?topic=1334.msg23018#msg23018)
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](https://bitcointalk.org/index.php?topic=1334.msg22251#msg22251)
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 n2 algorithm. The new efficient single-pass algorithm is orders of magnitude quicker. (O(n) vs O(n2)/2 algorithm, n=200 maybe 10 to 100 times quicker)
##### BitcoinTalk
#### New getwork
##### 2010-11-23 19:50:12 UTC - [-](https://bitcointalk.org/index.php?topic=1901.msg23876#msg23876)
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.
##### BitcoinTalk
#### Re: New getwork
##### 2010-11-23 20:55:27 UTC - [-](https://bitcointalk.org/index.php?topic=1901.msg23891#msg23891)
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).
##### BitcoinTalk
#### Re: New getwork
##### 2010-11-24 17:21:01 UTC - [-](https://bitcointalk.org/index.php?topic=1901.msg24095#msg24095)
[Quote from: jgarzik on November 24, 2010, 04:47:42 AM](https://bitcointalk.org/index.php?topic=1901.msg24008#msg24008)
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](https://bitcointalk.org/index.php?topic=1901.msg24050#msg24050)
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.
##### BitcoinTalk
#### Re: OpenCL miner for the masses
##### 2010-11-24 17:53:09 UTC - [-](https://bitcointalk.org/index.php?topic=1334.msg24101#msg24101)
A revised version of getwork is now in the official client, but the miners need to be updated a little to use it.
##### BitcoinTalk
#### Re: RFC: ship block chain 1-74000 with release tarballs?
##### 2010-11-25 17:51:39 UTC - [-](https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438)
It's not the downloading that takes the time, it's verifying and indexing it.
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.
##### BitcoinTalk
#### Version 0.3.17
##### 2010-11-25 20:07:36 UTC - [-](https://bitcointalk.org/index.php?topic=1946.msg24460#msg24460)
Version 0.3.17 is now available.
Changes:
- new getwork, thanks m0mchil
- added transaction fee setting in UI options menu
- free transaction limits
- sendtoaddress returns transaction id instead of "sent"
- getaccountaddress <account>
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 <account> will be in the next release. We still have some more changes to make first.
Downloads:
[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.17/)
##### BitcoinTalk
#### Re: RFC: ship block chain 1-74000 with release tarballs?
##### 2010-11-26 17:32:01 UTC - [-](https://bitcointalk.org/index.php?topic=1931.msg24662#msg24662)
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: jgarzik on November 26, 2010, 02:07:43 AM](https://bitcointalk.org/index.php?topic=1931.msg24522#msg24522)
[Quote from: satoshi on November 25, 2010, 05:51:39 PM](https://bitcointalk.org/index.php?topic=1931.msg24438#msg24438)
Maybe Berkeley DB has some tweaks we can make to enable or increase cache memory.
Which of the [ACID](http://en.wikipedia.org/wiki/ACID) properties do you need, while downloading?
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.
##### BitcoinTalk
#### Re: Version 0.3.17
##### 2010-11-26 18:23:30 UTC - [-](https://bitcointalk.org/index.php?topic=1946.msg24673#msg24673)
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.
##### BitcoinTalk
#### Re: New getwork
##### 2010-11-26 21:31:13 UTC - [-](https://bitcointalk.org/index.php?topic=1901.msg24708#msg24708)
That's what it does, it returns true/false.
##### BitcoinTalk
#### Re: New demonstration CPU miner available
##### 2010-11-26 22:02:41 UTC - [-](https://bitcointalk.org/index.php?topic=1925.msg24719#msg24719)
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.
##### BitcoinTalk
#### Re: Cooperative mining
##### 2010-11-28 16:03:30 UTC - [-](https://bitcointalk.org/index.php?topic=1976.msg25119#msg25119)
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.
##### BitcoinTalk
#### Re: RFC: ship block chain 1-74000 with release tarballs?
##### 2010-11-28 17:13:01 UTC - [-](https://bitcointalk.org/index.php?topic=1931.msg25138#msg25138)
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](https://bitcointalk.org/index.php?topic=1931.msg25017#msg25017)
Another new user on IRC, Linux this time, was downloading at a rate of 1 block every 4 seconds -- estimated total download time around 4 days.
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](https://bitcointalk.org/index.php?topic=1931.msg25058#msg25058)
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.
##### BitcoinTalk
#### Re: Is safe running bitcoins with the same wallet on more computers simultaneously?
##### 2010-11-28 18:06:39 UTC - [-](https://bitcointalk.org/index.php?topic=1986.msg25154#msg25154)
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](http://bitcointalk.org/index.php?topic=1925.0)
##### BitcoinTalk
#### Re: RFC: ship block chain 1-74000 with release tarballs?
##### 2010-11-29 20:19:12 UTC - [-](https://bitcointalk.org/index.php?topic=1931.msg25449#msg25449)
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
And, additionally, bitcoin forces a database checkpoint, pushing all transactions from log into main database.
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);
Probably should add this:
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);
Quote
2) 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.
##### BitcoinTalk
#### Re: Incompatible wallet format with latest bitcoin-git ?
##### 2010-11-30 19:02:31 UTC - [-](https://bitcointalk.org/index.php?topic=2007.msg25799#msg25799)
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
Martii Malmi (AKA Sirius) “COPA trial” email #238
Date: Wed, 01 Dec 2010 00:58:37 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: [Fwd: Bitcoin.org is down]
To: Martti Malmi <mmalmi@cc.hut.fi>
-------- Original Message --------
Subject: Bitcoin.org is down
Date: Tue, 30 Nov 2010 18:27:02 -0600
From: theymos <theymos@mm.st>
To: satoshin@gmx.com
Bitcoin.org has been down for several hours.
##### BitcoinTalk
#### Re: RFC: ship block chain 1-74000 with release tarballs?
##### 2010-12-01 21:25:39 UTC - [-](https://bitcointalk.org/index.php?topic=1931.msg26016#msg26016)
That's a good optimisation. I'll add that next time I update SVN.
More generally, we could also consider this:
dbenv.setlkmax_objects(10000);
dbenv.seterrfile(fopen(strErrorFile.cstr(), "a")); /// debug
dbenv.setflags(DBAUTO_COMMIT, 1);
+ dbenv.setflags(DBTXN_NOSYNC, 1);
ret = dbenv.open(strDataDir.c_str(),
DB_CREATE |
DBINITLOCK |
DBINITLOG |
We would then rely on dbenv.txn_checkpoint(0, 0, 0) in CDB::Close() to flush after wallet writes.
Martii Malmi (AKA Sirius) “COPA trial” email #239
Date: Thu, 02 Dec 2010 22:00:56 +0000
From: Satoshi Nakamoto <satoshin@gmx.com>
Subject: What was the bitcoin.org outage?
To: Martti Malmi <mmalmi@cc.hut.fi>
Do you know what caused that outage? Did it need to be rebooted, or was
it a DoS or something? The IP was pingable during the outage.
Did you get back to davidonpda about his doing a mirror backup? I think
that's a really good idea. Do you do any backups, or the VPS do any for
you automatically?