中本聪在 BitcoinTalk 的发言

1. The initial network transaction that occurs when you first click Generate Coins.
2. The time between that initial network transaction and when the bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction field to inside it.
4. The time between when the bitcoin appears in the All Transfers list and when the Description is ready to change to Generated (50.00 matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x more blocks).
6. The time between when the Description says Generated (50.00 matures in x more blocks) to when it is ready to change to Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.Which stages require network connectivity, significant local CPU usage and or significant remote CPU usage? Do any of these stages have names?

sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)

Helpful suggestions, thanks.

Quote from: madhatter on December 09, 2009, 05:34:46 AM

- When the bitcoin software establishes a connection with a peer (client TCP socket) have the client send the handshake string. Right now you have the server (server TCP socket) send the handshake. My reasons for this are anonymity of course. It is far too easy for ISPs to portscan clients and detect they are running this program.

That's a good idea.  The side accepting the connection just needs to withhold from sending anything until it receives a valid handshake.  Any portscan would only get a dead connection that doesn't volunteer to identify itself.

Quote

- Use some sort of encryption during the handshake (sort of goes with the statement/request above) to obfuscate what the software is during DPI (deep packet inspection). I am really thinking about people in non-free (as in freedom) countries such as China/Iran.

I have thought about eventually SSLing all the connections.  I assume anything short of SSL would be pointless against DPI.  Maybe a better more immediate solution is to connect through TOR, which will be possible with 0.2.

Quote

- Some sort of an API is needed so that this system can be integrated with websites to provide instant-on services. A simple https receipt mechanism would do wonders. Have the client post each incoming payment to an https url with all of the relevant information and provide status updates. Also an outbound payment mechanism would be nice. So one could automate payments (and batch payments) outbound. Status could be returned via the https receipt interface.

That's one of the main things on the agenda after 0.2.

Quote

- Static port/Random port. Have a setting to randomly assign the port that it runs on. (also be able to set it statically for very restrictive firewalls).

Yeah, the other stealth stuff would be kinda pointless if it's always the same port number.

Quote

- UPnP support. Have the client automatically create the port forward on upstream routers. Enabled by default. Can be turned off in the options menu.

I'm looking forward to trying UPnP.  Do most P2P clients typically have UPnP enabled by default?

Quote

- Ability to compile a headless (console only) install for *NIX systems. Also have the ability to just run as a network service. Perhaps with a telnet-able port for control (or even a unix socket would be ok).

I'm still thinking about how best to structure the management interface.  Maybe command line commands to communicate with the background daemon to query transactions received and initiate sending transfers.  That would be more automation friendly.  Or what about an http interface on some port other than 80 to manage it with a browser?

Quote from: madhatter2 on December 10, 2009, 02:00:17 PM

Front ends can also be ran on clients with very low cpu power such as mobile phones.

That's a good approach for mobile.  Programmatic API used by PHP (any language) to present a web UI covers remote admin, mobile and any other client that can't be online all the time with a static IP.  It would be like webmail.  It would be easier for new users to get started if they only need to create an account on a website, not install software.

Quote

The app could be pre-seeded before downloading. Pre-seeding would also cure the TOR+IRC problem. I know that people will want to run this system over I2P+TOR.

Yeah, we can phase out IRC when there are enough static nodes to preprogram a seed list.  Once you get seeded, you don't need IRC.

Quote

Also you could pre-seed the blocks so they won't have to be downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL takes forever I couldn't imagine how long it would take when there are millions of blocks -- a lifetime).

There were some issues in 0.1.5 where the initial block download could get bogged down.  0.2 has code to make sure it goes smoothly.  It ought to take less than an hour, I think.  I need to hurry up and get 0.2 out the door.The blocks increase linearly, it'll be decades before it's millions.  In theory, the block download time should top out 8 months from now when Moore's Law will be growing faster than the block chain.

Quote

Can you give me CVS access or something? (If not, can I send you patches?) I'd like to help out.

It's SVN on sourceforge.  PM or e-mail me your sourceforge account and I'll give you access.

Quote

I am mostly a Linux/BSD guy and I would like to lend my expertise in those areas.

That's great because that's where I have less expertise.  For instance, I haven't researched the best way to do the "Start Bitcoin on system startup" feature on Linux.  On Windows, the option adds/removes an icon in the Startup folder.

Right, the SVN has the almost-release-candidate 0.2 source, which can also be built and run on Linux.   It hasn't been tested on FreeBSD.

Quote from: madhatter2 on December 11, 2009, 04:59:19 AM

If we can get to the point where we have a working backend process that will run on FreeBSD I can run always-on seeds.

Quote

I really think that having the download package contain a daily seed snapshot will improve the bootstrapping. I have seen instances on new test installs here where the application will sit with 0 connections / 1 block. Upon inspecting the debug.log I find that the IRC server (freenode, I believe) claims I am already connected and refuses to let me seed the application. (Just an example).

I see, that would happen with multiple nodes using the same NAT or VPN or some ISP that funnels everyone through a few proxy servers.  I just committed a fix to SVN for this.  If it gets "433" name already in use (it was error 433, right?), it'll retry with a non-address random username.

Quote

In any event, I would like to help. I have a lot of time and a project like this one is very exciting.

That's great, any help is really appreciated!

Quote from: madhatter2 on December 12, 2009, 06:34:21 AM

I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also have a PPC970 machine here as well so a PPC build would be possible as well). The windowing is native carbon too via wxwidgets! It is FAST! I had to create a new makefile (makefile.osx; based on makefile.unix of course.. given any thought to using autoconf?) and put some ifdef's into header.h. I have patches. I will keep toying around. I might try it on FreeBSD next.

Mac support would be nice.  wxWidgets really pays off for cross platform.

Please don't try PPC.  PPC is big-endian and Bitcoin is little-endian, there would be endless endian bugs making it harder for me to debug the network if there's a potentially byte-swapping node out there.  PPC is on its way out anyway.

