Bitcoin Forum
May 27, 2022, 01:19:48 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Re: Starting a new proof-of-work chain on: April 17, 2010, 11:48:51 PM
If you decide to start a new proof-of-work chain for BTCv2, then all I have to do is get all the old BTC proofs-of-work, and add them to the new chain, and I'll instantly have lots of BTCv2s to my credit.


Thankfully, no. The Bitcoin mechanism has the concept of a genesis block hash, which is the theoretical hash (0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f) of a nonexistant 'root' block. To start a separate block chain you'd start with a new genesis block hash and start adding new blocks to that chain rooted at your new genesis block. Since each new block contains a hash of the previous block in the chain, you could not re-use blocks for the current block chain in your new block chain.
2  Bitcoin / Bitcoin Discussion / Re: We need a wiki! on: April 14, 2010, 03:54:20 AM
Seconded! I'd be very interested in helping with content.
3  Bitcoin / Bitcoin Discussion / Re: What happens when block generation becomes too slow? on: April 10, 2010, 10:30:49 PM
The network adjusts the difficulty so that roughly 6 blocks are created network-wide every hour. Each block can contain lots of transactions.

But indicates that the difficulty of the POW is increased to halve the block production rate every 4 years. Since this asymptotically approaches 0, it seems problematic. If the rate was a constant 6 blocks/hour then it wouldn't be an issue, but the FAQ suggests otherwise.

Quote from: sirius-m
If the network grows very large and that makes it difficult to get your transaction into a block for free, you can make it happen faster by paying a small transaction fee to the node that puts your transaction into the block chain. Bitcoin supports this functionality.

This is true. However, if the POW problem is hard enough that even paying transactions have to queue indefinitely for inclusion in a block then they're no better off than those transactions that are included for free in the block (and have to queue for inclusion regardless).
4  Bitcoin / Bitcoin Discussion / Re: Running 24/7? on: April 10, 2010, 06:19:02 PM
I knew that Bitcoin would increase my temps. My computer is semi-new and I haven't done much full load testing, but Bitcoin makes my machine rise 20-25 degrees C. It's still safe, at 57...but just curious. Do you all run Bitcoin 24/7, and if so, is it bad to run at 100% usage, at such a temp, whenever the computer is on?

It depends a lot on the cooling capacity of you computer. If your cooling is struggling to keep your core temperature down at 100% load then you're probably going to wear out your fans in the not-too-distant future. If your cooling system isn't breaking a sweat to keep your CPU cool then you probably won't have much issue with mechanical wear.

Also, an idea while studying this earlier. It may be small potatoes at this point, but a scheduler to accomodate different times you want it to run and/or how many processors you want running at once.

For example, it would be nice to have it run on full load while I am busy or at work, while slowing down to one or two processors during my main usage hours. Or for those with a computer that is a bit old or they don't exactly trust, turn the load down at night or when you are not home for safety precautions of temps.

Like I said, a timer/scheduler like that is small potatoes, but at some point I'd really like to see it in the Options menu.

That's not a bad idea. It might just be a better idea to make the load scaling work better by automatically cutting down the number of hashing threads based on the amount of load other system processes are putting on the system. That way, if you weren't using the computer at all the client could suck up all of the cores, but if you sat down and started doing big parallel compiles then it would back off to 1 or 0 cores.

The way that load scaling currently works in client is slightly problematic, in that the 'niceness' of individual processes doesn't affect its IO demand. Since the current BitCoin client is such a monster when it comes to disk access, you'd probably notice a huge responsivity increase on your system if you ionice'd the client.
5  Bitcoin / Bitcoin Discussion / Re: Benchmark Utility on: April 10, 2010, 05:50:09 PM
I decided that hyper-threading is better even if it were a bit slower because I want to keep one thread unused by Bitcoin and leaving a hyper-threaded half core unused by Bitcoin is better than leaving a whole core unused by Bitcoin. So scratch that request for a benchmark utility. There are other more important features to work on for now.

I think that a very useful thing to have in the BitCoin main window would be an indicator saying "# hashes/sec" to demonstrate how fast the BitcoinMiner threads were running.
6  Bitcoin / Bitcoin Discussion / Re: I have a couple of questions... on: April 10, 2010, 05:48:27 PM
Also, would it be unethical for me to farm a whole cluster of old Pentium3s/Pentium4s and generate Bitcoins that way?
No. The BitCoins you receive for generating a block are a payment to you by the system for you work towards extending the block chain. You have invested money (by way of electricity and hardware wear) in the generation of the block chain, and are receiving compensation for that work.
7  Bitcoin / Bitcoin Discussion / What happens when block generation becomes too slow? on: April 10, 2010, 05:34:09 PM
As the proof-of-work problem becomes increasingly more difficult the interval between block generation increases exponentially. What happens when the number of transactions in the system outpaces the block generation rate? Won't we be in the situation where we can no longer grow the block chain fast enough to include all of the ongoing transactions in blocks? If I've misunderstood something from the paper or the code please chime in and correct me, because I'm a touch worried about the future of the currency. Tongue
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!