Bitcoin Forum
May 23, 2022, 09:08:37 AM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Mining / Most Efficient Miner? on: June 06, 2011, 06:42:45 PM
Has anyone done a comparison of recent revisions of the various miners on the same hardware?  Implementation efficiency is a big deal when it comes to squeezing execution iterations out of a program, and I can't help but suspect that I could squeeze a few more hashes out of my machine by using the most skillfully-written miner...
2  Economy / Economics / Stable Exchange Rate? on: August 07, 2010, 05:38:33 PM
It looks as if the two main markets, bitcoinmarket and mtgox, are stabilizing around 5.5-6.5 USC/BTC.  The outliers and quartiles have been tightening for days now, and now the values are centering in that range.  Thoughts?  Could it be that we've established a market value?  That would be a major step toward currency confidence and widespread public use.
3  Bitcoin / Development & Technical Discussion / Faster Hashing - What's the Point? on: August 06, 2010, 05:18:58 PM
I've seen two recent releases, .36 and .38, mention faster hashing.  Why is this advantageous?  Won't faster hashing simply cause the difficulty to increase, and place us precisely back where we were before the "speed" increase, only with a higher difficulty number?
4  Bitcoin / Bitcoin Discussion / 0.3.7 Changes on: August 01, 2010, 06:14:26 PM
I noticed that 0.3.7 is released on the website, but after searching the forums I can't find any information on what the changes are.  Never mind that the changes from version to version should be packaged with the download....

anyone care to clue me in on this one?
5  Economy / Economics / Greece, the EU, and Bitcoins on: July 21, 2010, 09:23:03 PM
I'm sure everybody is fairly familiar with what is going on in Greece.  For those who don't know, a (very) simplified description is the following.

Greece, like the rest of the EU bloc, is under the Euro.  The Euro is a unified currency which spans over twenty nations.  Some of these nations are more economically prosperous than others.  Germany, for instance, can produce more value into the global economy than Greece.  In a multi-currency situation, this would lead to a devaluation of the Greek currency so that its goods could be purchased cheaply by the Germans and others with more economic power.  While the situation is not as good for the Greeks as if they were able to compete evenly, they can't compete evenly anyway, so at least this way they can sell something at some price.  However, the country is locked into the Euro.  Therefore, it is locked into a 1:1 exchange rate with all Euro countries (France, Germany, etc.)  Thus, it cannot offset its economic weakness with a devalued currency, so it must compete on even footing with other Euro countries, which it cannot do, as it is less economically and technologically developed.  Thus, we have a crash.

On the another stage, the US buys things from India because the RUP is devalued relative to the USD.  This works out well for both countries, as it enables the US to get cheap goods, and India to sell goods which couldn't compete with the goods of more prosperous and developed nations on even footing.  (Opportunity cost is at the root of this).  However, if the US and India were locked into an identical currency, the economic weakness of India today would look like a paradise relative to what we would see then.

The parallels between the Bitcoin and the Euro are obvious.    Say the BTC becomes a global currency.  How do we deal with the issue of necessary currency value differentials to accommodate the differing capabilities of disparate geographical locations?  Obviously, if we can't, then the BTC is worthless in all but the economic top-tier countries, because it cannot be used save on an equal footing with such countries.
6  Economy / Marketplace / Bitcoin Market Access Issues on: July 19, 2010, 01:16:51 AM
I really love the idea behind BitcoinMarket, being an active commodity investor myself.  However, the site seems to be always, or nearly so, unreachable.  I seem to recall a post stating that it was on someone's home machine (and thus probably piped through a residential line)...could this be the source of the issues?  Whoever runs the site, I would be glad to collaborate with you (Computer Science researcher here, so I can at least know what I'm talking about) if you would like some assistance devising ways to increase uptime, reachability, or system automation.
7  Bitcoin / Development & Technical Discussion / Dynamic Difficulty Adjustments on: July 18, 2010, 10:15:36 PM
I have read that the difficulty of BTC generation varies every two weeks, based upon statistics gathered over the course of the two weeks.  This seems to introduce an undue amount of lag into the system.  We've all read about the guy who supposedly has 1,000 cores running the client - if he leaves, suddenly BTC generation takes far longer.  Also, if the difficulty is low and we suddenly have a mass influx of power, then coins are generated too quickly.

What was the justification behind the two-week blocks of time between difficulty adjustments. Why not do something like the following?  (In this example, magnitudes of changes are fictitious, and target block generation time is taken to be ten minutes.)