Considered autoconf.  Autoconf is a necessity for large projects with a quagmire makefile, but I think we're small enough that it's more optimal without it.  I'd rather keep the makefile simple as long as possible.

Quote

I think that breaking bitcoin into two apps is ideal. A wxwidgets front end (since it is mostly all there) and a backend that binds to a control TCP socket. I have been reading over the source to see how hard it would be to break it apart and I think it should be fairly simple. Of course an API would have to be developed.

My head hurts just thinking about that.  Funnelling all the UI backend through a TCP connection would make everything twice as hard.  There's too much bandwidth between the UI and the internal data structures in order to keep the listview control updated, because of the way the listview control works.

I'd rather have command line control, that would get us remote admin and batch automation.

Quote from: madhatter2 on December 14, 2009, 03:01:39 PM

Can anyone shed some light here?g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include" -I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include" -I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch headers.h
...
ui.h:430: error: no matching function for call to 'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/include/wx-2.8/wx/textctrl.h:303: note: candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)

It looks like the implicit conversion from std::string to wxString isn't working. \u00a0That's used everywhere, the conversion needs to work.

wxString is complicated by supporting win32's 16-bit wchar and 8-bit ansi dual-compile. \u00a0You can get that problem on Windows if the "unicode" (meaning wchar) build is used, so that wxString is wchar and std::string is char.

It's probably some wxWidgets compile defines or build configuration. \u00a0What "configure" options did you use?

I'm not sure __WXMAC__ is the right define. \u00a0It may be the Mac Classic support that's complicating wxString, and we only want OSX. \u00a0Try __WXOSX__ (or see below)

http://docs.wxwidgets.org/stable/wx_cppconst.html

"There are two wxWidgets ports to Mac OS. One of them, wxMac, exists in two versions: Classic and Carbon. The Classic version is the only one to work on Mac OS version 8. The Carbon version may be built either as CFM or Mach-O (binary format, like ELF) and the former may run under OS 9 while the latter only runs under OS X. Finally, there is a new Cocoa port which can only be used under OS X. To summarize:

* If you want to test for all Mac platforms, classic and OS X, you should test both __WXMAC__ and __WXCOCOA__.

* If you want to test for any GUI Mac port under OS X, use __WXOSX__.

* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use __DARWIN__"

Quote from: madhatter2 on December 15, 2009, 05:21:09 AM

It is also throwing the same std::string issue on the latest version of Ubuntu Linux.

Then it must be something you're doing differently with building or configuring wxWidgets.

What options did you use on the wxWidgets "configure" script? The options I used are in build-unix.txt.

Quote

One question: how do I enable the debug.log? I have tried stopping bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It never seems to write to the file. Am I missing something?

Never heard of that happening. Is there anything in debug.log?If you touched the file, that sounds like something is there. Does the program have write access to the file?

The transfer is immediate if you send by IP address.  If you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it.

Also, the recipient needs to be synced up with the block chain before it'll see the received transaction.  That means the status bar at the bottom needs to say at least 33000 blocks, like "x connections  33200 blocks  x transactions".

Quote from: sirius-m on January 05, 2010, 01:20:06 AM

Would it be clearer if the status said "x confirmations", like:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations

Each block essentially means another node has confirmed that it agrees with all transactions up to that point.

Where it says "# blocks" in the status column I'm changing it to say "# confirmations".  That might be clearer.

If you doubleclick on the transaction you get a little more information.

The resync idea would go through your wallet and check it against the block index to find any transactions that your current computer doesn't realize are already spent.  That could happen if they were spent on another computer with a copy of the wallet file, or you had to restore the wallet to a backup from before they were spent.  Currently, the software just assumes it always knows whether its transactions are spent because it marks them spent in wallet.dat when it spends them.

A wallet merge tool is possible to implement but much less in demand once resync solves most of the problem.  With resync, you could do about the same thing by sending all the money from one wallet to the other.  The receiver would resync and discover all its overlapping coins were spent, then receive them in the new transaction.

That's the right way to do it as riX says.  The software can generate a new bitcoin address whenever you need one for each payment.  "Please send X bc to [single-use bitcoin address] to complete your order"  When the server receives that amount to the bitcoin address, that could trigger it to automatically fulfil the order or e-mail the shop owner.

Adding command line support is a high priority.  It's just a matter of getting the time to code it.

I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0.

There was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit.  The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0.

wxWidgets 2.9.0 is UTF-8.  We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support.

I compiled and ran on 64-bit Ubuntu 9.10 Karmic.

I think the only bug left is where the status number is mashed up.  I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen.  Haven't looked into it.

build-unix.txt is updated and two makefiles on SVN:
makefile.unix.wx2.8
makefile.unix.wx2.9

Unfortunately there's still no debian package for either version of wxWidgets we use.  They only have the wchar ("unicode") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string.  We use either ANSI wxWidgets 2.8, or wxWidgets 2.9.  So you still have to get it and build it yourself.

I uploaded this fix to the SVN.  It watches for spent coins and updates your wallet on load and also continuously as blocks come in.  I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once.

If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit).

Port forwarding forwards a port to one computer.  It tells the router which computer handles connections to that port.  So that's the computer receiving.

If you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent.  When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.

Someone should post their static IP so people can try out sending by IP and also give that user free money.

There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.

If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost.  A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation".

We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.

The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that.  For most of last year, we were hovering below the minimum.  On 30 Dec we broke above it and the algorithm adjusted to more difficulty.  It's been getting more difficult at each adjustment since then.

The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year.  That means you generate only 55% as many coins for the same amount of work.

The difficulty adjusts proportionally to the total effort across the network.  If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.

For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log.  It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block.  It gets adjusted every 2016 blocks, typically two weeks.  That's when it prints "GetNextWorkRequired RETARGET" in debug.log.

minimum    00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000

