Bitcoin Forum
May 20, 2019, 04:00:21 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 »
101  Bitcoin / Bitcoin Discussion / Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins? on: September 08, 2010, 08:27:39 PM
AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt
Did you try -4way?

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.
102  Bitcoin / Development & Technical Discussion / Re: Version 0.3.12 on: September 08, 2010, 06:06:04 PM
Bitcoin clients currently only create and recognize transactions that match two possible templates. 

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

In the future, if we add more templates to the existing 2 types of transactions, we can change the "rather not work on nonstandard transactions" test to accept them.
103  Bitcoin / Bitcoin Discussion / Re: Always pay transaction fee? on: September 08, 2010, 05:30:14 PM
Currently, paying a fee is controlled manually with the -paytxfee switch.  It would be very easy to make the software automatically check the size of recent blocks to see if it should pay a fee.  We're so far from reaching the threshold, we don't need that yet.  It's a good idea to see how things go with controlling it manually first anyway.

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

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

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

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

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

The threshold can easily be changed in the future.  We can decide to increase it when the time comes.  It's a good idea to keep it lower as a circuit breaker and increase it as needed.  If we hit the threshold now, it would almost certainly be some kind of flood and not actual use.  Keeping the threshold lower would help limit the amount of wasted disk space in that event.
104  Bitcoin / Development & Technical Discussion / Version 0.3.12 on: September 07, 2010, 07:17:55 PM
Version 0.3.12 is now available.

- json-rpc errors return a more standard error object. (thanks to Gavin Andresen)
- json-rpc command line returns exit codes.
- json-rpc "backupwallet" command.
- Recovers and continues if an exception is caused by a message you received.  Other nodes shouldn't be able to cause an exception, and it hasn't happened before, but if a way is found to cause an exception, this would keep it from being used to stop network nodes.

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

105  Bitcoin / Bitcoin Discussion / Re: Always pay transaction fee? on: September 07, 2010, 04:32:21 PM
Another option is to reduce the number of free transactions allowed per block before transaction fees are required.  Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.

The threshold should probably be lower than it currently is.

I don't think the threshold should ever be 0.  We should always allow at least some free transactions.
106  Bitcoin / Bitcoin Technical Support / Re: bitcoind as daemon in OSX on: September 06, 2010, 09:52:45 PM
Can you build?

Try changing line 78 of init.cpp from:
#ifdef __WXGTK__

#ifndef __WXMSW__

If that works, I'll change the source.  It should work.
107  Bitcoin / Development & Technical Discussion / Re: auto backing up of wallet.dat on: September 06, 2010, 09:45:10 PM
rpc backupwallet <destination> is in SVN rev 147.
108  Bitcoin / Bitcoin Technical Support / Re: Warning : Check your system ( Help me ) on: September 06, 2010, 09:41:06 PM
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?
"Please check that your computer's date and time are correct. If your clock is wrong Bitcoin will not work properly."
109  Bitcoin / Development & Technical Discussion / Re: HTTP status codes from the JSON-RPC api on: September 06, 2010, 09:21:21 PM
This is in SVN rev 147.

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

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

Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code.  Exit codes can only be 0-255 on unix, so it's abs(code)%256.
- The "backupwallet <destination>" command that was discussed in another thread.  It locks the wallet and copies it, so you can be sure you get a correct copy.
110  Bitcoin / Bitcoin Technical Support / Re: Warning : Check your system ( Help me ) on: September 05, 2010, 11:36:20 PM
Any suggestions for better text to put for this error message so the next person will be less likely to be confused?

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

It's relying on 3 time sources:
1) the system clock
2) the other nodes, if within an hour of the system clock
if those disagree, then
3) the user (asking the user to fix the system clock)

I've thought about NTP, but this is more secure.
111  Bitcoin / Bitcoin Technical Support / Re: CryptoPP Assertion Error on: September 05, 2010, 11:25:32 PM
You can probably just comment out the line

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

It looks like a template class to make sure the derived class defines its own version of allocate and deallocate.  It would be weird if that was the actual problem and it made it all the way to release.  Probably a false alarm.
112  Bitcoin / Development & Technical Discussion / Re: Big endian code problems on: August 29, 2010, 10:14:36 PM
The code assumes little-endian throughout and was written with the intention of never being ported to big-endian.  Every integer that is sent over the network would have to be byte swapped, in addition to many dozens of other places in code.  It would not be worth the extra sourcecode bloat.

Big-endian is on its way out anyway.
113  Bitcoin / Development & Technical Discussion / Re: Version 0.3.11 with upgrade alerts on: August 28, 2010, 02:54:04 PM
The "About" dialog still shows beta.
What OS?  I ran the Windows and 64-bit Linux version and checked the about dialog.

The Mac version is still

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.
114  Bitcoin / Development & Technical Discussion / Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 on: August 28, 2010, 02:27:15 PM
The simplification is intentional.  There will only be more than one thash[7]=0 in one out of 134,217,728 cases.  It only makes it 0.0000007% slower.
115  Bitcoin / Development & Technical Discussion / Version 0.3.11 with upgrade alerts on: August 27, 2010, 09:54:12 PM
Version 0.3.11 is now available.

- Some blk*.dat checking on load
- Built the -4way code with -march=amdfam10, which makes it a little faster
- Warning if your clock is too far off
- Warnings/errors/alerts can also be seen in the getinfo command
- Alert system

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

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

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

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

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

116  Economy / Economics / Re: Bitcoin does NOT violate Mises' Regression Theorem on: August 27, 2010, 05:32:07 PM
As a thought experiment, imagine there was a base metal as scarce as gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable either
- not useful for any practical or ornamental purpose

and one special, magical property:
- can be transported over a communications channel

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

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

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

(I'm using the word scarce here to only mean limited potential supply)
117  Economy / Economics / Re: Bitcoins are most like shares of common stock on: August 27, 2010, 04:39:26 PM
Bitcoins have no dividend or potential future dividend, therefore not like a stock.

More like a collectible or commodity.
118  Bitcoin / Development & Technical Discussion / Re: New web service: obtain dump of bitcoin block NNNN on: August 27, 2010, 04:13:16 PM
That's kind of interesting as an upside-down bar chart of how many blocks were produced each day.  The target is 144 blocks per day.
119  Bitcoin / Development & Technical Discussion / Re: auto backing up of wallet.dat on: August 27, 2010, 03:47:57 PM
Sorry, I've been so busy lately I've been skimming messages and I still can't keep up.

We want to avoid Windows API calls whenever possible.  They usually take about 6-8 parameters and a lot of testing to get right, it takes a page of code to do something simple.

I usually shy away from iostreams.  Seems like I too often hit limitations.  They kind of botched the C++ streams standard in the 90's, which is too bad, streams can be very powerful and useful when done right.  Using it in rpc.cpp may still turn out to be a mistake.

Bottom line is I'd rather call an existing file copy function than make and test my own.
120  Bitcoin / Development & Technical Discussion / Re: auto backing up of wallet.dat on: August 27, 2010, 02:54:07 AM
I doubt there's an mmap(2) on Windows.  I'd rather call an existing file copy function than make and test my own.

But if you are already using features from boost::filesystem you can use copy_file from that. I just think that, if not already required for something else, it's a tad overkill.
Thanks.  I thought it would be in there somewhere.

We already use boost::filesystem in a dozen places.  It's not a new added dependency.  It gives us a lot of portable stuff that we would otherwise have to have a #ifdef for each OS and test everywhere.
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!