I added the cached SHA256 state idea to the SVN, rev 113. The speedup is about 70%. I credited it to tcatm based on your post in the x64 thread.

I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon as it runs it crashes. It says its for MASM (Microsoft's assembler) and the sample command line they give looks like Visual C++. Does it only work with the MSVC and Intel compilers?

##### BitcoinTalk

#### Re: Proof-of-work difficulty increasing

##### 2010-07-27 03:04:58 UTC - [-](https://bitcointalk.org/index.php?topic=43.msg5990#msg5990)

New difficulty factor 244.213223092

+35%

I updated the first post.

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%

##### BitcoinTalk

#### Re: Bitcoin x86 for Windows

##### 2010-07-27 18:27:30 UTC - [-](https://bitcointalk.org/index.php?topic=572.msg6069#msg6069)

[Quote from: BlackEye on July 25, 2010, 10:12:23 PM](https://bitcointalk.org/index.php?topic=453.msg5774#msg5774)

_I was able to integrate the SHA256 functionality from Crypto++ 5.6.0 into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly code. Since Bitcoin was sending unaligned data to the block hash function, I had to change the MOVDQA instruction to MOVDQU.

I think using the SHA256 functionality from Crypto++ 5.6.0 is the way forward right now._

I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped it down to just SHA and 11 general dependency files. There shouldn't be any other crypto in there other than SHA.

I aligned the data fields and it worked. The ASM SHA-256 is about 48% faster. The combined speedup is about 2.5x faster than version 0.3.3.

I guess it's using SSE2. It automatically sets its build configuration at compile time based on the compiler environment.

It looks like it has some SSE2 detection at runtime, but it's hard to tell if it actually uses it to fall back if it's not available. I want the release builds to have SSE2. SSE2 has been around since the first Pentium 4. A Pentium 3 or older would be so slow, you'd be wasting your electricity trying to generate on it anyway.

This is SVN rev 114.

##### BitcoinTalk

#### Re: Bitcoin x86 for Windows

##### 2010-07-27 19:47:42 UTC - [-](https://bitcointalk.org/index.php?topic=572.msg6083#msg6083)

OK, thanks. I'd also like to know if it runs fine as long as you don't turn on Generate. You'd think as long as it doesn't actually execute any SSE2 instructions, it would still load. At least Pentium 3's could run it without generating.

##### BitcoinTalk

#### Re: Having problems specifing -datadir

##### 2010-07-28 20:58:26 UTC - [-](https://bitcointalk.org/index.php?topic=601.msg6268#msg6268)

It was able to reproduce this. The database doesn't like the relative path.

"bitcoind -datadir=./subdir getinfo" works against a running daemon, but trying to start the daemon as "bitcoind -datadir=./subdir" gets that exception.

I guess we should resolve the full path before passing it to the database.

It looks like you were the first one to ever use -datadir with a relative path.

##### BitcoinTalk

#### Re: Build error SVN r115 on my Mac: workaround

##### 2010-07-28 21:23:23 UTC - [-](https://bitcointalk.org/index.php?topic=604.msg6273#msg6273)

Was that the only thing I broke in the OSX build?! Does it actually work after just that one change?

I had to do that for makefile.vc also. It compiled, but SHA-256 didn't work correctly; it returned the same incorrect hash each time.

We'll disable it now, and if anyone figures out how to fix it, we can re-enable it then. It's still 1.7x faster from the midstate optimisation.

The Crypto++ ASM SHA-256 works with GCC on Linux and Windows (MinGW).

I uploaded this makefile.osx change to SVN. (let me know if that compiles now)

##### BitcoinTalk

#### Re: Difficulty

##### 2010-07-29 01:16:23 UTC - [-](https://bitcointalk.org/index.php?topic=587.msg6301#msg6301)

You were looking at the wrong code. Here's the code that applies:

Code:

bool CBlock::CheckBlock() const

{

// Check timestamp

if (nTime > GetAdjustedTime() + 2 * 60 * 60)

return error("CheckBlock() : block timestamp too far in the future");

bool CBlock::AcceptBlock()

{

// Check timestamp against prev

if (nTime <= pindexPrev->GetMedianTimePast())

return error("AcceptBlock() : block's timestamp is too early");

The timestamp is limited to up to 2 hours in the future. It can be earlier than the previous block, but it must be greater than the median of the last 11 blocks. The reason for doing it that way is so the time can get corrected in the next block if the previous block had the time too far in the future, like what happened.

##### BitcoinTalk

#### Re: Scalability and transaction rate

##### 2010-07-29 02:00:38 UTC - [-](https://bitcointalk.org/index.php?topic=532.msg6306#msg6306)

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.

[Quote from: bytemaster on July 28, 2010, 08:59:42 PM](https://bitcointalk.org/index.php?topic=532.msg6269#msg6269)

Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.

See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.

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

##### BitcoinTalk

#### Re: wiki registration email?

##### 2010-07-29 02:10:46 UTC - [-](https://bitcointalk.org/index.php?topic=338.msg6307#msg6307)

WTF? How did we get on that? AFAIK, the only e-mail is if you tell the forum to do notifications, and I guess the wiki registration. I'd consider turning off the forum notification e-mails, I don't know why we have that.

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

Date: Thu, 29 Jul 2010 03:18:56 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: Forum e-mail notifications and PBL blacklist and wiki registration

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

http://www.bitcoin.org/smf/index.php?topic=338.0

> of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.

>

> "Looks like bitcoin.org is listed on the PBL."

> http://www.spamhaus.org/pbl/query/PBL340779

I think our problem may be that we have forum notifications on, like

e-mail you when you receive a PM, but we don't have e-mail verification

of new accounts. Can someone put someone else's e-mail address without

verifying it, then have stuff sent there? We need to stop that right

away before it gets used for something bad. Either disallow all

notification, or make sure e-mail addresses are verified.

I'm more inclined to disallow notifications or anything where the forum

sends you e-mail. I kinda like not requiring e-mail verification. But

if that's the only way to make sure we don't send e-mails to un-verified

addresses, then we could do that.

If we request to get off of PBL, we'd better make sure we've got the

problem secured first.

I changed Registration->settings->registration of new members to "Member

Activation". I assume that means it e-mail verifies.

"Member Activation

When this option is enabled any members registering to the forum will

have a activation link emailed to them which they must click before they

can become full members"

I think that's the only way to make sure the forum can't be used to send

to other people's e-mail addresses and potentially use it to spam.

##### BitcoinTalk

#### ALERT Upgrade to 0.3.6

##### 2010-07-29 19:13:06 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6451#msg6451)

Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it was possible that bogus transactions could be displayed as accepted. Do not accept Bitcoin transactions as payment until you upgrade to version 0.3.6!

If you can't upgrade to 0.3.6 right away, it's best to shut down your Bitcoin node until you do.

Also in 0.3.6, faster hashing:

- midstate cache optimisation thanks to tcatm

- Crypto++ ASM SHA-256 thanks to BlackEye

Total generating speedup 2.4x faster.

Download:

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

Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.

##### BitcoinTalk

#### Re: ALERT version 0.3.6

##### 2010-07-29 19:55:51 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6469#msg6469)

Haven't had time to update the SVN yet. Wait for 0.3.6, I'm building it now. You can shut down your node in the meantime.

##### BitcoinTalk

#### Re: ALERT version 0.3.6

##### 2010-07-29 20:30:15 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6480#msg6480)

SVN is updated with version 0.3.6.

Uploading Windows build of 0.3.6 to Sourceforge now, then will rebuild linux.

##### BitcoinTalk

#### Re: ALERT Upgrade to 0.3.6 ASAP!

##### 2010-07-29 21:20:38 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6490#msg6490)

0.3.6 Linux build is back to the old makefile.unix. It static links libjpeg so that shouldn't be a problem.

Is that working better?

If you got 22DbRunRecoveryException and you've used someone else's build before, you may need to delete (or move the files somewhere else) database/log.000000*

Windows and Linux users: if you got 0.3.5 you still need to upgrade to 0.3.6.

##### BitcoinTalk

#### Re: ALERT Upgrade to 0.3.6 ASAP!

##### 2010-07-29 21:43:15 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6502#msg6502)

"./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11' not found (required by ./bitcoin)" isn't a new problem that started with 0.3.6 is it? This was built on the same OS installations as 0.3.0.

Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not upgrade anymore. I don't know when I might have time to reinstall to downgrade, but at least by not upgrading, it'll gradually fix itself.

##### BitcoinTalk

#### Re: Implementation bug prior to 0.3.6

##### 2010-07-29 22:04:15 UTC - [-](https://bitcointalk.org/index.php?topic=628.msg6508#msg6508)

Actually, it works well to just PM me. I'm the one who's going to be fixing it. If you find a security flaw, I would definitely like to hear from you privately to fix it before it goes public.

##### BitcoinTalk

#### Re: Transaction disappeared in the void...

##### 2010-07-29 22:08:31 UTC - [-](https://bitcointalk.org/index.php?topic=615.msg6512#msg6512)

If the transaction didn't go out immediately at first, like if you weren't connected at the time, it may take up to 2 hours to resend it. Long term, it does keep relentlessly sending it.

I'll shorten that length of time in a future version.

You do need to have downloaded the complete block chain (currently 71040 blocks) before you'll see any confirms. Same with the recipient.

##### BitcoinTalk

#### Re: Linux distribution download

##### 2010-07-29 22:17:24 UTC - [-](https://bitcointalk.org/index.php?topic=612.msg6516#msg6516)

Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It's a lot more work to downgrade than upgrade and I've been squeezed for time. Ubuntu is the most popular distro, so I'm staying with that.

##### BitcoinTalk

#### Re: ALERT Upgrade to 0.3.6 ASAP!

##### 2010-07-29 23:12:12 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6542#msg6542)

[Quote from: lachesis on July 29, 2010, 10:14:36 PM](https://bitcointalk.org/index.php?topic=626.msg6515#msg6515)

On Debian testing 32-bit, I get a few build errors, all resembling:

Code:

script.cpp:114: error: \u0091OPNOP1\u0092 was not declared in this scope_

_I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present.

If anyone else gets this error, the simplest solution is to "make clean" and retry the build._

We don't really need pre-compiled header. It only makes it compile slightly faster. I think I'll just get rid of it. Even still, you'd still need to remember to "make -f makefile.unix clean" or delete headers.h.gch one more time to get rid of the leftover file.

Damn that GLIBC_2.11. I thought I'd been careful not to accept any of the updates.

bitcoin-list

[bitcoin-list] Alert: upgrade to bitcoin 0.3.6

2010-07-30 06:02:38 UTC - [-](https://sourceforge.net/p/bitcoin/mailman/message/25843947/)

Please upgrade to 0.3.6 ASAP to get an important bugfix.

See the bitcoin.org homepage for download links.

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

Date: Fri, 30 Jul 2010 06:34:38 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: [bitcoin-list] Alert: upgrade to bitcoin 0.3.6

To: bitcoin-list@lists.sourceforge.net

Please upgrade to 0.3.6 ASAP to get an important bugfix.

See the bitcoin.org homepage for download links.

##### BitcoinTalk

#### Re: Bug: "Immature" coins lost in wallet.dat during transaction

##### 2010-07-30 19:19:05 UTC - [-](https://bitcointalk.org/index.php?topic=642.msg6701#msg6701)

I don't get how it let you send if it was not matured. Your balance would have been lower than the amount. It would have said balance 0.01, right? If I try that it says "you don't have enough money" or "Insufficient funds" from the command line.

How many blocks did it say it had left to mature when you sent?

There's a chance it might still go through.

Have you copied or moved your wallet.dat in any way?

##### BitcoinTalk

#### Re: [PATCH] implement 'listtransactions'

##### 2010-07-30 19:40:54 UTC - [-](https://bitcointalk.org/index.php?topic=611.msg6706#msg6706)

What are you needing to use listtransactions for?

The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.

When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like "0/unconfirmed 0:0:0 date comment debit 4 credit 0" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.

##### BitcoinTalk

#### Re: ALERT Upgrade to 0.3.6 ASAP!

##### 2010-07-30 19:53:06 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6711#msg6711)

[Quote from: knightmb on July 30, 2010, 07:24:07 PM](https://bitcointalk.org/index.php?topic=626.msg6702#msg6702)

I can only imagine the pain you went through to get these builds because I'm trying to build the program on a Ubuntu 9.04 box and so far I can't seem to find all the dependencies to compile no matter how much I keep installing packages and compiling source, LOL.

I can't understand why you're having so much pain. I just followed the instructions in build-unix.txt. I made a couple little corrections for Boost 1.37, which I'll put on SVN the next time I update it, noted below:

Dependencies

sudo apt-get install build-essential

sudo apt-get install libgtk2.0-dev

sudo apt-get install libssl-dev

sudo apt-get install libdb4.7-dev

sudo apt-get install libdb4.7++-dev

sudo apt-get install libboost-all-dev (or libboost1.37-dev)

wxWidgets

cd /usr/local

tar -xzvf wxWidgets-2.9.0.tar.gz

cd /usr/local/wxWidgets-2.9.0

mkdir buildgtk

cd buildgtk

make

sudo su

make install

ldconfig

added a comment in makefile.unix:

# for boost 1.37, add -mt to the boost libraries

LIBS= \

-Wl,-Bstatic \

-l boost_system \

-l boost_filesystem \

-l boostprogramoptions \

-l boost_thread \

-l db_cxx \

-l crypto \

-Wl,-Bdynamic \

-l gthread-2.0

##### BitcoinTalk

#### Re: ALERT Upgrade to 0.3.6 ASAP!

##### 2010-07-30 21:44:04 UTC - [-](https://bitcointalk.org/index.php?topic=626.msg6728#msg6728)

[Quote from: knightmb on July 30, 2010, 08:04:19 PM](https://bitcointalk.org/index.php?topic=626.msg6713#msg6713)

_So that last command should simply be

__sudo apt-get install libboost1.37-dev_

Except that wouldn't work for boost 1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.

Seems they changed everything around in Boost recently, "-mt" and all that, makes it hard.

BTW, I tried Boost 1.34 but it didn't have the boost.interprocess stuff.

Mac OSX version is available now. See bitcoin.org or the SourceForge link.

##### BitcoinTalk

#### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

##### 2010-07-31 00:29:20 UTC - [-](https://bitcointalk.org/index.php?topic=648.msg6751#msg6751)

That's amazing...

So are you saying you use 128-bit registers to SIMD four 32-bit data at once? I've wondered about that for a long time, but I didn't think it would be possible due to addition carrying into the neighbour's value.

##### BitcoinTalk

#### Webpage idea: Next predicted difficulty change

##### 2010-07-31 01:32:08 UTC - [-](https://bitcointalk.org/index.php?topic=651.msg6760#msg6760)

It would be neat if someone had a page (like that handy calculator at [http://www.alloscomp.com/bitcoin/calculator.php](http://www.alloscomp.com/bitcoin/calculator.php)) that projects what the next difficulty adjustment will be.

projected difficulty adjustment multiplier =

blockssincelast_adjustment / 2016

timesincelastadjustment / 14days

For instance, if it already got half way to the next adjustment in only 3.5 days instead of 7, we would expect difficulty to double:

(1008/2016) / (3.5/14) = 0.5/0.25 = 2.0

Also, it could show the predicted time when the next adjustment will occur, and tell when the last adjustment was and how much it changed.

##### BitcoinTalk

#### Re: Linux distribution download

##### 2010-07-31 14:38:52 UTC - [-](https://bitcointalk.org/index.php?topic=612.msg6822#msg6822)

It can be built with Boost 1.37 or later.

##### BitcoinTalk

#### Re: Linux version => No GUI after upgrade. WTF?

##### 2010-08-02 17:39:27 UTC - [-](https://bitcointalk.org/index.php?topic=655.msg7057#msg7057)

Did it print anything to the console? Are you sure you didn't run "bitcoind"?

Try version 0.3.7.

##### BitcoinTalk

#### Re: Mac Client Problems Outlined...

##### 2010-08-02 18:02:20 UTC - [-](https://bitcointalk.org/index.php?topic=660.msg7068#msg7068)

"Minimize to the tray instead of the taskbar" & "Minimize to the tray on close" must not be implemented yet on the Mac. We should grey them out in the next version.

##### BitcoinTalk

#### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6

##### 2010-08-02 19:02:46 UTC - [-](https://bitcointalk.org/index.php?topic=648.msg7084#msg7084)

Is it 2x fast on AMD and 1/2 fast on Intel?

[Quote from: tcatm on July 31, 2010, 10:12:38 AM](https://bitcointalk.org/index.php?topic=648.msg6797#msg6797)

Btw. Why are you using this alignup<16> function when attribute ((aligned (16))) will tell the compiler to align at compiletime?

Tried that, but it doesn't work for things on the stack. I ran some tests.

It doesn't even cause an error, it just doesn't align it.

##### BitcoinTalk

#### Re: Protocol Buffers for Bitcoin

##### 2010-08-02 20:22:08 UTC - [-](https://bitcointalk.org/index.php?topic=632.msg7090#msg7090)

The reason I didn't use protocol buffers or boost serialization is because they looked too complex to make absolutely airtight and secure. Their code is too large to read and be sure that there's no way to form an input that would do something unexpected.

I hate reinventing the wheel and only resorted to writing my own serialization routines reluctantly. The serialization format we have is as dead simple and flat as possible. There is no extra freedom in the way the input stream is formed. At each point, the next field in the data structure is expected. The only choices given are those that the receiver is expecting. There is versioning so upgrades are possible.

CAddress is about the only object with significant reserved space in it. (about 7 bytes for flags and 12 bytes for possible future IPv6 expansion)

The larger things we have like blocks and transactions can't be optimized much more for size. The bulk of their data is hashes and keys and signatures, which are uncompressible. The serialization overhead is very small, usually 1 byte for size fields.

On Gavin's idea about an existing P2P broadcast infrastructure, I doubt one exists. There are few P2P systems that only need broadcast. There are some libraries like Chord that try to provide a distributed hash table infrastructure, but that's a huge difficult problem that we don't need or want. Those libraries are also much harder to install than ourselves.

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

Date: Mon, 02 Aug 2010 21:56:06 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: [Fwd: no activation mail]

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

Oh great, now we're screwed.

We probably got spam blocked because we were allowing registrations

without e-mail verification. But now that we've enabled it, our

verification e-mails are blocked.

There could still be some existing user accounts created before the

registration requirement being used by spammers.

We're kind of in a jam here. Can you make sure there's nothing else you

can think of that might be acting as an open e-mail gateway or way for

spammers to use our system for putting out spam? Check the e-mail logs

and see if there's been a lot of traffic and what it's from. If you can

figure out what the problem was and shut it down, then after you're sure

it's fixed, request PBL to take us off the block list.

If there's a way to prohibit the forum from sending e-mail

notifications, maybe we should do that.

-------- Original Message --------

Subject: no activation mail

Date: Mon, 02 Aug 2010 22:30:35 +0200

From: Youri <youri.de.bruycker@telenet.be>

To: satoshin@gmx.com

Hey Satoshin,

I tried to register me at the bitcoinforum, but I didn't get an activation

mail.

Tried the resend activation code option a few times, changed the

mailadress from my telenet to my gmail and back, but no luck. Looked at my

spam folder but it's not there. So I guess something went wrong, could you

activate my account?

My username is Skull88.

Thanks in advance,

Youri

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

Date: Mon, 02 Aug 2010 22:08:22 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: Disabled some notifications

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

For "normal members" I disabled "Request notification on replies" and

"Request notification on new topics".

I'm pretty sure there's a notification option for when you receive PMs,

but I don't see a way to disable it. If we have to, I guess we could

edit the php code.

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

Date: Mon, 02 Aug 2010 22:09:20 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

Subject: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]

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

Here's the info about PBL again.

-------- Original Message --------

Subject: Forum e-mail notifications and PBL blacklist and wiki registration

Date: Thu, 29 Jul 2010 03:18:56 +0100

From: Satoshi Nakamoto <satoshin@gmx.com>

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

http://www.bitcoin.org/smf/index.php?topic=338.0

> of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.

>

> "Looks like bitcoin.org is listed on the PBL."

> http://www.spamhaus.org/pbl/query/PBL340779

I think our problem may be that we have forum notifications on, like

e-mail you when you receive a PM, but we don't have e-mail verification

of new accounts. Can someone put someone else's e-mail address without

verifying it, then have stuff sent there? We need to stop that right

away before it gets used for something bad. Either disallow all

notification, or make sure e-mail addresses are verified.

I'm more inclined to disallow notifications or anything where the forum

sends you e-mail. I kinda like not requiring e-mail verification. But

if that's the only way to make sure we don't send e-mails to un-verified

addresses, then we could do that.

If we request to get off of PBL, we'd better make sure we've got the

problem secured first.

I changed Registration->settings->registration of new members to "Member

Activation". I assume that means it e-mail verifies.

"Member Activation

When this option is enabled any members registering to the forum will

have a activation link emailed to them which they must click before they

can become full members"

I think that's the only way to make sure the forum can't be used to send

to other people's e-mail addresses and potentially use it to spam.

##### BitcoinTalk

#### Re: Builds for Ubuntu?

##### 2010-08-03 20:56:11 UTC - [-](https://bitcointalk.org/index.php?topic=454.msg7328#msg7328)

[Quote from: nimnul on August 03, 2010, 05:51:15 PM](https://bitcointalk.org/index.php?topic=454.msg7282#msg7282)

Is satoshi noWx patch in 0.3.7 already? Before that bitcoind required wx, and I never seen Satoshi announcing that it's in trunk

Yes, 0.3.7 has it. It was in rev 112.

##### BitcoinTalk

#### Re: Bitcoind x86 binary for CentOS

##### 2010-08-03 21:05:08 UTC - [-](https://bitcointalk.org/index.php?topic=685.msg7331#msg7331)

[Quote from: sgtstein on August 03, 2010, 05:30:37 PM](https://bitcointalk.org/index.php?topic=685.msg7275#msg7275)

I have successfully built it with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the initial block download to disk. 

I urge you not to use BDB 4.8. The database/log0000* files will be incompatible if anyone uses your build and then goes back to the official build.

##### BitcoinTalk

#### Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)

##### 2010-08-03 21:26:26 UTC - [-](https://bitcointalk.org/index.php?topic=689.msg7335#msg7335)

[Quote from: gavinandresen on August 03, 2010, 06:56:44 PM](https://bitcointalk.org/index.php?topic=689.msg7299#msg7299)

[Quote from: jgarzik on August 03, 2010, 06:09:08 PM](https://bitcointalk.org/index.php?topic=689.msg7288#msg7288)

bitcoin requires the Content-Length header, but several JSON-RPC libraries do not provide it. When the Content-Length header is absent, bitcoin returns 500 Internal Server Error.

Can you be more specific about which JSON libraries don't provide Content-Length ? It'd be nice to document that.

I guess we should try to support the case where there's no Content-Length parameter. I don't want to rip and replace streams though, even if it has to read one character at a time.

Edit: That is, assuming there actually are any libraries that don't support Content-Length.

##### BitcoinTalk

#### Re: What happens when network is split for prolonged time and reconnected?

##### 2010-08-03 22:45:07 UTC - [-](https://bitcointalk.org/index.php?topic=661.msg7356#msg7356)

creighto: I agree with that idea. After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance. It could tell if it's not hearing the hum of the world anymore.

[Quote from: knightmb on August 03, 2010, 07:02:13 PM](https://bitcointalk.org/index.php?topic=661.msg7303#msg7303)

[Quote from: gavinandresen on August 03, 2010, 06:38:44 PM](https://bitcointalk.org/index.php?topic=661.msg7293#msg7293)

Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.

Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),

In practice, splits are likely to be very asymmetrical. It would be hard to split the world down the middle. More likely it would be a single country vs the rest of the world, lets say a 1:10 split. In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days. Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.

[Quote from: knightmb on August 03, 2010, 07:02:13 PM](https://bitcointalk.org/index.php?topic=661.msg7303#msg7303)

If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?

There's no time limit. Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.

##### BitcoinTalk

#### Please upgrade to 0.3.8!

##### 2010-08-03 23:40:18 UTC - [-](https://bitcointalk.org/index.php?topic=696.msg7364#msg7364)

Version 0.3.8 adds an important security improvement. Everyone should upgrade to get this change.

The new safety feature displays a warning message in the status bar and locks down RPC if it detects a problem that may require an upgrade.

If it sees a longer chain, but it can't process it, then it knows something is wrong. It displays "WARNING: Displayed transactions may not be correct! You may need to upgrade." and makes most RPC commands return an error. It still keeps generating as normal, which is necessary for the stability of the network.

There were important security updates in the versions before this too, so if you haven't upgraded recently, it's extremely important that you upgrade now!

Also, don't forget, we recently added 2.4x faster generating thanks to tcatm's mid-state caching optimisation and BlackEye's help getting ASM SHA-256 working.

Download:

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

##### BitcoinTalk

#### Re: Bitcoind x86 binary for CentOS

##### 2010-08-04 00:09:32 UTC - [-](https://bitcointalk.org/index.php?topic=685.msg7372#msg7372)

[Quote from: knightmb on August 03, 2010, 11:46:46 PM](https://bitcointalk.org/index.php?topic=685.msg7365#msg7365)

There are two versions, one built from stock code, the other modified to accept up to 1,000 nodes (hence the super node name)

I'd rather you didn't make a build of the 1000 node connecting version available. It won't take very many people running that before we have to make another release just to limit the incoming connections.

##### BitcoinTalk

#### Re: Please upgrade to 0.3.8!

##### 2010-08-04 00:29:37 UTC - [-](https://bitcointalk.org/index.php?topic=696.msg7381#msg7381)

I guess SourceForge hasn't updated its mirrors yet. The files are there on the admin side, but not on the user side. I have no idea how long that will take. It's always been immediate in the past.

Edit: SourceForge is updated now.

##### BitcoinTalk

#### Re: Building initial transaction trust through "coin ripping"

##### 2010-08-04 00:40:40 UTC - [-](https://bitcointalk.org/index.php?topic=635.msg7385#msg7385)

The software is designed to support things like this. I was going to post details of the plans for Escrow, but since getting slashdotted I haven't had time.

##### BitcoinTalk

#### Re: Flood attack 0.00000001 BC

##### 2010-08-04 16:25:36 UTC - [-](https://bitcointalk.org/index.php?topic=287.msg7524#msg7524)

[Quote from: Insti on August 04, 2010, 02:58:31 PM](https://bitcointalk.org/index.php?topic=287.msg7498#msg7498)

It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01. The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn't claim to be practical for arbitrarily small micropayments.

##### BitcoinTalk

#### Re: Flood attack 0.00000001 BC

##### 2010-08-05 16:03:21 UTC - [-](https://bitcointalk.org/index.php?topic=287.msg7687#msg7687)

Forgot to add the good part about micropayments. While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.

I am not claiming that the network is impervious to DoS attack. I think most P2P networks can be DoS attacked in numerous ways. (On a side note, I read that the record companies would like to DoS all the file sharing networks, but they don't want to break the anti-hacking/anti-abuse laws.)

If we started getting DoS attacked with loads of wasted transactions back and forth, you would need to start paying a 0.01 minimum transaction fee. 0.1.5 actually had an option to set that, but I took it out to reduce confusion. Free transactions are nice and we can keep it that way if people don't abuse them.

That brings up the question: if there was a minimum 0.01 fee for each transaction, should we automatically add the fee if it's just the minimum 0.01? It would be awfully annoying to ask each time. If you have 50.00 and send 10.00, the recipient would get 10.00 and you'd have 39.99 left. I think it should just add it automatically. It's trivial compared to the fees many other types of services add automatically.

[Quote from: FreeMoney on August 04, 2010, 07:30:32 PM](https://bitcointalk.org/index.php?topic=287.msg7569#msg7569)

Does including more slow down your hashing rate?

No, not at all.

##### BitcoinTalk

#### Re: Flood attack 0.00000001 BC

##### 2010-08-05 16:30:20 UTC - [-](https://bitcointalk.org/index.php?topic=287.msg7694#msg7694)

Quote from: bytemaster

Payments would generally be advanced, say 1 BTC at a time and when the connection closes any "change" would be returned. This rule makes it impossible to pay for a simple "search query" with no further transactions.

One alternative is to use a round-up system. You pay for, say, 1000 pages or images or downloads or searches or whatever at a time. When you've used up your 1000 pages, you pay for another 1000 pages. If you only use 1 page, then you have 999 left that you may never use, but it's not a big deal because the cost per 1000 is still small.

Or you could pay per day. The first time you access the site on a given day, you pay for 24 hours of access.

Per 1000 or per day may be easier for consumers to get their heads around too. They worry about per item because it's harder to figure if it might add up too fast. Unlimited for 24 hours they know what the cost will be. Or if 1000 seems like plenty, they're not worrying that it's costing more with each click if they figure 1000 is more than they'll probably use.

##### BitcoinTalk

#### Re: Flood attack 0.00000001 BC

##### 2010-08-05 16:39:58 UTC - [-](https://bitcointalk.org/index.php?topic=287.msg7696#msg7696)

[Quote from: bytemaster on August 05, 2010, 03:39:19 PM](https://bitcointalk.org/index.php?topic=287.msg7684#msg7684)

The only solution to this problem is to make broadcasting of a transaction "non free". Namely, if you want me to include it you have to pay me. The net (no pun intended) result is that each client would need to pay other clients to whom they even send their transaction, not just the individual who gets it in a block. In this way the laws of economics take over and no one gets a free ride on the transaction broadcast system.

I don't know a way to implement that. The transaction fee to the block creator uses a special trick to include the transaction fee without any additional size. If there was a transaction for each transaction fee, then what about the transactions fees for the transaction fee's transaction?

##### BitcoinTalk

#### Re: Who's the Spanish jerk draining the Faucet?

##### 2010-08-05 17:06:03 UTC - [-](https://bitcointalk.org/index.php?topic=704.msg7703#msg7703)

Silently failing would look bad.

[Quote from: gavinandresen on August 04, 2010, 08:40:55 PM](https://bitcointalk.org/index.php?topic=704.msg7575#msg7575)

1. Rate limit based on the first byte of the IP address (79. or 81. in this case).

Definitely needed. What rate are you thinking of? Ultimately, it's better to rate limit it than to let it all drain out.

[Quote from: gavinandresen on August 04, 2010, 08:40:55 PM](https://bitcointalk.org/index.php?topic=704.msg7575#msg7575)

3. Rate limit based on last two domains of reverse DNS lookup of the IP address (rima-tde.net in this case).

That might work surprisingly well. If it works, it keeps them from hitting the rate limit, but the rate limit is there as the last line of defence.

[Quote from: gavinandresen on August 04, 2010, 08:40:55 PM](https://bitcointalk.org/index.php?topic=704.msg7575#msg7575)

4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone up 10 times in value since I started the Faucet).

Definitely time to lower it.

##### BitcoinTalk

#### Re: bitcoind transaction to ip address

##### 2010-08-05 17:28:40 UTC - [-](https://bitcointalk.org/index.php?topic=711.msg7705#msg7705)

It's not implemented.

It turned out nobody liked that mode of transfer anyway, so it hasn't had much development attention.

##### BitcoinTalk

#### Re: Transaction Overload Solution

##### 2010-08-05 17:38:21 UTC - [-](https://bitcointalk.org/index.php?topic=713.msg7706#msg7706)

I can't think of a way to implement that. All the transaction fees would be additional transactions. What about the transaction fees for the transaction fee's transaction?

##### BitcoinTalk

#### Re: Flood attack 0.00000001 BC

##### 2010-08-05 17:49:43 UTC - [-](https://bitcointalk.org/index.php?topic=287.msg7710#msg7710)

[Quote from: bytemaster on August 05, 2010, 04:46:52 PM](https://bitcointalk.org/index.php?topic=287.msg7699#msg7699)

_Right now the transaction fee address is left "blank" and the block generator fills it out.

Now you would fill it in with the address of the person you are asking to build the block._

If you're only going to have one person work on building the block, that could take days. Oh, do you mean send a different variation to each node with the tx fee written to them?

The way it is now, it's whoever builds this gets it.

If we needed to, we could have a BitTorrent-esque tit-for-tat for transaction broadcast. Relay paying transactions to me, or I won't relay them to you. It probably won't be an actual problem though. It only takes one node relaying like it should to cancel out 7 others greedily not relaying.

##### BitcoinTalk

#### Re: A proposal for a semi-automated Escrow mechanism

##### 2010-08-05 18:08:30 UTC - [-](https://bitcointalk.org/index.php?topic=645.msg7712#msg7712)

A transaction can be written that requires two signatures to spend it next. You write a payment that requires the signature of both the recipient and the sender to spend it. To release the escrow, you give the recipient the signature for your half, or the payee can return it by giving you his signed half. There's no mediator in this simple case. The recourse is to refuse to ever release it, essentially burning the money.

##### BitcoinTalk

#### Re: latency and locality

##### 2010-08-07 16:28:17 UTC - [-](https://bitcointalk.org/index.php?topic=723.msg8103#msg8103)

Once you get away from a system where each node's influence is proportional to their CPU power, then what else do you use to determine who is (approximately) one person?