date, difficulty factor, % change
2009           1.00
30/12/2009     1.18   +18%
11/01/2010     1.31   +11%
25/01/2010     1.34    +2%
04/02/2010     1.82   +36%
14/02/2010     2.53   +39%
24/02/2010     3.78   +49%
08/03/2010     4.53   +20%
21/03/2010     4.57    +9%
01/04/2010     6.09   +33%
12/04/2010     7.82   +28%
21/04/2010    11.46   +47%
04/05/2010    12.85   +12%
19/05/2010    11.85    -8%
29/05/2010    16.62   +40%
11/06/2010    17.38    +5%
24/06/2010    19.41   +12%
06/07/2010    23.50   +21%
13/07/2010    45.38   +93%
16/07/2010   181.54  +300%
27/07/2010   244.21   +35%
05/08/2010   352.17   +44%
15/08/2010   511.77   +45%
26/08/2010   623.39   +22%

Quote from: Sabunir on February 05, 2010, 05:31:30 PM

Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?

That's not possible.  You've handed control of the money over to the recipient's keypair.  Only that key can control it.

It's similar to if you encrypt a file with AES and a strong password, and you lose the password.  The data is lost.

Thank you for the offer to help translate.  That is probably the best way you could help.

I will need to prepare the code for translation first.  wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard.  We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support.  I've done test builds with 2.9.0 and there is one bug left to fix.

What operating system are you using?  Windows, Linux 32-bit or 64 bit?

Split from another thread.
sirius-m

It's much easier to have a single binary and multiple .mo files.  It's too much maintenance work to have lots of build variations.  Once the software support is implemented, anyone could contribute translations.

wxWidgets uses the gettext standard.  You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file.  The program loads the .mo file at runtime and reskins all the strings.  Additional languages can be added to an existing program by adding .mo files without recompiling the program.

On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located.

Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next.

There's a small transaction fee for very large transactions.  The node that generates the block that contains the transaction gets the fee.

If the same money gets sent again, it won't incur the fee again.  If all you have is generated coins in your wallet, if you send them all in one huge transaction, it has to bundle hundreds of 50 bc coins together.  After that it's just one line to send the combined unit.

Quote from: soultcer on February 12, 2010, 02:31:50 PM

If you want, I can provide you with a precompiled binary.

Am I missing something?  Is there something wrong with the 32-bit linux precompiled binary on bitcoin.org?

The bitcoin binary in the distribution static links the wxWidgets library, and its shared links (openssl and GTK) are included in Ubuntu, so it can run without needing to be a .deb to pull down dependencies.

Since we're upgrading to wxWidgets 2.9.0 for UTF-8, which doesn't have a DEB package yet, we'll continue to need to static link it.

Quote from: theymos on February 12, 2010, 08:31:52 AM

Does the sending client send more BitCoins to account for the fee (so the recipient gets what he's expecting)?

Yes.

Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM

why do we even need fees ? i thougt the no-fees-feature was one of the advantages of bitcoin ?!

Almost all transactions are free.  A transaction is over the maximum size limit if it has to add up more than 500 of the largest payments you've received to make up the amount.  A transaction over the size limit can still be sent if a small fee is added.

The average transaction, and anything up to 500 times bigger than average, is free.

It's only when you're sending a really huge transaction that the transaction fee ever comes into play, and even then it only works out to something like 0.002% of the amount.  It's not money sucked out of the system, it just goes to other nodes.  If you're sad about paying the fee, you could always turn the tables and run a node yourself and maybe someday rake in a 0.44 fee yourself.

Quote from: Suggester on February 16, 2010, 02:15:49 AM

Satoshi, I figured it will take my modern core 2 duo about 20 hours of nonstop work to create \u0e3f50.00! With older PCs it will take forever. People like to feel that they "own" something as soon as possible, is there a way to make the generation more divisible? So say, instead of making \u0e3f50 every 20 hours, make \u0e3f5 every 2 hours?

I thought about that but there wasn't a practical way to do smaller increments.  The frequency of block generation is balanced between confirming transactions as fast as possible and the latency of the network.

The algorithm aims for an average of 6 blocks per hour.  If it was 5 bc and 60 per hour, there would be 10 times as many blocks and the initial block download would take 10 times as long.  It wouldn't work anyway because that would be only 1 minute average between blocks, too close to the broadcast latency when the network gets larger.

Quote from: Sabunir on February 16, 2010, 08:51:51 AM

. Perhaps it has to do with my connection's very high latency (2000ms or more on average)

2 seconds of latency in both directions should reduce your generation success by less than 1%.

Quote from: Sabunir on February 16, 2010, 08:51:51 AM

and/or my high packet loss (sometimes up to 10% loss)?

Probably OK, but I'm not sure.  The protocol is designed to resync to the next message, and messages get re-requested from all the other nodes you're connected to until received.  If you miss a block, it'll also keep requesting it every time another blocks comes in and it sees there's a gap.  Before the original release I did a test dropping 1 out of 4 random messages under heavy load until I could run it overnight without any nodes getting stuck.

Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM

Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?

No, each generated transaction uses a new, single-use address.

Nothing uses the address in the main window, it's just there for convenience for you to copy.  0.2.5 has a "New..." button next to it to make it easy to change each time you use it.

Quote from: Sabunir on February 25, 2010, 01:47:56 AM

I like them. Do they come in higher resolutions?

Yes, the original is 546x531 pixels.

It looks good at larger size too, but since the small icons are what you mostly always see, I wanted to judge it on those first.  I'll post larger sizes and full size a little later.

Quote from: Cdecker on February 27, 2010, 03:24:07 AM

How about an SVG version? That way we could automatically generate smaller and larger versions as needed.

I don't know how to do SVG, but I did the original very large, over 500 pixels across, so it can be scaled down.  I'll give the original when I'm finished.

I had to custom tweak each icon size so the vertical lines land square on their pixels, otherwise they're ugly blurry and inconsistent.  Such is the challenge of making icons.  The original will be good for scaling to custom sizes between 48 and 500 but not smaller.

Quote from: sirius-m on February 24, 2010, 06:17:35 PM

This is strange... When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there's something wrong with the build or something.

sirius-m debugged this, it was 64-bit related.

The fix is now available on SVN, file util.cpp.

Quote from: Xunie on May 14, 2010, 09:52:53 PM

I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.

That's a good idea.  At the very least a warning dialog explaining that it'll connect to the IP and send the information cleartext, giving the chance to cancel.

Quote from: Karmicads on May 01, 2010, 06:06:53 AM

A freenet URI is like this:http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf

There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=<bitcoinaddress>;amount=<amount>

Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332.  It would give an HTTP answer.

Quote from: DataWraith on May 02, 2010, 11:13:09 AM

A bitcoin-link should be more like mailto: than magnet: IMHO.

I think we can do that.

Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.

The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page.  Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in.  It would work just like a mailto: link that pops up a new email with the address filled in.

127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog.  You'd still have to press Send.  We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.

A little late, but in case anyone else has the same issue.  The compile dump had 2 warnings (that were 20 lines long) and 2 link errors.  The errors were:

Quote

obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function `wxArrayString::Item(unsigned long) const':
/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to `wxTheAssertHandler'obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In function `wxArrayString::Item(unsigned long) const':
/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)'