after each block:

difficulty+=.001*600-block.genTimeInSeconds

Thus, the difficulty would adjust dynamically up or down every block, with the magnitude of the adjustments being in proportion to the influx or exodus of computing power during that last block.  Yes, you would get situations where someone would randomly solve a block in ten seconds and thus the next difficulty would ramp up exceedingly high, but the high (or low, in the converse situation) difficulty would only last for one block, and these random noise variations would even out in the long run.
8  Economy / Economics / Transaction Fees in the Deflated Economy on: July 18, 2010, 10:08:56 PM
I saw a post from Satoshi in another thread informing us that "Typically over 25,000BTC" had to change hands in a single transaction to warrant transaction fees.

So, will no fees, ever, be charged in a deflated economy?  If the average transaction is .01BTC, or if only 10,000BTC exist in the economy, will no fees ever occur?
9  Economy / Economics / Future Adjustment of Divisibility on: July 18, 2010, 10:57:13 AM
It was wise when creating the BTC specification to allow up to 8 (I think its 8 ) decimal places of divisibility.  Given the natural deflation that will occur barring government intervention, its certainly better than two places of divisibility.  However, a number of theoretical posts on the forums have raised the question of what would happen if that ever was not enough.  

I am amazed at the two categories of answers that I see - A)"That'll never happen," and B)"Well we're screwed then."  How difficult would it be in the future to modify the bitcoin specification to allow for nine, ten, or even an arbitrary number of, points precision?  My guess is that it would be pretty daunting, given that the entire chain would have to change (I think?).

The second option that I can see would be a voluntary currency revaluation.  In essence, we'd release a new chain and a new client.  This new chain wouldn't generate *any* coins.  However, it would be denominated in "BitCoinMillionths" or whatever, and when you imported your old BitCoin wallet, it would apply the exchange rate of 1BTC=1,000,000BTCm, and continue from there.  The BTCm would be divisible to eight or ten or however many decimal places as well.  Thus, people could still generate BTC with the BTC client (assuming we hadn't hit the 21,000,000 mark), but the new client would allow for greater divisibility while not modifying the underlying system.  In fact, the BTCm client could generate bitcoins on the old chain according to the same rules that govern generation today, letting one program handle both issues.

What do you guys think of this idea?

Cross-posted to Tech and Dev to get a response about actually modifying the bitcoin's divisibility.
10  Bitcoin / Development & Technical Discussion / Divisibility Adjustment - Technical Feasibility on: July 18, 2010, 10:54:23 AM
It was wise when creating the BTC specification to allow up to 8 (I think its 8 ) decimal places of divisibility.  Given the natural deflation that will occur barring government intervention, its certainly better than two places of divisibility.  However, a number of theoretical posts on the forums have raised the question of what would happen if that ever was not enough.  

I am amazed at the two categories of answers that I see - A)"That'll never happen," and B)"Well we're screwed then."  How difficult would it be in the future to modify the bitcoin specification to allow for nine, ten, or even an arbitrary number of, points precision?  My guess is that it would be pretty daunting, given that the entire chain would have to change (I think?).

