# Kicking the Hornet's Nest - third edition - part 19

All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi

Edited by [crrdlx](@crrdlx), npub:

```

npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j

```

### Kicking the Hornet's Nest pages 425 - 450

##### BitcoinTalk

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

##### 2010-08-27 16:13:16 UTC - [-](https://bitcointalk.org/index.php?topic=928.msg11400#msg11400)

That's kind of interesting as an upside-down bar chart of how many blocks were produced each day. The target is 144 blocks per day.

##### BitcoinTalk

#### Re: Bitcoins are most like shares of common stock

##### 2010-08-27 16:39:26 UTC - [-](https://bitcointalk.org/index.php?topic=845.msg11403#msg11403)

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

More like a collectible or commodity.

##### BitcoinTalk

#### Re: Bitcoin does NOT violate Mises' Regression Theorem

##### 2010-08-27 17:32:07 UTC - [-](https://bitcointalk.org/index.php?topic=583.msg11405#msg11405)

As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:

- boring grey in colour

- not a good conductor of electricity

- not particularly strong, but not ductile or easily malleable either

- not useful for any practical or ornamental purpose

and one special, magical property:

- can be transported over a communications channel

If it somehow acquired any value at all for whatever reason, then anyone wanting to transfer wealth over a long distance could buy some, transmit it, and have the recipient sell it.

Maybe it could get an initial value circularly as you've suggested, by people foreseeing its potential usefulness for exchange. (I would definitely want some) Maybe collectors, any random reason could spark it.

I think the traditional qualifications for money were written with the assumption that there are so many competing objects in the world that are scarce, an object with the automatic bootstrap of intrinsic value will surely win out over those without intrinsic value. But if there were nothing in the world with intrinsic value that could be used as money, only scarce but no intrinsic value, I think people would still take up something.

(I'm using the word scarce here to only mean limited potential supply)

##### BitcoinTalk

#### Version 0.3.11 with upgrade alerts

##### 2010-08-27 21:54:12 UTC - [-](https://bitcointalk.org/index.php?topic=941.msg11439#msg11439)

Version 0.3.11 is now available.

Changes:

- Some blk*.dat checking on load

- Built the -4way code with -march=amdfam10, which makes it a little faster

- Warning if your clock is too far off

- Warnings/errors/alerts can also be seen in the getinfo command

- Alert system

The alert system can display notifications on the status bar to alert you if you're running a version that needs to be upgraded for an important security update.

In response to an alert, your node may also go into safe mode, which disables the following json-rpc commands (used by automated websites) to protect it from losing money until you get a chance to upgrade:

sendtoaddress

getbalance

getreceivedbyaddress

getreceivedbylabel

listreceivedbyaddress

listreceivedbylabel

If you decide it's a false alarm and want to take your chances, you can use the switch -disablesafemode to re-enable them.

This is an important safety improvement. For a large segment of possible problems, this can warn everyone immediately once a problem is discovered and prevent them from acting on bad information.

Nodes keep operating and do not stop generating in response to an alert, so old versions may still try to make a fork, but the alert system can make sure users are warned not to act on anything in the fork.

Download:

[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.11/)

##### BitcoinTalk

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

##### 2010-08-28 14:27:15 UTC - [-](https://bitcointalk.org/index.php?topic=820.msg11503#msg11503)

The simplification is intentional. There will only be more than one thash[7]=0 in one out of 134,217,728 cases. It only makes it 0.0000007% slower.

##### BitcoinTalk

#### Re: Version 0.3.11 with upgrade alerts

##### 2010-08-28 14:54:04 UTC - [-](https://bitcointalk.org/index.php?topic=941.msg11505#msg11505)

[Quote from: torservers on August 28, 2010, 01:00:37 PM](https://bitcointalk.org/index.php?topic=941.msg11499#msg11499)

The "About" dialog still shows 0.3.10.1 beta.

What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.

The Mac version is still 0.3.10.1.

[Quote from: pavelo on August 28, 2010, 07:36:07 AM](https://bitcointalk.org/index.php?topic=941.msg11481#msg11481)

iirc, it is possible to specify -march on a per-function basis using some gcc attribute. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.

I updated the first post to be more specific. Only the -4way code is compiled this way.

##### BitcoinTalk

#### Re: Big endian code problems

##### 2010-08-29 22:14:36 UTC - [-](https://bitcointalk.org/index.php?topic=816.msg11610#msg11610)

The code assumes little-endian throughout and was written with the intention of never being ported to big-endian. Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code. It would not be worth the extra sourcecode bloat.

Big-endian is on its way out anyway.

##### BitcoinTalk

#### Re: CryptoPP Assertion Error

##### 2010-09-05 23:25:32 UTC - [-](https://bitcointalk.org/index.php?topic=967.msg12062#msg12062)

You can probably just comment out the line

cryptopp/secblock.h:187

//assert(false);

Let me know if it works, and watch if it memory leaks.

It looks like a template class to make sure the derived class defines its own version of allocate and deallocate. It would be weird if that was the actual problem and it made it all the way to release. Probably a false alarm.

##### BitcoinTalk

#### Re: Warning : Check your system ( Help me )

##### 2010-09-05 23:36:20 UTC - [-](https://bitcointalk.org/index.php?topic=960.msg12063#msg12063)

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

It's trying to tell them their clock is wrong and they need to correct it.

It's relying on 3 time sources:

1) the system clock

2) the other nodes, if within an hour of the system clock

if those disagree, then

3) the user (asking the user to fix the system clock)

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