Those are probably due to switching to the release build of wxWidgets instead of debug.  They're moving towards only debug build and ditching the release build, so they probably don't care that their release build is broken by referring to non-existent assert stuff.  There's nothing to fear about the debug build.  It's fully suitable for releases.

bitcoind runs as a daemon and can either be controlled by command line or JSON-RPC.

Thanks madhatter and generica for detailing the instructions for building on freebsd.

Quote from: DataWraith on May 19, 2010, 07:52:42 PM

Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.

Almost but not quite.  Bitcoin uses EC-DSA, which can only do digital signing, not encryption.  RSA can do both, but I didn't use it because it's an order of magnitude bigger and would have been impractical.

The premise is false.Adding more transactions to the block you're working on does NOT slow down your generation rate.  When generate is scanning hashes, it only hashes the header of the block, which is constant size.  The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.

If necessary I can write code to make nodes prefer not to use a block if it doesn't contain enough of the transactions they know about.  A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in.  I doubt this will be necessary, since there's no real advantage for nodes not to include all transactions.

A second version would be a massive development and maintenance hassle for me.  It's hard enough maintaining backward compatibility while upgrading the network without a second version locking things in.  If the second version screwed up, the user experience would reflect badly on both, although it would at least reinforce to users the importance of staying with the official version.  If someone was getting ready to fork a second version, I would have to air a lot of disclaimers about the risks of using a minority version. This is a design where the majority version wins if there's any disagreement, and that can be pretty ugly for the minority version and I'd rather not go into it, and I don't have to as long as there's only one version.

I know, most developers don't like their software forked, but I have real technical reasons in this case.

Quote from: gavinandresen on June 17, 2010, 07:58:14 PM

I admire the flexibility of the scripts-in-a-transaction scheme, but my evil little mind immediately starts to think of ways I might abuse it.  I could encode all sorts of interesting information in the TxOut script, and if non-hacked clients validated-and-then-ignored those transactions it would be a useful covert broadcast communication channel.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

That's one of the reasons for transaction fees.  There are other things we can do if necessary.

Quote from: laszlo on June 17, 2010, 06:50:31 PM

How long have you been working on this design Satoshi?  It seems very well thought out, not the kind of thing you just sit down and code up without doing a lot of brainstorming and discussion on it first.  Everyone has the obvious questions looking for holes in it but it is holding up well 

Since 2007.  At some point I became convinced there was a way to do this without any trust required at all and couldn't resist to keep thinking about it.  Much more of the work was designing than coding.

Fortunately, so far all the issues raised have been things I previously considered and planned for.

Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM

Bitcoin looks ugly in Ubuntu's new default theme. It seems that some, but not all of the theme settings are being picked up. The unselected file menu should have light text with a dark background, but it incorrectly has light text with a light background. They're similar enough that it's unreadable on my display. It should be fixed before the next stable release.

This is now fixed in the SVN version.
1) Menu bar default color.
2) Balance bar not a different color.
3) Background behind bitcoin address and balance now the same color as toolbar.

I checked all the standard themes and it seems reasonable with all of them.

Ubuntu minimize,maximize,close buttons to the right:
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close

They've got it awfully buried considering 9 out of 10 users are used to having it on the right.

Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone.

Quote from: laszlo on June 21, 2010, 01:54:29 PM

I wonder though, is there a point where the difficulty of generating a new coinbase is so high that it would make more sense to try to recover keys for lost coins or steal other people's coins instead?  The difficulty of that is really high so for now it makes a lot more sense to generate but I just wonder what the real figures are.. would that ever become more productive?  Maybe Satoshi can address this..

Computers have to get about 2^200 times faster before that starts to be a problem.  Someone with lots of compute power could make more money by generating than by trying to steal.

Quote from: lachesis on June 22, 2010, 06:20:02 AM

It would be nice if the listtransactions RPC method were finished before the next release, though.

My fear is too many programmers would latch onto that for checking for received payments.  It can never be reliable that way.  The list/getreceivedbyaddress/label functions are the only way to do it reliably.

We shouldn't delay forever until every possible feature is done. There's always going to be one more thing to do.

Quote from: davidonpda on June 22, 2010, 06:23:26 PM

EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoinitcoin.exe in OnInit()

What operating system?

Normally when it does that it's because the directory where the data directory should go doesn't exist.  See if the "%appdata%" directory exists.

Do you get that error with 0.2 also?  It's hard to see how you could get that with 0.3 and not with 0.2 since there's nothing different in that regard.

Quote from: sirius-m on June 10, 2010, 01:51:16 PM

You can of course use services like vekja.net or mybitcoin.com on a mobile browser, depositing money there to the extent you trust them.

