Bitcoin Forum
September 29, 2023, 04:40:29 PM *
News: Latest Bitcoin Core release: 25.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Issues building bitcoin on Windows 7 on: September 14, 2010, 06:58:07 PM
You should build using the nmake command from the visual studio command prompt as described in the information distributed with the source.
2  Bitcoin / Bitcoin Discussion / Re: Why do this? on: September 14, 2010, 04:41:12 PM
This is the same problem I've encountered with a couple of friends I've talked to about bitcoin. A lot of people don't have the economic insight to understand why bitcoins have certain intrinsic advantages over other currencies. To them it's just play money you can generate with some obscure algorithm on a computer and then convert into "real" money. At best they see it as some form of speculation or pyramid scheme (which currently is a deflating factor imho) and in the worst case they see it as some unworldly hippie thing.

Some serious thought should be put into making people understand the intrinsic benefits of bitcoins, but I'm not sure how to do that either. Most people simply don't care and just use whatever money their government wants them to use.
3  Economy / Marketplace / Re: Bitconent -The exponential Bitcoin Investment on: September 02, 2010, 09:56:43 PM
The forex market oscillates between certain range within a week, generally following downtrend or uptrend over a longer period like in monthwise context.Anybody dealing in forex knows that 10 % profit over a single transaction is not a big deal, using mathematical models one can have literally be never in loss .But there is risk in each and every future event(Heisenberg 's principle) -events like some calamity or economic collapse, so, to gaurantee 10% returns I will use my BTC reserve or the previous accumulated profits ( incase of loss ) and  the maximum investment will be kept limited to minimise greater risk of loss .Trust is thing which is very hard to get ,but being myself and others here involved in bitcoin for a long perod of time,so  please give me a little trust , I will try to make to it more concrete .

Can you explain to me (or give me a link that explains it) how Heisenberg's principle applies to forex markets? At first, this sounds a bit like gibberish to me. :s
4  Bitcoin / Development & Technical Discussion / Re: Generating Bitcoins with your video card (OpenCL/CUDA) on: September 02, 2010, 09:50:32 PM
There is already 1 person with 20% of the hashing capability, so I thought this would even the field better.

Could you elaborate on that?
5  Bitcoin / Development & Technical Discussion / Re: Generating Bitcoins with your video card (OpenCL/CUDA) on: September 02, 2010, 09:47:15 PM
Not sure if I trust this, might be a scam to rip off your coins or something.
6  Economy / Marketplace / Re: Bitconent -The exponential Bitcoin Investment on: September 02, 2010, 06:44:21 PM
Deposit bitcoins and Earn 10 % interest weekly .
I have started a new investment service directly dealing in Bitcoins.
For details visit -

How can you guarantee 10% weekly interest? Is this a Ponzi scheme?
7  Bitcoin / Development & Technical Discussion / Re: Version 0.3.11 with upgrade alerts on: September 02, 2010, 10:32:46 AM
Alerts are broadcast in the same way as transactions. Each node, upon accepting the alert, sends the alert to all of its peers.

Bitcoin won't relay alerts that are signed with a different key. Propagation might not be very good for any client if different alert keys start being used.
That doesn't sound very scalable... Does anyone remember the gnutella bottlenecks? If not, read up on this:

Also not relaying alerts signed with a different key basically means there's only one person in the whole world that can send messages through the network. Isn't that kind of against the spirit of p2p and decentralization in general?
8  Bitcoin / Bitcoin Discussion / Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins? on: September 01, 2010, 06:04:17 PM
The article is all about the cost of the hardware, neglecting the more significant cost: electricity.

Once you're above baseline power of 11 kWh/day (as any geek is), Southern California utilities get about $0.13/kwh marginal, with taxes, distribution, etc.
The 24-core beast built in the article probably draws some serious current.  Hard to guess how much, but I'd guess about 500W?  Anyone know?

The 24-core beast will draw a minimum of 380W (using the power supply calculator:

What you have calculated is the power requirements of system with a single Phenom II X4 processor, the article talks about 6 such processors in one system.

A single Phenom II X4 consumes at full load approximately 125W (see TDP:, 6 such cores would consume about 750W, so a full system including memory, video, motherboard, will draw about 900W, assuming a 1000W power supply unit (a somewhat pricey device which is oddly forgotten in the article) with an efficiency of around 80% you can expect drawing over 1 kW 24/7 running such a system. Assuming 1kW and you pay 0.15ct for each kWh that would be about 3.60 every day on power consumption. That's a little bit more than the value of generating one block (which gives you 50 bitcoins).

As you're expected to generate one block each day, you would actually lose money generating bitcoins, even when you got that $2000 system for free. Of course this is assuming you pay a more or less standard price for electricity, don't have any excess self-generated electricity, you don't recycle waste heat, ...

9  Bitcoin / Development & Technical Discussion / Re: Big endinan code problems on: August 29, 2010, 05:18:16 PM
The ByteReverse macro should probably be skipped before doing SHA-256 transforms.

before and after? theres several ByteReverse calls that probably need removal for the nonce ant the timestamp also.

in fact you may be able to do away completely with the temp block header thats mostly just there so it can be ByteReversed.

I think all of them can go away since SHA-256 expects it's bytestream to be big-endian. The fastest way to find out I think is to run the code through a debugger on both a BE and LE machine at the same time and compare results at every step.
10  Bitcoin / Development & Technical Discussion / Re: Big endinan code problems on: August 29, 2010, 11:35:19 AM
The ByteReverse macro should probably be skipped before doing SHA-256 transforms.
11  Bitcoin / Development & Technical Discussion / Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 on: August 29, 2010, 11:11:32 AM
@sgtstein: Intel's Sandy Bridge (to be released Q4 2010) will also support AVX 256-bit SIMD registers. That means 8 simultaneous hash calculations/thread would be possible, in principle.

Does anybody has any reports on 4-way SSE2 on the Pentium D (Presler)? What kind of performance can I expect? I have an old Pentium D+mobo laying around and I would fire it up as a mining server if performance would be ok. Probably won't be the most efficient khash/Watt though.
12  Bitcoin / Bitcoin Technical Support / Re: What does this error in my debug log mean? on: August 24, 2010, 02:26:09 PM
ERROR: ConnectInputs() : a471d0 mapTransactions prev not found 13ce12
ERROR: AcceptTransaction() : ConnectInputs failed a471d0
and what does this error mean?
I have that one too, not sure what it means.

EDIT: Just thought a bit about it, and maybe it means that there was an attempt to validate a transaction whose previous transaction in the chain hasn't been validated yet. Possibly a minor concurrency thing, not really an issue.
13  Bitcoin / Development & Technical Discussion / Re: Bitcoin's implementations on: August 23, 2010, 11:12:56 PM
I'm thinking about writing a minimal-dependency C library implementation of Bitcoin. There's the other thread here where people are reverse engineering the protocol for a python client. More and more alternative implementations will appear when Bitcoin gains more momentum, especially since the stock implementation can't possibly cover all the Bitcoin use cases (think of a laundromat that accepts Bitcoins for example). Alternative implementations will happen and decent protocol standardization is the only way to prevent potential problems with multiple implementations inter-operating on the network. Multiple implementations will make the network grow faster, standardization will make the network more robust. Both will dramatically increase security, as a lot more potential problems will be discovered.
14  Bitcoin / Wallet software / Re: Python client on: August 22, 2010, 05:15:33 PM
I'm looking into the possibility of integrate Bitcoin functionality into an existing GPL software product, the problem is that it seems to be hard. The one true implementation brings with it some additional dependencies such as wxWindows (which is actually pointless if you're just interested in the functionality and not the GUI), BerkeleyDB (which is a bit much for storing just a bunch of keypairs), openSSL (which is reasonable as it's use is very wide-spread, but i'm not entirely sure why it is required as the set of crypto functions in Bitcoin is fairly limited afaik) and Boost (which is huge to introduce in an existing project when it's only needed for Bitcoin functionality). Especially on Windows is including those libraries far from a straightforward task and building a 64-bit binary for Windows is just a pain.

I don't really have a problem with the fact that a one true implementation is preferred, because I understand more implementations will introduce complications in this early stage, the examples where this method is successful are few (Perl is maybe one of the very few exceptions probably because it's very well-documented). I think in the long run multiple implementations are going to be required if Bitcoin is to grow (a lot) larger. Keep in mind that in time perhaps other devices with much more esoteric platforms may want to be able to have Bitcoin functionality as well (smartphones were already mentioned, but think about automated payment servers, set-top boxes, vending machines, pay-toilets, ...). Bittorrent, which is mentioned here as an example, is currently running on the firmware of some people's networked harddrives. Maybe on-chip implementations of Bitcoin will be made one day.

Being able to run Bitcoin in javascript (with an AJAX proxy) would be a significant advantage for the application I'm thinking about.

I think what would be needed is a very low-dependency reference implementation, which can easily be translated into other programming languages without introducing new bugs or incompatibilities. In time the protocol should be standardized and perhaps even go for recognition by standards bodies. That's the best way to guarantee long-term survival of the network. Every platform in the world that could be capable of using Bitcoin has at least a decent C compiler and the current de facto standard way to have a low-dependency reference implementation is to have C library which can be easily compiled on all major platforms without (or with absolute minimal) dependencies. The stock client should also use that C library.
15  Bitcoin / Development & Technical Discussion / Re: BitCoin 0.3.8 win64 Installer on: August 09, 2010, 05:30:18 PM
Hi, I've tested your version and it works really well. With the stock version I get about 4500 khash/s and now I get 4900 khash/s, that's almost a 10% increase, which is really nice. Smiley

I'm also trying to build bitcoin myself to tweak performance a bit, but haven't gotten past the default debug build yet. It would be nice if you could share your compilation settings?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!