Bitcoin Forum
May 25, 2019, 02:19:36 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 »
401  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 10:23:39 PM
Laszlo figured out that enabling some more optimisation increased performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume he used that in his own build.

30khash increase to what total rate?  (to figure the % increase)
402  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 07:46:23 PM
You figured it out faster than I could post a reply.  Smiley

It looks like laszlo's build of Berkeley DB has database/log.* files that are not compatible with ours.  The .dat files are fine, their format shouldn't ever change.  All data is stored in the .dat files.  All your own data is stored in wallet.dat.  If you had waited for it to redownload the block chain, your missing transactions and generateds would have appeared as the block chain reached the point where those transactions were recorded.

When you copied the directory except log.0000000002, that's the best solution.  You should be good now.

The database/log.* files only contain temporary database data.  If you exited bitcoin normally the last time, not exited by forced terminating it or crashing, then the database/log.* files can normally be deleted safely.  They're only used so that if the database is in the middle of a transaction when the computer crashes or the program is killed or crashes, then it could recover without losing data.

Please keep running v0.3 if at all possible, don't go back to v0.2.10.

Anyone else who hits this problem, move the database\log.000000000* files somewhere else.  (if it works fine after that, you can delete them later)

I'm reluctant to make the installer delete or move those files.  If the previous run was stopped by crashing or killed, that would be the wrong thing to do.
403  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 07:25:13 PM
davidonpda, were you also running laszlo's build previously?

Check if the "%appdata%" directory exists, and "%appdata%\bitcoin"

 rename "%appdata%\bitcoin" bitcoin2

does it work then?
404  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 07:11:41 PM
EXCEPTION: 22DbRunRecoveryException
DBENv::open: DB_RUNRECOVERY: Fatal error, run database recovery
C:\Program Files\Bitcoin\bitcoin.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.
405  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 05:37:08 PM
Here's RC1 for windows for testing:
(removed, see RC2 below)

Please only download this if you're going to test and report back whether everything seems fine or not.  Make sure to look through the files in "c:\program files\bitcoin"
406  Bitcoin / Development & Technical Discussion / Re: 0.3 almost ready on: June 22, 2010, 05:02:07 PM
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.
407  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: June 22, 2010, 04:51:14 PM
Agree.  Certainly too trivial to clutter the user's attention with.

I changed it to every 30 minutes.

If I increased it to every 10 minutes, it would still be a small enough presence in the log file.  Question is whether that would be more output than the user wants when they grep.
408  Bitcoin / Development & Technical Discussion / Re: Bitcoin in Ubuntu 10.04 on: June 22, 2010, 04:39:43 PM
It's too late now for feature changes to 0.3, but I'll add that to the post-0.3 to do list.  I never would have noticed that if you hadn't pointed it out.
409  Bitcoin / Bitcoin Discussion / Re: How fast do the fastest computers generate bitcoins? on: June 22, 2010, 04:35:26 AM
I've noticed that hashing performance doesn't vary as much between CPUs as you'd expect.  Compared to an old CPU, a newer CPU doesn't show as much of a speedup at hashing as it does on general benchmarks.

I guess recent CPU optimizations must have concentrated on things like I/O and branch prediction.  Most programs are a bunch of memory access, comparisons and branching, they rarely get down to cranking away at maths for very long.

The latest SVN version has a khash/s display.  Around 400 khash/s per processor is typical.
410  Bitcoin / Development & Technical Discussion / 0.3 almost ready -- please test the Mac version! on: June 22, 2010, 04:01:53 AM
I finished everything on my list to do for version 0.3.  The code on SVN is about ready to release.

Testing at this point is much appreciated.
411  Bitcoin / Development & Technical Discussion / Re: Bitcoin in Ubuntu 10.04 on: June 22, 2010, 03:45:56 AM
On Ubuntu 10.04 it wouldn't remove the taskbar button cleanly, so I made it leave it there.

But now that you mention it, it's probably better to have the feature, even if it's messy, than not to have it, though it may confuse a few people when the taskbar button temporarily stays around but disappears if you click on it.

Updated SVN.

Thanks for testing.
412  Bitcoin / Bitcoin Discussion / Re: Proof-of-work difficulty increasing on: June 21, 2010, 06:09:17 PM
I integrated the hashmeter idea into the SVN version.  It displays khash/s in the left section of the status bar.

Two new log messages:
21/06/2010 01:23 hashmeter   2 CPUs    799 khash/s
21/06/2010 01:23 generated 50.00

grep your debug.log for "generated" to see what you've generated, and grep for "hashmeter" to see the performance.  On windows, use:
 findstr "hashmeter generated" "%appdata%\bitcoin\debug.log"

I have the hashmeter messages once an hour.  How often do you think it should be?
413  Bitcoin / Bitcoin Discussion / Re: Dying bitcoins on: June 21, 2010, 05:48:26 PM
Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone.

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.
414  Bitcoin / Development & Technical Discussion / Re: Bitcoin in Ubuntu 10.04 on: June 21, 2010, 05:20:21 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:

They've got it awfully buried considering 9 out of 10 users are used to having it on the right.
415  Economy / Marketplace / Re: Get 5 free bitcoins from on: June 18, 2010, 11:08:34 PM
Excellent choice of a first project, nice work.  I had planned to do this exact thing if someone else didn't do it, so when it gets too hard for mortals to generate 50BTC, new users could get some coins to play with right away.  Donations should be able to keep it filled.  The display showing the balance in the dispenser encourages people to top it up.

You should put a donation bitcoin address on the page for those who want to add funds to it, which ideally should update to a new address whenever it receives something.
416  Bitcoin / Development & Technical Discussion / Re: On IRC bootstrapping on: June 18, 2010, 05:28:18 PM
The SVN version now uses IRC first and if that fails it falls back to a hardcoded list of seed nodes.  There are enough seed nodes now that many of them should still be up by the time of the next release.  It only briefly connects to a seed node to get the address list and then disconnects, so your connections drop back to zero for while.  At that point, be patient.  It's only slow to get connected the first time.

This means TOR users won't need to -addnode anymore, it'll get connected automatically.  
417  Bitcoin / Development & Technical Discussion / Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG on: June 18, 2010, 04:17:14 PM
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.

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.

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 Smiley
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.
418  Bitcoin / Development & Technical Discussion / Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG on: June 17, 2010, 06:46:08 PM
The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

I don't believe a second, compatible implementation of Bitcoin will ever be a good idea.  So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.  The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint.
419  Bitcoin / Bitcoin Discussion / Re: new binary release? on: June 17, 2010, 05:07:56 PM
I'm working on getting version 0.3 released as soon as I can.  Just a last few things left to do.  It's been a long time since 0.2 and we need to get a prebuilt bitcoind with command line and JSON-RPC available.  This time we'll have both 32-bit and 64-bit linux binaries, and Laszlo is going to build a Mac OSX release.  Plus, we'll include the German, Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks you guys!).
420  Bitcoin / Development & Technical Discussion / Re: Website translations on: June 16, 2010, 04:53:34 PM
Thanks DataWraith!  The German translation is uploaded to SVN.

This is great, we've already got 3 major languages.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 [21] 22 23 24 25 26 27 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!