I think that's the best option right now.  Like cash, you don't keep your entire net worth in your pocket, just walking around money for incidental expenses.

They could make a smaller version of the site optimized for mobile.  If there was an app, it could be a front end to one of those, with the main feature being QR-code reader, or maybe there's already a universal QR-code reading app that web sites can be designed to accept scans from.

If there was an iPhone app that was just a front end for vekja or mybitcoin, not a big involved P2P, would apple approve it and if not, on what basis?  It could always be an Android app instead.  An app is not really necessary though, just a mobile sized website.

A web interface to your own Bitcoin server at home wouldn't be a solution for everyone.  Most users don't have a static IP, and it's too much trouble to set up port forwarding.

Quote from: satoshi on June 14, 2010, 08:39:50 PM

If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.If the hash breakdown came gradually, we could transition to a new hash in an orderly way.  The software would be programmed to start using a new hash after a certain block number.  Everyone would have to upgrade by that time.  The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.

Everybody needs to connect to the same IRC server and channel so they can find each other.

Quote from: Vasiliev on June 25, 2010, 11:50:15 PM

You may want to leave Freenode in as a fallback server -- if his server doesn't work, use Freenode's.

It might not be good if we suddenly rushed freenode with a ton of users all at once.

The fallback is our own seed system.

irc.lfnet.org is pretty old and has impressive uptime.  I think it's going to be fine.

We could take IRC out at some point if we want, but I'd rather ease into it and just test our own seed system as a backup for now, and I really like the complementary redundant attributes of the two different systems.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I need to give an updated .po file.

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

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

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

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

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

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

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

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

I updated them to 0.3.0.

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

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

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

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

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

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

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

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

I updated the first post with a link to rc2 for linux with the fix for this.  Please check that this is fixed for you.  Thanks!http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz

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

The listreceivedbyaddress and getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)

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

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

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

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

Quote from: hugolp on May 08, 2010, 10:38:51 AM

When I run bitcoin it becomes very sluggish, almost unusable. When I stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04 amd64 using ia32libs and the binary in bitcoin 0.20 tarball.

0.3.1 fixes that, sets the generate threads to the lowest priority.  Download links are on the homepage now.

Quote from: singpolyma on July 17, 2010, 10:19:48 PM

My coins disappeared, but I assume they'll come back when it's up to current?

Right, they'll re-appear when it's finished downloading all the blocks.

Quote from: llama on July 18, 2010, 12:03:29 AM

This is a good start, but still not impermeable.

I didn't say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards.

Quote

(for example, by refusing to propogate word of the transaction at the vending machine)

No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.  Think something like a credit card processor with a new job.  They would have many well connected network nodes.

So you drop a settings file in the ~/.bitcoin directory, that sounds better.  In the "no password is set" warning, it could tell you where the file is and what to do.

What is the most popular and common settings file format?

HTTP basic authentication should be considered.  In actual practice though, it's more work for web developers to figure out how to specify the password through some extra parameter in the HTTP or JSON-RPC wrapper than to just stick an extra parameter at the beginning of the parameter list.  What do you think?  Does HTTP basic authentication get us any additional benefits?  Moving it off the parameter list but then you still have to specific it in a more esoteric place I'm not sure is a net win.

Quote from: gavinandresen on July 19, 2010, 12:02:39 PM

I was confused for a bit because the password is given LAST on the command line, but FIRST in the JSON-RPC params list.  I agree that reading the command-line password from a file would be more convenient and more secure.

You're also confusing me, what do you mean?  Did I do something unintended?

Quote from: gavinandresen on July 21, 2010, 12:11:10 PM

I just did a quick survey of 20 .conf files in /etc on my debian system, and found:
1 file used "key value"
5 used "key=value"

Thanks for that survey!

I find "key value" a little unnatural.  There ought to be a more definite separator between key and value that suggests assignment.  The space people may just be getting lazy using their language's split function.
key=some full sentence with spaces in it.  # seems more clear
key some full sentence with spaces in it.  # than this

Allright then, lets go with self-parsed mapConfig, syntax:
# comment
key=value

file extension .conf.  What's the filename, is it ~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?

I think we better strip whitespace at the beginning and end of the key and the value.
# user who likes column formatted
k            = value
key         = value
longerkey =   this sentence would be this    # "this sentence would be this"
key = value   # guess this is ok too
nextkey = value
right = justified

The normal syntax should be "key=value", but you can't blame people for the occasional "key = value".

Quote from: gavinandresen on July 22, 2010, 01:11:26 AM

TODO: dialog box or debug.log warning if no rpc.user/rpc.password is set, explaining how to set.