The second option that I can see would be a voluntary currency revaluation.  In essence, we'd release a new chain and a new client.  This new chain wouldn't generate *any* coins.  However, it would be denominated in "BitCoinMillionths" or whatever, and when you imported your old BitCoin wallet, it would apply the exchange rate of 1BTC=1,000,000BTCm, and continue from there.  The BTCm would be divisible to eight or ten or however many decimal places as well.  Thus, people could still generate BTC with the BTC client (assuming we hadn't hit the 21,000,000 mark), but the new client would allow for greater divisibility while not modifying the underlying system.  In fact, the BTCm client could generate bitcoins on the old chain according to the same rules that the generation follows at present, letting one program handle both issues.

Cross-posted to Economics for the obvious non-technical portion of this.
11  Bitcoin / Bitcoin Discussion / Anonymous Altruists on: July 18, 2010, 10:41:32 AM
I keep getting random influxes of BTC....five cents here, 1BTC there....I can only assume they're from people on the forums, as I know no one who uses bitcoins.  Thanks to whomever it may be.  I'd really like to know who.
12  Bitcoin / Development & Technical Discussion / Changelog? on: July 18, 2010, 09:11:46 AM
Can a comprehensive changelog be included in the download zips?  I had to dig through the forums to find the difference between 0.3 and 0.31, and (less so, because it was more recent) from 0.31 to 0.32.  I'd also like to see, for edification purposes, the differences between 0.3 (when I joined bitcoin after the /. article), and prior versions.
13  Bitcoin / Development & Technical Discussion / Verification of Coin Ownership on: July 17, 2010, 11:17:50 AM
Say I'm running a client, and I have 1,000BTC, and backup my wallet.  Then, I use the BTC to buy something.  Then, I re-copy my wallet, and my client assumes I have the 1,000BTC again.  Of course, if I use these coins again, the network will reject my payment.  On what metric does it make the decision that I no longer own the coins?
14  Bitcoin / Development & Technical Discussion / Network Size on: July 16, 2010, 11:04:44 PM
Is there any way to query the current size of the network, say, in connected clients, actively generating clients, FLOPS, or preferably, all three?  I see that my client is connected, and has been connected, to 15 clients for the past four days....yet somehow I doubt there are only 15 people generating coins.  I'm looking for this in the context of scalability assessments.
15  Bitcoin / Development & Technical Discussion / Post-Minting Phase and CPU Usage on: July 16, 2010, 03:52:00 AM
I've got a machine that I've left running "for the cause" for the past week or so since I found out about bitcoins.  Even though I'm skeptical of a few of the monetary policy claims behind the currency, I think an extra-governmental digital currency is in and of itself a positive thing, so I'm willing to run my machine more than usual to help out with the network.  I've got two questions regarding CPU consumption, which stem from the fact that my machine is a speed-stepping laptop.

1)I understand that 21,000,000 coins is the maximum.  How many total blocks will this be, given the logarithmic decrease of coins/block when we hit the 21M?

2)After all the blocks are minted, the network, as I understand it, will be responsible for validating transactions, and will receive occasional transaction fees as an incentive for running the system.  Currently, generating coins guzzles CPU cycles, but I can see no reason why the much faster transaction processing won't be far more lax on the CPU, as it won't involve literally constant crypto work.  Am I right or wrong here?
16  Economy / Economics / Inflation, Fractional Reserve, and Bitcoins on: July 15, 2010, 02:12:16 PM
I've seen a few claims, on these forums and elsewhere, that bitcoins, because they are limited in supply, are free from inflation, and once or twice I've seen claims that this set supply would eliminate fractional reserve bank policies.  Would anyone care to explain this to me? 

The way I see it, the supply of bitcoins is limited, yes, but its akin to the supply of, in the US, physical one-dollar bills.  The majority of the US economy, however, is not cash - it is credit, or dollars on account, both of which are backed essentially by loan collateral.  This collateral forms the basis for more loans than it is actually worth, and thus we have fractional reserve banking.  The limited supply of bitcoins will stand at 21,000,000 maximum.  However, this in no way prevents people from establishing accounts with bitcoin-equivalent units in them that do not actually exist - exactly as credit and savings accounts are done today.  These pseudo-BTC would be traded, just as loan-based pseudo-dollars are traded today, and there is no limit to their number, nor any protection against fractional reserve policies.  Am I going wrong here somewhere?  I certainly hope so, because if not....then I really don't see the advantage of BTC at all.
17  Bitcoin / Development & Technical Discussion / Hash/sec Throttling for Democracy on: July 13, 2010, 06:23:55 PM
I've seen a number of posts complaining that coin generation on old machines is impractical (actually, the posts say impossible, but that's not correct).  A number of others have espoused the general idea that flops*luck=coins, which seems to me to be about right.  One even advocated for OpenCL/CUDA support, which seems to me like it would give those with OpenCL capable cards an incredible advantage in the "flops" category of flops*luck.  

Now, some have said "If you have no luck, you don't get coins...." but come on here...we're dealing with computers - RNGs have nothing, really, to do with luck.  They operate upon statistical averages.  (If BTC is using a true RNG based upon machine atmospheric noise, I could be wrong here, but I don't know that such a generator would be practical in that it would be too slow).  

Therefore, why not cap the number of hashes per second?  If the operations were capped at say, 250khash/sec based upon system clock and not the available number of cycles, then anyone with the "minimum requirements" could participate in generation at no disadvantage to the guy with the TESLA cluster running CUDA (okay...so people aren't going to use TESLA clusters for this...but you see my point, I hope).  Of course, difficulty would need to be adjusted accordingly to keep block generation on pace, and checks for blocks generated clients violating the cap (and thus outpacing other clients by cheating) would be required, but these are matters solved with relative ease in the code.
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!