##### BitcoinTalk

#### Re: HTTP status codes from the JSON-RPC api

##### 2010-09-06 21:21:21 UTC - [-](https://bitcointalk.org/index.php?topic=969.msg12130#msg12130)

This is in SVN rev 147.

This is more standard, and although json-rpc 1.0 didn't specify the format of error objects, it did specify that they would be objects not strings or other values, so we needed to change this to be correct. The code/message members have become standard in later json-rpc specs.

If you have code that checks the error and expects a string, you'll need to change it. When there is an error, the error member is now an object not a string.

Also in SVN rev 147:

- The command line json-rpc returns the error code as its exit code. Exit codes can only be 0-255 on unix, so it's abs(code)%256.

- The "backupwallet <destination>" command that was discussed in another thread. It locks the wallet and copies it, so you can be sure you get a correct copy.

##### BitcoinTalk

#### Re: Warning : Check your system ( Help me )

##### 2010-09-06 21:41:06 UTC - [-](https://bitcointalk.org/index.php?topic=960.msg12132#msg12132)

[Quote from: Insti on September 06, 2010, 12:51:37 PM](https://bitcointalk.org/index.php?topic=960.msg12101#msg12101)

[Quote from: satoshi on September 05, 2010, 11:36:20 PM](https://bitcointalk.org/index.php?topic=960.msg12063#msg12063)

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

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

Thanks.

##### BitcoinTalk

#### Re: auto backing up of wallet.dat

##### 2010-09-06 21:45:10 UTC - [-](https://bitcointalk.org/index.php?topic=921.msg12134#msg12134)

rpc backupwallet <destination> is in SVN rev 147.

##### BitcoinTalk

#### Re: bitcoind as daemon in OSX

##### 2010-09-06 21:52:45 UTC - [-](https://bitcointalk.org/index.php?topic=992.msg12135#msg12135)

Can you build?

Try changing line 78 of init.cpp from:

#ifdef WXGTK

to:

#ifndef WXMSW

If that works, I'll change the source. It should work.

##### BitcoinTalk

#### Re: Always pay transaction fee?

##### 2010-09-07 16:32:21 UTC - [-](https://bitcointalk.org/index.php?topic=994.msg12168#msg12168)

Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.

The threshold should probably be lower than it currently is.

I don't think the threshold should ever be 0. We should always allow at least some free transactions.

##### BitcoinTalk

#### Version 0.3.12

##### 2010-09-07 19:17:55 UTC - [-](https://bitcointalk.org/index.php?topic=999.msg12181#msg12181)

Version 0.3.12 is now available.

Features:

- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)

- json-rpc command line returns exit codes.

- json-rpc "backupwallet" command.

- Recovers and continues if an exception is caused by a message you received. Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

If you have json-rpc code that checks the contents of the error string, you need to change it to expect error objects of the form {"code":<number>,"message":<string>}, which is the standard. See this thread:

[http://BitcoinTalk.org/index.php?topic=969.0](http://bitcointalk.org/index.php?topic=969.0)

Download:

[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.12/)

##### BitcoinTalk

#### Re: Always pay transaction fee?

##### 2010-09-08 17:30:14 UTC - [-](https://bitcointalk.org/index.php?topic=994.msg12237#msg12237)

Currently, paying a fee is controlled manually with the -paytxfee switch. It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee. We're so far from reaching the threshold, we don't need that yet. It's a good idea to see how things go with controlling it manually first anyway.

It's not a big deal if we reach the threshold. Free transactions would just take longer to get into a block.

I did a rough tally of 4000 blocks from around 74000-78000. This is excluding the block reward transactions:

There were average 2 transactions per block, 17 transactions per hour, 400 transactions per day.

Average transaction bytes per block was 428 bytes, or 214 bytes per transaction.

The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.

The threshold can easily be changed in the future. We can decide to increase it when the time comes. It's a good idea to keep it lower as a circuit breaker and increase it as needed. If we hit the threshold now, it would almost certainly be some kind of flood and not actual use. Keeping the threshold lower would help limit the amount of wasted disk space in that event.

##### BitcoinTalk

#### Re: Version 0.3.12

##### 2010-09-08 18:06:04 UTC - [-](https://bitcointalk.org/index.php?topic=999.msg12240#msg12240)

Bitcoin clients currently only create and recognize transactions that match two possible templates.

Those are some quick tests that loosely check if transactions fit some general metrics that those standard transactions fit. Nodes will only work on adding those transactions to their block.

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.

##### BitcoinTalk

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

##### 2010-09-08 20:27:39 UTC - [-](https://bitcointalk.org/index.php?topic=955.msg12248#msg12248)

[Quote from: BitLex on September 07, 2010, 08:10:54 PM](https://bitcointalk.org/index.php?topic=955.msg12189#msg12189)

_AMD X3 @2.8ghz

->stock client

_3800khs 150Watt_

Did you try -4way?

Quote

How many hashes can I expect with a 24 core machine? I have a quad-core generating 4,300 hashes-per-second, so I am estimating a 24-core machine could mine bitcoins at 25,000 hashes-per-second.

AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with -4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the best choice because it has the best SSE2 implementation. (or maybe because tcatm had an AMD and optimised his code for that)

There's been so much else to do that I haven't had time to make -4way automatic. For now you still have to do it manually.

[http://BitcoinTalk.org/index.php?topic=820.0](http://bitcointalk.org/index.php?topic=820.0)

##### BitcoinTalk

#### Auto-detect for 128-bit 4-way SSE2

##### 2010-09-09 01:04:05 UTC - [-](https://bitcointalk.org/index.php?topic=1007.msg12262#msg12262)

SVN rev 150 has some code to try to auto-detect whether to use 4-way SSE2. We need this because it's only faster on certain newer CPUs that have 128-bit SSE2 and not ones with 64-bit SSE2.

It uses the CPUID instruction to get the CPU brand, family, model number and stepping. That's the easy part. Knowing what to do with the model number is the hard part. I was not able to find any table of family, model and stepping numbers for CPUs. I had to go by various random reports I saw.

Here's what I ended up with:

Code:

// We need Intel Nehalem or AMD K10 or better for 128bit SSE2

// Nehalem = i3/i5/i7 and some Xeon

// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II

// Intel Core i5 family 6, model 26 or 30

// Intel Core i7 family 6, model 26 or 30

// Intel Core i3 family 6, model 37

// AMD Phenom family 16, model 10

bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||

(fAMD && nFamily * 10000 + nModel >= 160010));

I saw some sporadic inconsistent model numbers for AMD CPUs, so I'm not sure if this will catch all capable AMDs.

If it's wrong, you can still override it with -4way or -4way=0.

It prints what it finds in debug.log. Search on CPUID.

This is only enabled if built with GCC.

##### BitcoinTalk

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

##### 2010-09-10 00:23:24 UTC - [-](https://bitcointalk.org/index.php?topic=1013.msg12341#msg12341)

What version is the one where this happened? Release build, or built it yourself? Which operating system?

Were you sending by IP or by Bitcoin Address?

When you sent 49.99, did it prompt you to pay a 0.01 fee?

There was a change in GetMinFee, but I can't see how it would cause this. It only starts to apply when a block gets huge.

The reason for the difference in block number is the number displayed was reduced by 1 in 0.3.11 because it made more sense that way.

##### BitcoinTalk

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

##### 2010-09-10 00:46:37 UTC - [-](https://bitcointalk.org/index.php?topic=1013.msg12342#msg12342)

I think I know what happened. Doubleclick on the generated transaction. It probably has a sub-0.01 transaction fee in it.

Someone has been paying a 0.00000010 transaction fee. I don't think you can even set that with -paytxfee, I think you'd have to modify the code to do it. Your generated block is worth 50.00000010, so when you try to send the whole thing you have 0.00000010 left over for the change, which triggers the dust spam 0.01 fee.

It would normally be harmless except in this corner case. I should add a special case to CreateTransaction to handle this.

##### BitcoinTalk

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

##### 2010-09-10 17:12:33 UTC - [-](https://bitcointalk.org/index.php?topic=1013.msg12368#msg12368)

The fix is in SVN rev 151.

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

##### BitcoinTalk

#### Re: Auto-detect for 128-bit 4-way SSE2

##### 2010-09-10 18:11:06 UTC - [-](https://bitcointalk.org/index.php?topic=1007.msg12372#msg12372)

[Quote from: teknohog on September 09, 2010, 07:32:05 PM](https://bitcointalk.org/index.php?topic=1007.msg12336#msg12336)

_Since the function CallCPUID function contains x86 assembler, it breaks the build on other architectures. I've changed line 2770 in main.cpp to

#if defined(GNUC) && defined(CRYPTOPPX86ASM_AVAILABLE)

to make it compile again, at least on ARM._

Added in SVN rev 152

##### BitcoinTalk

#### Re: Running on a port other than 8333

##### 2010-09-12 17:40:20 UTC - [-](https://bitcointalk.org/index.php?topic=589.msg12483#msg12483)

[Quote from: lachesis on August 10, 2010, 03:24:55 PM](https://bitcointalk.org/index.php?topic=589.msg8544#msg8544)

It does not -- did my own tests.

Is there a way to open BerkeleyDB exclusive?

DBPRIVATE is the worst of both worlds. DBPRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.

I've dropped the DB_PRIVATE flag in rev 153.

##### BitcoinTalk

#### Re: RFC: remove DB_PRIVATE flag

##### 2010-09-12 18:00:39 UTC - [-](https://bitcointalk.org/index.php?topic=920.msg12484#msg12484)

Trying it without the DB_PRIVATE flag in rev 153. We need to keep an eye on what's different.

On Windows at least, it creates six db.001 - db.006 files with sizes from 24K to 4MB. It doesn't delete them on exit, it just leaves them behind.

The docs say it uses memory mapped files. I assume they have the same file permissions as the database files, so the same user access restrictions apply.

Tests on Windows private LAN download of 78500 blocks:

with DB_PRIVATE 20 minutes 51 seconds

without DB_PRIVATE 20 minutes 51 seconds

I wasn't expecting them to come out exactly the same.

##### BitcoinTalk

#### Re: Switch to GPL

##### 2010-09-12 19:24:53 UTC - [-](https://bitcointalk.org/index.php?topic=989.msg12494#msg12494)

If the only library is closed source, then there's a project to make an open source one.

If the only library is GPL, then there's a project to make a non-GPL one.

If the best library is MIT, Boost, new-BSD or public domain, then we can stop re-writing it.

I don't question that GPL is a good license for operating systems, especially since non-GPL code is allowed to interface with the OS. For smaller projects, I think the fear of a closed-source takeover is overdone.

##### BitcoinTalk

#### Re: Memory leak

##### 2010-09-19 17:22:03 UTC - [-](https://bitcointalk.org/index.php?topic=1023.msg13201#msg13201)

Bouncing between 0 and 2 connections could be if it's connecting to itself. Are you using the "-connect" switch?

Did you compile it or is this a release build, and what version?

I'm not sure how the 200Kb/sec, since it waits at least a half second between connection attempts. How fast is it flickering between 0 and 2 connections? Faster than twice a second?

The wait function on linux is:

inline void Sleep(int64 n)

{

boost::thread::sleep(boost::getsystemtime() + boost::posix_time::milliseconds(n));

}

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

##### BitcoinTalk

#### Re: Issues building bitcoin on Windows 7

##### 2010-09-19 18:46:46 UTC - [-](https://bitcointalk.org/index.php?topic=1034.msg13206#msg13206)

The lines it's tripping on:

Code:

ERROR extern map<string, string> mapAddressBook;

ERROR extern CCriticalSection cs_mapAddressBook;

ERROR extern vector<unsigned char> vchDefaultKey;

OK extern bool fClient;

OK extern int nBestHeight;

OK extern unsigned int nWalletDBUpdated;

ERROR extern DbEnv dbenv;

So it's acting like nothing is defined, not even map and vector.

Yet, db.h is included by headers.h (and only there, nowhere else) which includes vector, map, util.h and everything before db.h.

Is VC trying to use precompiled headers and screwing it up? Could there be some leftover precompiled header files in your directory from previously failed attempts that it's finding and using?

There's an installer package now that makes it really easy to install MinGW. Don't use the latest version 4.5.0, use a few versions back like 4.4.1 (1.908.0) or 1.812.0. A setup program completely installs everything, it's not hard like it used to be. I think the only thing I had to do was rename make*.exe something to make.exe.

[http://tdm-gcc.tdragon.net/](http://tdm-gcc.tdragon.net/)

Off topic, but: It would be nice if someone would hack on getting tcatm's 4-way 128-bit SSE2 code working on Windows. There's something with MinGW's optimisation, I'm not sure but maybe a problem with 16-byte alignment on the stack, that makes it segfault. With some fiddling, I was able to get his code to work in a test program, but not in Bitcoin itself for some reason.

##### BitcoinTalk

#### Re: Bug? /usr/bin/bitcoind ""

##### 2010-09-19 19:58:11 UTC - [-](https://bitcointalk.org/index.php?topic=1063.msg13211#msg13211)

I don't know anything about any of the bug trackers. If we were to have one, we would have to make a thoroughly researched choice.

We're managing pretty well just using the forum. I'm more likely to see bugs posted in the forum, and I think other users are much more likely to help resolve and ask follow up questions here than if they were in a bug tracker. A key step is other users helping resolve the simple stuff that's not really a bug but some misunderstanding or confusion.

I keep a list of all unresolved bugs I've seen on the forum. In some cases, I'm still thinking about the best design for the fix. This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them.

##### BitcoinTalk

#### Re: The case for removing IP transactions

##### 2010-09-19 21:49:30 UTC - [-](https://bitcointalk.org/index.php?topic=1048.msg13219#msg13219)

Probably best to disable receiving by IP unless you specifically intend to use it. This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts. Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases. If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy. If you use a privacy proxy, man-in-the-middle risk is unacceptably high. If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156. The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address". Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending. If there's a better name for the switch, we can change it again.

##### BitcoinTalk

#### Re: Message Encryption as a built-in feature?

##### 2010-09-19 22:47:00 UTC - [-](https://bitcointalk.org/index.php?topic=1032.msg13221#msg13221)

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

##### BitcoinTalk

#### Re: Always pay transaction fee?

##### 2010-09-23 16:08:35 UTC - [-](https://bitcointalk.org/index.php?topic=994.msg13829#msg13829)

[Quote from: satoshi on September 08, 2010, 05:30:14 PM](https://bitcointalk.org/index.php?topic=994.msg12237#msg12237)

The current threshold is 200KB per block, or about 1000 transactions per block. I think it should be lowered to 50KB per block. That would still be more than 100 times the average transactions per block.

I implemented this change in SVN rev 157.

The reason I previously made it so high was to allow very large transactions without hitting the transaction fee. The threshold was around 26,000 BTC for transactions made of 50 BTC generated coins. Even though it was 100 times easier to generate back then, only a few people ever encountered the fee at that level. The new threshold puts it at around 11,000 BTC for sending generated coins. It would mostly only be reached with generated bitcoins. If you bought your bitcoins, they'll be denominated in larger transactions and won't be anywhere near the fee limit, unless you bought them in several hundred separate transactions. Even if you do reach the fee level, you only have to pay it once to bundle your little transactions together.

##### BitcoinTalk

#### Internal version number

##### 2010-09-23 16:19:08 UTC - [-](https://bitcointalk.org/index.php?topic=1269.msg13831#msg13831)

In the next release (0.3.13), I'm going to change the format of the internal version number integer from 313 to 31300, for instance 31305 = 0.3.13.5. The last number represents changes on the SVN between releases and ought to be properly represented in the version number. Otherwise, it would be a pain if we had a mistake or something in one of the sub versions that needed to be worked around.

##### BitcoinTalk

#### Re: How To Make a Distributed BitCoin Escrow Service

##### 2010-09-26 17:34:26 UTC - [-](https://bitcointalk.org/index.php?topic=1283.msg14136#msg14136)

It's not implemented yet, but the network can support a transaction that requires two signatures. It's described here:

[http://BitcoinTalk.org/index.php?topic=750.0](http://bitcointalk.org/index.php?topic=750.0)

It's absolutely safer than a straight payment without escrow, but not as good as a human arbitrated escrow, assuming you trust the human enough.

In this kind of escrow, a cheater can't win, but it's still possible for you to lose. It at least takes away the profit motive for cheating you. The seller is assured that the money is reserved for him, while the buyer retains the leverage that the seller hasn't been paid yet until completion.

##### BitcoinTalk

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

##### 2010-09-30 16:38:53 UTC - [-](https://bitcointalk.org/index.php?topic=1306.msg14714#msg14714)

As you figured out, the root problem is we shouldn't be counting or spending transactions until they have at least 1 confirmation. 0/unconfirmed transactions are very much second class citizens. At most, they are advice that something has been received, but counting them as balance or spending them is premature.

I made changes so they show up in lighter print, with the credit amount in square brackets like [+1.23], and the amount not counted towards your balance and not available for spending. This doesn't apply to transactions you sent, which you implicitly trust, since you wrote them.

I didn't make it (+1.23) because parenthesis in accounting means negative. I hope square brackets is different enough to be clear what is meant.

The JSON-RPC interface can still see 0/unconfirmed if it wants by specifying 0 confirmations.

I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC shortly.

If you have any of these transactions in your wallet, do not send any payments until you've upgraded to 0.3.13, which will be coming soon.

If you've already sent any of these transactions, or you're the creator of them, then use theymos' patch or make the following change and use it to send your clean transactions to a new wallet to clean things up.

change:

if (pcoin->GetDepthInMainChain() < 1 && pcoin->GetDebit() <= 0)

continue;

to:

if (pcoin->GetDepthInMainChain() < 1)

continue;

##### BitcoinTalk

#### 0.3.13 RC1 for Windows, please test

##### 2010-09-30 17:04:15 UTC - [-](https://bitcointalk.org/index.php?topic=1322.msg14722#msg14722)

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

[http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe)

- don't count or spend payments until they have 1 confirmation

[http://BitcoinTalk.org/index.php?topic=1306.0](http://bitcointalk.org/index.php?topic=1306.0)

- internal version number from 312 to 31300

- only accept transactions sent by IP address if -allowreceivebyip is specified

- dropped DB_PRIVATE Berkeley DB flag

- fix problem sending the last cent with sub-cent fractional change

- auto-detect whether to use 128-bit 4-way SSE2 on Linux

Gavin Andresen:

- option -rpcallowip= to accept json-rpc connections from another machine

- clean shutdown on SIGTERM on Linux

##### BitcoinTalk

#### Re: BitCoin Wikipedia page DELETED!!!

##### 2010-09-30 17:50:32 UTC - [-](https://bitcointalk.org/index.php?topic=652.msg14729#msg14729)

If you do, I think it should be a very brief, single paragraph article like 100 words or less that simply identifies what Bitcoin is.

I wish rather than deleting the article, they put a length restriction. If something is not famous enough, there could at least be a stub article identifying what it is. I often come across annoying red links of things that Wiki ought to at least have heard of.

The article could be as simple as something like:

"Bitcoin is a peer-to-peer decentralised /link/electronic currency/link/."

The more standard Wiki thing to do is that we should have a paragraph in one of the more general categories that we are an instance of, like Electronic Currency or Electronic Cash. We can probably establish a paragraph there. Again, keep it short. Just identifying what it is.

##### BitcoinTalk

#### Re: Prioritized transactions, and tx fees

##### 2010-09-30 18:11:56 UTC - [-](https://bitcointalk.org/index.php?topic=1314.msg14732#msg14732)

It ramps up the fee requirement as the block fills up:

<50KB free

50KB 0.01

250KB 0.02

333KB 0.03

375KB 0.04

etc.

It's a typical pricing mechanism. After the first 50KB sells out, the price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At some price, you can pretty much always get in if you're willing to outbid the other customers.

Just including the minimum 0.01 goes a long way.

##### BitcoinTalk

#### Re: Prioritized transactions, and tx fees

##### 2010-09-30 18:22:22 UTC - [-](https://bitcointalk.org/index.php?topic=1314.msg14734#msg14734)

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

##### BitcoinTalk

#### Re: Remote RPC access

##### 2010-09-30 18:27:41 UTC - [-](https://bitcointalk.org/index.php?topic=1291.msg14736#msg14736)

It can be safe if you're using it over your own LAN, like if you have multiple servers at a location that talk to each other.

0.3.13 RC1 is available for Windows:

[http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe)

##### BitcoinTalk

#### Re: 0.3.13 RC1 for Windows, please test

##### 2010-10-01 00:32:46 UTC - [-](https://bitcointalk.org/index.php?topic=1322.msg14787#msg14787)

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

##### BitcoinTalk

#### Version 0.3.13, please upgrade

##### 2010-10-01 00:34:35 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg14788#msg14788)

Version 0.3.13 is now available. You should upgrade to prevent potential problems with 0/unconfirmed transactions. Note: 0.3.13 prevents problems if you haven't already spent a 0/unconfirmed transaction, but if that already happened, you need 0.3.13.2.

Changes:

- Don't count or spend payments until they have 1 confirmation.

- Internal version number from 312 to 31300.

- Only accept transactions sent by IP address if -allowreceivebyip is specified.

- Dropped DB_PRIVATE Berkeley DB flag.

- Fix problem sending the last cent with sub-cent fractional change.

- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.

Gavin Andresen:

- Option -rpcallowip= to accept json-rpc connections from another machine.

- Clean shutdown on SIGTERM on Linux.

Download:

[http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.13/)

(Thanks Laszlo for the Mac OSX build!)

Note:

The SSE2 auto-detect in the Linux 64-bit version doesn't work with AMD in 64-bit mode. Please try this instead and let me know if it gets it right:

[http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz)

You can still control the SSE2 use manually with -4way and -4way=0.

Version 0.3.13.2 (SVN rev 161) has improvements for the case where you already had 0/unconfirmed transactions that you might have already spent. Here's a Windows build of it:

[http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe](http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe)

##### BitcoinTalk

#### Re: Version 0.3.13

##### 2010-10-03 18:17:06 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15102#msg15102)

[Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM](https://bitcointalk.org/index.php?topic=1327.msg14997#msg14997)

_That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.

I still have to add the "-4way" switch._

Forgot to say, I suspected the detect might not work on 64-bit AMD. I found it hard to believe but AMD reports a different model number in 64-bit mode.

Could you grep CPUID your debug.log and tell me what it says? (and anyone else with 64-bit AMD) And what AMD chip do you have?

Do all AMDs that support 64-bit have the better SSE2 hardware also?

##### BitcoinTalk

#### Re: Version 0.3.13, please upgrade

##### 2010-10-03 19:39:06 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15110#msg15110)

Could a few people please run this special build? It'll amnesty the dust spam transactions, which will clear up the 0/unconfirmed problem for now. We really just need one block letting them through to clear up the previous transactions. Post if you generate a block with this.

These are binaries only. The linux version is 64-bit only.

[http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-win32.zip)

[http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.13.1-specialbuild-linux64.tar.gz)

SHA1 fb7c66270281ed058c570627cf7baff0bdc16e5d bitcoin-0.3.13.1-specialbuild-win32.zip

SHA1 9fc44ea5f2109618073e2cfd887e2cc266eb31a9 bitcoin-0.3.13.1-specialbuild-linux64.tar.gz

The linux 64-bit version includes a change to the cpuid 4-way 128-bit SSE2 autodetect for AMD in 64-bit mode, if you'd like to test that and see if that's better.

##### BitcoinTalk

#### Re: Version 0.3.13, please upgrade

##### 2010-10-03 19:49:32 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15112#msg15112)

[Quote from: tcatm on October 03, 2010, 07:45:45 PM](https://bitcointalk.org/index.php?topic=1327.msg15111#msg15111)

983 Mhash/s box.

Seriously? What hardware is that?

##### BitcoinTalk

#### Re: Version 0.3.13, please upgrade

##### 2010-10-03 20:02:24 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15116#msg15116)

Code:

diff -u old\main.cpp new\main.cpp

--- old\main.cpp Sun Oct 03 20:57:20 2010

+++ new\main.cpp Sun Oct 03 20:57:54 2010

@@ -2831,6 +2831,10 @@

bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||

(fAMD && nFamily * 10000 + nModel >= 160010));

+ // AMD reports a lower model number in 64-bit mode

+ if (fAMD && sizeof(void*) > 4 && nFamily * 10000 + nModel >= 160004)

+ fUseSSE2 = true;

+

static bool fPrinted;

if (!fPrinted)

{

@@ -2989,6 +2993,17 @@

// Transaction fee based on block size

int64 nMinFee = tx.GetMinFee(nBlockSize);

+ //////// temporary code

+ if (nBlockSize < MAXBLOCKSIZE_GEN / 10 && GetWarnings("statusbar") == "")

+ {

+ if (nBestHeight < 91000)

+ nMinFee = 0;

+ if (nBestHeight < 100000 && nTxSize < 2000)

+ nMinFee = 0;

+ if (nBestHeight < 110000 && nBestHeight % 10 == 0)

+ nMinFee = 0;

+ }

+ //////// temporary code

map<uint256, CTxIndex> mapTestPoolTmp(mapTestPool);

if (!tx.ConnectInputs(txdb, mapTestPoolTmp, CDiskTxPos(1,1,1), pindexPrev, nFees, false, true, nMinFee))

diff -u old\serialize.h new\serialize.h

--- old\serialize.h Sun Oct 03 20:57:45 2010

+++ new\serialize.h Sun Oct 03 20:57:54 2010

@@ -22,8 +22,8 @@

class CAutoFile;

static const unsigned int MAX_SIZE = 0x02000000;

-static const int VERSION = 31300;

-static const char* pszSubVer = "";

+static const int VERSION = 31301;

+static const char* pszSubVer = " test1";

##### BitcoinTalk

#### Re: Version 0.3.13, please upgrade

##### 2010-10-03 20:54:07 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15136#msg15136)

[Quote from: theymos on October 03, 2010, 08:09:51 PM](https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118)

ArtForz is already running with no fees, and he has 20-30% of the network's CPU power. The person who originally sent the broken transactions deleted his wallet, though, and the network has forgotten these historical transactions, so any transactions based on this won't confirm.

Transactions aren't accepted or displayed as 0/unconfirmed until your node has a path of transactions back to the block chain.

Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.

If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.

[Quote from: theymos on October 03, 2010, 08:09:51 PM](https://bitcointalk.org/index.php?topic=1327.msg15118#msg15118)

The person who originally sent the broken transactions deleted his wallet

Sigh... why delete a wallet instead of moving it aside and keeping the old copy just in case? You should never delete a wallet.

[Quote from: tcatm on October 03, 2010, 08:10:47 PM](https://bitcointalk.org/index.php?topic=1327.msg15119#msg15119)

It's running. Should find a block within 3 hours.

It may take a while to collect re-broadcast transactions. It'll help if you can accept inbound connections so you'll be listening to more nodes. Even if you find a block in 3 hours, keep it running continuously for a few days at least.

##### BitcoinTalk

#### Re: [PATCH] increase block size limit

##### 2010-10-03 21:07:28 UTC - [-](https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139)

[Quote from: theymos on October 03, 2010, 08:28:39 PM](https://bitcointalk.org/index.php?topic=1347.msg15126#msg15126)

Applying this patch will make you incompatible with other Bitcoin clients.

+1 theymos. Don't use this patch, it'll make you incompatible with the network, to your own detriment.

We can phase in a change later if we get closer to needing it.

Martii Malmi (AKA Sirius) “COPA trial” email #235

Date: Sun, 03 Oct 2010 21:27:29 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: SMF php code

To: Martti Malmi <mmalmi@cc.hut.fi>

I noticed my custom captcha stuff is gone. I guess it got lost in an

upgrade? What are we doing for captcha now? If we only have default

captcha, we'd be getting flooded with spam accounts. Do I need to

re-integrate the custom captcha stuff or do we have another solution now?

##### BitcoinTalk

#### Re: How to overthrow the GPU Oligarchs

##### 2010-10-03 21:30:04 UTC - [-](https://bitcointalk.org/index.php?topic=1332.msg15142#msg15142)

[Quote from: theymos on October 02, 2010, 06:11:11 AM](https://bitcointalk.org/index.php?topic=1332.msg14966#msg14966)

[Quote from: lzsaver on October 02, 2010, 05:49:47 AM](https://bitcointalk.org/index.php?topic=1332.msg14960#msg14960)

_Can you tell more about it:

"they have to do weird things with extraNonce, which increases the size of the block header"._

When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.

This is the point of confusion. extraNonce is not part of the block header, it is part of the first transaction. It does not slow down your hashing. It does not change the size of the header.

We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed. It doesn't.

extraNonce never needs to be very big. We could reset it every second whenever the time changes if we wanted. Worst case, if you didn't want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.

Separate machines are automatically collision proof because they have different generated public keys in the first transaction. That also goes for each thread too.

##### BitcoinTalk

#### Re: Version 0.3.13, please upgrade

##### 2010-10-03 21:43:20 UTC - [-](https://bitcointalk.org/index.php?topic=1327.msg15147#msg15147)

ShadowOfHarbringer, is yours faster with -4way?

If it is, then I'm thinking that any AMD that supports 64-bit has 128-bit SSE2.

The specialbuild version I posted here looks for model 4 or higher. If yours is faster with -4way, then I should change it to always use SSE2 with any AMD with 64-bit.