In many of the contexts of this RPC stuff, you can print to the console with fprintf(stdout, like this:
#if defined(__WXMSW__) && wxUSE_GUI
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password> ", "Bitcoin", wxOK | wxICON_EXCLAMATION);
#else
fprintf(stdout, "Warning: rpc password is blank, use -rpcpw=<password> ");
#endif

Quote from: gavinandresen on July 23, 2010, 03:11:45 PM

Question for everybody:  should I add a section to the wiki page describing, in detail, how to do HTTP Basic authentication?  PHP and Python make is really easy-- just use the http://user:pass@host:port/URL syntax.

Yes, I think that would be really good so each dev doesn't have to figure it out themselves.  We need a simple example for each of Python, PHP and Java importing the json-rpc library and using it to do a getinfo or something, including doing the http authentication part.

Quote from: knightmb on July 23, 2010, 07:32:58 PM

Is there a safety reason to stop within the last 2000 blocks or can it be tweaked to stop at remaining 500 blocks for example?

Not really.  I'll change it to 1000 next time.

Quote from: knightmb on July 25, 2010, 07:44:02 PM

If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I'm still left without the Private Key.But from what you are saying, all I need is Public Key 654321 and I can spend coin pretending to be Public Key 123456.

You would still have to sign it with public key 654321.  You need to find a collision using a public key for which you know the private key.

When you claim a Bitcoin Address transaction, you give your public key that matches the hash, then you must sign it with that key.

Red's point is that it's easy to quickly generate insecure public keys which you could break and find the private key after you find a collision.

He points out that if the public key was required to be a secure one, one which must have required significant work to find the prime numbers, that would increase the strength above that of the hash function alone.  Someone trying to brute force would have to take time generating a key for each attempt.

Quote

Here is a paper that claims to find SHA-1 collisions in 2^52 crypto operations. And optimally secure hash would take 2^80 operations. 2^52 time is still large, but it is getting into cluster and botnet range.

2^80 is if you can use a birthday attack.  You can't use a birthday attack for this, so the difficulty is the full 2^160 bits.  Although, if you were trying to crack any one of 1 million (2^20) transactions, you could do a partial birthday attack 2^160/2^20 = 2^140.

Bitcoin Addresses are the only place where 160-bit hash is used.  Everything else is SHA-256.  They're calculated as:

bitcoinaddress = RIPEMD-160(SHA-256(publickey))

Correct me if I'm wrong (please, and I'll gladly eat crow) but I think it would be hard to use an analytical attack on RIPEMD-160 in this case.  An analytical attack prescribes a certain range or pattern of inputs to try that will greatly increase your chance of finding a collision.  Here, you don't have that kind of control over RIPEMD-160's input, because the input is the output of SHA-256.  If an analytical attack helps you find an input to RIPEMD-160 that produces a collision, what are you going to do with it?  You still have to get SHA-256 to output that value, so you would still have to break SHA-256 too.

For brute force, RIPEMD-160(SHA-256(x)) is no stronger than RIPEMD-160 alone.  But for analytical attack, it seems like you must analytical attack both RIPEMD-160 and SHA-256.  If I'm wrong, then the strength is the same as RIPEMD-160 and the SHA-256 only serves as one round of key strengthening.

Quote from: lachesis on July 25, 2010, 07:52:35 PM

+1 to you for having such a long password that you found this bug.

Uploaded to SVN as rev 110.

Quote from: BitLex on July 25, 2010, 08:45:38 PM

i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying to fopen(http://username:password@localhost:8332/)), nor my curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to work.

That's strange, didn't someone just say that was supposed to work?  (what library was he using?)  Post if you figure out what wrong.

I hope it's not going to put up this much of a fight for all PHP users.

Looks like we've got the Fortran scenario already.

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.

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

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

Quote from: lachesis on July 29, 2010, 10:14:36 PM

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.

Quote from: knightmb on July 30, 2010, 07:24:07 PM

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
../configure --with-gtk --enable-debug --disable-shared --enable-monolithic
make
sudo su
make install
ldconfigadded 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 boost_program_options \
-l boost_thread \
-l db_cxx \
-l crypto \
-Wl,-Bdynamic \
-l gthread-2.0

Quote from: knightmb on July 30, 2010, 08:04:19 PM

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.

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

Quote from: tcatm on July 31, 2010, 10:12:38 AM

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.

Quote from: nimnul on August 03, 2010, 05:51:15 PM

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.

Quote from: sgtstein on August 03, 2010, 05:30:37 PM

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.

Quote from: gavinandresen on August 03, 2010, 06:56:44 PM

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.

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

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

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.

Quote from: knightmb on August 03, 2010, 11:46:46 PM

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.

Quote from: Insti on August 04, 2010, 02:58:31 PM

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.

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

Does including more slow down your hashing rate?

No, not at all.

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.

Quote from: bytemaster on August 05, 2010, 03:39:19 PM

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?

Silently failing would look bad.

Quote from: gavinandresen on August 04, 2010, 08:40:55 PM

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

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

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.

Quote from: bytemaster on August 05, 2010, 04:46:52 PM

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.

It's the same situation as gold and gold mining.  The marginal cost of gold mining tends to stay near the price of gold.  Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange.I think the case will be the same for Bitcoin.  The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used.  Therefore, not having Bitcoin would be the net waste.

Quote from: gridecon on August 06, 2010, 04:48:00 PM

As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins.

Each node's influence on the network is proportional to its CPU power.  The only way to show the network how much CPU power you have is to actually use it.

If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it.  IP addresses... much easier to get lots of them than CPUs.

I suppose it might be possible to measure CPU power at certain times.  For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes.  You could still prove your total power at given times without running it all the time.  I'm not sure how that could be implemented though.  There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back.

Proof-of-work has the nice property that it can be relayed through untrusted middlemen.  We don't have to worry about a chain of custody of communication.  It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself.

Quote from: jgarzik on August 05, 2010, 07:00:30 PM

Due to that recourse, it is unlikely to be used as an escrow mechanism 

Really?  Do you think people won't be able to understand the benefit?  (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.)

Quote from: impossible7 on August 06, 2010, 11:37:20 AM

CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp.

Sorry about that.  CRITICAL_BLOCK isn't perfect.  You have to be careful not to break or continue out of it.  There's an assert that catches and warns about break.  I can be criticized for using it, but the syntax would be so much more bloated and error prone without it.

Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around?  For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow?  I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level.  I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope.  But it would be really nice if this was working on most CPUs.

It doesn't have to be such a breaking change.  New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW.  Or, they could always accept old transactions, but only a limited number per time period.

I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better.  0.01 is basically a proof of work, but not wasted.  But if the problem is validating loads of transactions, then PoW could be checked faster.

A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected.  Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

Bitcoin's p2p network is subject to various kinds of denial of service attacks.

There, I said it.

+1

Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.

Quote from: Red on August 12, 2010, 01:10:19 AM

Are you back to talking about the existing Bitcoin system here?

I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back.

If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:
1) Show it the entire history back to the original generated coin.
2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.

But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think.

Quote

But there will be no irc server to bootstrap from.

Which doesn't matter because you can't access sourceforge to download the software either.

If you've ever been connected before, you don't need IRC to bootstrap anymore.  Even if you haven't, you can bootstrap from seed nodes.  IRC is completely redundant since 0.3.0.

If you haven't already, try aligning thash.  It might matter.  Couldn't hurt.

Quote from: tcatm on August 14, 2010, 12:53:07 AM

Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?

No help from -O0, same error.

MinGW is GCC 3.4.5.  Probably the problem.

I'll see if I can get a newer version of MinGW.

On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner.  So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.

I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.

I found the problem with Crypto++ on MinGW 4.5.0.  Here's the patch for that:

The idea was the main part.  When you posted your patch, I realized it should have been done that way instead of "-?".  I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server.

Here's the preliminary change.  Look right?  I have more changes to make, this isn't all of it.  Will SVN shortly.

Code:

    bool CheckTransaction() const
{
// Basic checks that don't depend on any context
if (vin.empty() || vout.empty())
return error("CTransaction::CheckTransaction() : vin or vout empty");// Check for negative and overflow values
int64 nTotal = 0;
foreach(const CTxOut& txout, vout)
{
if (txout.nValue < 0)
return error("CTransaction::CheckTransaction() : txout.nValue negative");
if (txout.nValue > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout.nValue too high");
nTotal += txout.nValue;
if (nTotal > 21000000 * COIN)
return error("CTransaction::CheckTransaction() : txout total too high");
}if (IsCoinBase())
{
if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
return error("CTransaction::CheckTransaction() : coinbase script size");
}
else
{
foreach(const CTxIn& txin, vin)
if (txin.prevout.IsNull())
return error("CTransaction::CheckTransaction() : prevout is null");
}return true;
}

Don't sticky the topic, nobody looks up there.  There'll be enough posts to bump.

Quote from: knightmb on August 15, 2010, 10:59:04 PM

[edit] Just saw your post, I'll build one to less than 74,000 then, should at least save you technical people a few minutes of downloading the new chain.  

Just leave the old one alone!  Older is better.  What block number is it?  Anywhere from 60000-74000 is good.  The one that you've had available for a while has been vetted and is the best choice.

Quote from: Joozero on August 15, 2010, 11:32:43 PM

I think that you should add something about this: http://bitcointalk.org/index.php?topic=259.0
There must be a label on the client that show a warning message if needed 
Now everyone have always to check the website, and I think that this is bad.

Agree, wanted to do that for a long time, haven't had time to do it.

For now, you could also subscribe to the bitcoin-list mailing list.  It rarely gets used except for announcements like this and major new versions.

Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list

1) Once more than 50% of the node power is upgraded and the good chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad transactions to get any confirmations.
2) If you didn't remove your blk*.dat files, you're not helping to contribute to that 50%, and you'll still show bad transactions until the good chain overtakes the bad chain.

Quote from: tcatm on August 16, 2010, 12:43:39 AM

I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work on 32bit and 64bit) as only CPUs supporting this instruction set (AMD Phenom, Intel i5 and newer) benefit from -4way and it'll improve performance by ~9%.

GCC 4.3.3 doesn't support -march=amdfamk10.  I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch

Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM

With 4way, I get significantly better performance when I have all my virtual cores enabled. I think I get about the same amount of hashes when hyper threading is turned off with or without 4way.

Hey, you may be onto something!

hyperthreading didn't help before because all the work was in the arithmetic and logic units, which the hyperthreads share.

tcatm's SSE2 code must be a mix of normal x86 instructions and SSE2 instructions, so while one is doing x86 code, the other can do SSE2.

How much of an improvement do you get with hyperthreading?

Some numbers?  What CPU is that?

Quote from: jgarzik on August 16, 2010, 03:35:28 AM

cpu family 6 model 26 stepping 4 is an Intel Core i7.
That's a 23% speedup with -4way, 63% total speedup with -4way + hyperthreading.
33% faster with hyperthreading than without it.

That's a difficult approach.

We need to cause a reorg, which will disconnect the invalid chain.

This is code that will rarely ever get tested, and is fairly intricate, so something simple and safe is best.

Here's what I was thinking of.  (I haven't tested this yet)  It checks all the blocks in the main chain.  If it finds a bad one, it sets all that chain's bnChainWork to 0 so it can't win best chain again, and it reduces best chain work to the fork level so any new block after the fork will cause a reorg.  (It can't change pindexBest without actually doing a reorg)

This isn't perfect yet.  It still needs to receive one valid block to trigger the reorg.

It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention.  I probably should break out part of AddToBlockIndex that sets the new best block.  I'll probably end up doing that instead of the code below.

Code:

bool CTxDB::LoadBlockIndex()
{
...// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error("LoadBlockIndex() : block.ReadFromDisk failed");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}return true;
}

Quote from: kencausey on August 15, 2010, 11:45:26 PM

Quote from: satoshi on August 16, 2010, 03:25:54 PM

It would probably be possible to initiate an AddToBlockIndex or Reorganize after the check, but it would require a lot more careful attention.  I probably should break out part of AddToBlockIndex that sets the new best block.  I'll probably end up doing that instead of the code below.

This is what I ended up doing in SVN rev 139.

Instead of deleting the bad chain, I added an extra CheckBlock to ConnectBlock so bad blocks can't get back into the best chain once they're kicked out.

Quote from: Ground Loop on August 18, 2010, 11:14:26 PM

Any non-Mac i5 love?
Windows i5 64-bit got slower here.

That's the first I've heard anyone say i5 was slower.  Everyone else has said 4way was faster on i5.  Moreso with hyperthreading enabled.

Quote from: nelisky on August 18, 2010, 11:02:25 PM

And i5, at least on my macbookpro

Good, so I take it that's a confirmation that it's working on Mac as well?

Laszlo told me he did compile in the -4way stuff on Mac, so the -4way switch is also available to try on Mac.  I don't think makefile.osx on SVN has it yet, just the built version.

Search debug.log for "proof-of-work found".  If you find any, then check for any errors right after that.

Quote from: davidonpda on August 19, 2010, 07:43:01 PM

How big of a margin on the time is allowed for things to work right.

The margin is 2 hours.

This should be solved in SVN rev 141 and the next release (0.3.11+).  It'll pop up a message box alerting you if your clock is off by more than an hour.

Quote from: ArtForz on August 21, 2010, 04:56:31 PM

This probably explains why hyperthreading increases performance with -4way.  If three SSE2 units is excessive, then hyperthreading would help keep them all busy.

Quote from: jimbobway on August 25, 2010, 04:45:22 PM

WRT the alert system, who cares?  The most the key can do is temporarily disable six json-rpc commands until the site owners either add the -disablesafemode switch or upgrade.  All nodes keep running and generating, the network stays up.  If I'm not available, any script kiddie can figure out how to add two characters and make a new version that disables the alert system.  It would be a temporary inconvenience only.

Quote from: BioMike on August 23, 2010, 05:15:43 AM

So, theoretical this is a first control system where <some goverment> can arrest satoshi and demand
that he hands over his key (or get it from his computer) and shut down the complete network?

This is what makes me think the people objecting don't know what they're talking about.  It can't "shut down the complete network".

Quote from: nelisky on August 25, 2010, 01:28:32 AM

So what kind of warning do admins get from bitcoind? Is there something we can grep from debug.log? Or will rpc calls raise some specific error? Is there a way to locally force this to happen, for unittesting services?

getinfo has a new field that shows any alert messages or other errors that would be displayed on the status bar.

The rpc methods return a json-rpc error with the error description "Safe mode: " followed by additional text specified by the alert.

I added the switch "-testsafemode" for you.  SVN rev 145.

This stuff is very new and may still be subject to change.

Quote from: mizerydearia on August 25, 2010, 12:11:50 AM

I just discovered http://www.bitcoin.org/wiki/doku.php?id=man_page and don't see any reference to -disablesafemode.  Perhaps it should be added!  Also others liek -4way should be added as well.

Many switches are intentionally undocumented, like if their functionality is still under construction or I haven't settled on their name yet, or just test code not intended for release.

-4way should eventually be replaced by an auto-detect.

Quote from: BioMike on August 25, 2010, 06:23:45 PM

My apologies, your post was indeed a question not a statement.

Try -datadir=

Last time I tried $(shell /usr/bin/wx-config), there was immediate hollering about build problems with it.  There wasn't time to investigate at the time.

One problem with $(shell /usr/bin/wx-config) is it will pick up any version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that happens to be there.  -lwx_gtk2ud-2.9 only matches the right configuration.  It fails if wxWidgets was built with the wrong configuration.

Quote

Iirc, chatting in #wxwidgets on freenode, the devs there were baffled why that was used.

Did they say why they were baffled?

Quote

This is because on my system the path is /usr/include/wx-2.9/wx/wx.h

Why is it there?  Was it included by the OS, or did you have to build it?  If you built it, I wonder why it would put itself in a different place.

Has wxWidgets 2.9 finally started to become available as a debian package?

Maybe we should do this:

INCLUDEPATHS= \
-I"/usr/local/include/wx-2.9" \
-I"/usr/local/lib/wx/include/gtk2-unicode-debug-static-2.9" \
-I"/usr/include/wx-2.9" \
-I"/usr/lib/wx/include/gtk2-unicode-debug-static-2.9"

Again, those paths help make sure it's only 2.9 and will fail with 2.8.

wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us.  It's tempting because it's so easily available as a package; a lot of people were frustrated by it until we started hardcoding 2.9 into the makefile.

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

The "About" dialog still shows 0.3.10.1 beta.

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

The Mac version is still 0.3.10.1.

Quote from: pavelo on August 28, 2010, 07:36:07 AM

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

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

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

Thanks.

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

AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt

Did you try -4way?

Quote

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

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

There's been so much else to do that I haven't had time to make -4way automatic.  For now you still have to do it manually.
http://bitcointalk.org/index.php?topic=820.0

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.

Quote from: teknohog on September 09, 2010, 07:32:05 PM

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

#if defined(__GNUC__) && defined(CRYPTOPP_X86_ASM_AVAILABLE)

to make it compile again, at least on ARM.

Added in SVN rev 152

Is there a way to open BerkeleyDB exclusive?DB_PRIVATE is the worst of both worlds.  DB_PRIVATE is not exclusive, but it does make it get screwed up if another process tries to access it at the same time.

I've dropped the DB_PRIVATE flag in rev 153.

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/

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.

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

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

I implemented this change in SVN rev 157.

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

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

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

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

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

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

That's nice, however the automatic 4way detection is not working on my Gentoo AMD 64 version client.I still have to add the "-4way" switch.

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

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

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

Quote from: tcatm on October 03, 2010, 07:45:45 PM

983 Mhash/s box.

Seriously?  What hardware is that?

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

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

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

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

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

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

The person who originally sent the broken transactions deleted his wallet

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

Quote from: tcatm on October 03, 2010, 08:10:47 PM

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

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

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

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

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.

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

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

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

So for example, you have:
src
srcase58.h
srcignum.h
...
src\util.cpp
src\util.h
src\xpm
src\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.

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

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

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

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

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

It is normal that untranslated strings are shown on top.

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

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

I know, but not easily without complicating the sourcecode.

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

his block count remains "stuck" at 1698.

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

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

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

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

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

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

 Fault Module Name:   mingwm10.dll

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

Is anyone else running OK on Windows 64-bit?

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

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

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

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

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

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

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

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

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

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

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

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

updated to SVN 186

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

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

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

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

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

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

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

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

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

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

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

This is the new spec.  It shouldn't be hard to update your miner to use it.The changes are:
- It does not return work when you submit a possible hit, only when called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.

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

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.

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

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

No, don't "bring it on".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That's already possible.  <pubkey> OP_CHECKSIG.  <pubkey> can be 33 to 120 bytes.

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