|
Starting a new block chain tends to imply the new block chain having much less "strength", making it easier to gain >50% network power.
|
|
|
|
If the ".0" workaround is not desired, it should be easy to back out just that one commit. However, it should have no negative effects, and avoids money-handling problems with buggy JSON implementations (which there seem to be plenty of).
Can you be more specific? I know of jansson, which has problems because the author arbitrarily declared all integers in his API to be 32-bit. What other problematic implementation exist? I'm no expert on all the JSON libraries out there, but the one embedded in BitCoin had such a bug-- if a JSON number looks float-ish, it will error if the code tries to access it as an integer. This bug is out of necessity fixed in the ".0"-adding commit. If we simply output the raw int64, this is an unrelated bug. So, jansson remains the only known JSON implementation that has trouble with int64 values? |
|
|
|
Hi guys, I'm new here. I just started mining with HD6870 using the OpenCL miner. I'm doing about 210Mhash/sec, which according to the probability calculator ( http://www.alloscomp.com/bitcoin/calculator.php) means that on average I should generate a block about every 8 days. Instead, I have generated 3 blocks in about 4 days. This can mean two things: 1. I'm extremely lucky, or 2. the rate calculator is not quite right. You were lucky. In 3-4 days, my 1000 Mhash/sec generated no blocks. It's a lottery. Over time you should see the statistical average, but right now your sample size is tiny. |
|
|
|
If the ".0" workaround is not desired, it should be easy to back out just that one commit. However, it should have no negative effects, and avoids money-handling problems with buggy JSON implementations (which there seem to be plenty of).
Can you be more specific? I know of jansson, which has problems because the author arbitrarily declared all integers in his API to be 32-bit. What other problematic implementation exist? If everybody except jansson works with 64-bit integers (the bitcoin native coin size), I'd be OK with moving forward. We can deal with a single, buggy implementation. Perhaps I could even contribute an int64 patch to jansson's upstream. Now, back to your proposal. 1. I agree with a proposal to change RPC to showing native int64 values for monetary amounts, in JSON output. No special tricks like $coin.0. 2. I disagree that this issue, alone, requires a breaking change to RPC. It's "nice to have" but not a driver for inclusion. 3. I strongly disagree with multi-version code at this early stage in bitcoin's life. We should just pick an RPC version and stick with it. |
|
|
|
Berkeley DB is quite common on Linux -- certainly more common than xSQL. It's also easy to compile, and it has no dependencies of its own.
BDB is common on Windows, too, but nobody sees it because it's embedded in your applications. And because BDB is embedded (linked) into your application, no external server is required (unlike MySQL). |
|
|
|
Thanks for posting an easy-to-review diff. Comments: - We should not support multiple RPC versions in the same binary. We are at 0.3.x, early in bitcoin's life. If we need to change the API, we just change it. Adding a 'version' arg to many functions pointlessly increases complexity.
- However, I don't see a driving need to change the API just for this issue.
- It is strange that SelectCoinsMinConf() needs any change at all.
- In general, I understand the desire to avoid faux-floating point in JSON output, as is currently done, but "$nanocoin.0" seems like an absurd attempt to avoid weird implementation issues, when those issues should instead be confronted directly.
|
|
|
|
Out of curiosity, why does the wallet use an external dependency (Berkeley DB, now "owned" by known-open-source-killer Oracle) in the first place, rather than something ubiquitous like XML (or if purely flat, even CSV as you mention)?
Because it's a database, and thus easy to use, compared to building your own file format. |
|
|
|
Would this be a group of volunteers working with merchants in an effort to help expand the BTC economy, or a group looking to charge those merchants for the service of helping them get set up to use BTC?
A business that charges for its services seems more sustainable. |
|
|
|
This post got me thinking about bitcoin support. Most major open source projects have consulting and technical support readily available to newcomers. As the linked post illustrates, individuals -- especially entrepreneurs that we want to attract -- need ready access to bitcoin-knowledgeable technical support personnel and software programmers. To that end, one hopes that https://en.bitcoin.it/wiki/Trade will grow a "Bitcoin Support" section, listing qualfied individuals and organizations willing to do tasks such as - Patiently explain how the block chain and P2P network works
- Troubleshoot bitcoin software installs
- Assistance with backing up, encrypting and securing a wallet
- Integration of bitcoin into existing websites
This thread is now open for comments (or orgs promoting their support services?). Disclaimer: I am speaking solely as a bitcoin activist, who thinks this will help bitcoin succeed. I have no interest in running, participating, or investing in such a business myself; I already have a day job 
|
|
|
|
Can someone please give me a list of the pros and cons of using new Bitcoin addresses for each transaction? It seems very inconvenient to use a new address each time.
warning, I am a newbie...liked the videos presentations, did some research...and tried it. Bitcoin.exe on an i7 --only application---24/7 x 10 days---on generate mode. Only successful in the gratuitous .05 BTC from faucet per computer per public ip address. I had plans to accept Bitcoins on all my websites...hired web developers ...faced ZERO SUPPORT ANYWHERE. Bitcoin definitely needs to grow some organizations that can offer technical advice and software support for bitcoin itself. Most major open source projects have one or more companies doing this. That would help with bitcoin adoption, too. So question number ONE. What happens to the Bitcoin if I don't use it, save it? I speculate it ONLY serves to increase the value of those users and optimists who are "fan boys". I have spent too much time...wasting...which cost me more money than I could have possibly made in two weeks.
Bitcoin is a currency, literally, in its infancy. The concept (distributed notary service with digital signatures) is, as far as I know, the first of its kind. It is still being "bootstrapped," meaning that bitcoin does not have a self-supporting economy -- which must, by its nature, encompass mundane things like buying gasoline with BTC, paying rent or mortgage with BTC, buying groceries with BTC. So, what can you do with the bitcoins you have right now? Not a lot, if you ignore bootstrapping services (services like currency exchanges or bitcointo.com). Mostly software services like web hosting, and an odd assortment of tangible goods. But it seems like most folks in the bitcoin community recognize that we just started construction of a very interesting and unique experiment in currency. Any endeavour is, unfortunately, very high risk from an investment standpoint. It might fail for dozens of reasons... but wouldn't be fun and interesting if it succeeded? Question Number Two. My PC's were set up by my SYSADMIN's. After a few bouts of "actvity"....I ended up with 100% CPU on all cores...and the "connect" prompt says unconnected. Thats a lot of power and CPU cycles for Nothing...a big fat waste of time. You want me to be impressed so we can get the concept moving? Put up simple to understand "NOOB" isms...so that morons like myself...can learn HOW to connect. If no connect...why the 100% CPU on all cores and NOTHING going on? FOR DAYS? I don't have time for games. When you guys are serious...I'll be back. I love all the concepts supporting it...but I will not GIVE AWAY valuable product from my websites for coins that have no value TO ME.
Step 1: Turn off "Generate coins" option. It is a waste of time and electricity. Step 2: Wait for all the blocks to download. As of this writing, there are 109245 of them. Step 3: Don't panic, and read the forums. If you can post specific problems you are seeing after following steps #1 and #2, you can get answers. Step 4: Hire better SYSADMIN's. They should be able to answer these basic questions and offer basic support, or not install software that neither you or they understand. |
|
|
|
There are too many variations in GPU hardware and thus too many dependencies to deal with. You dont need to code direct to specific GPU configs, this is dealt with in the divers behind the API's of DirectCompute or OpenCL. (There could well be performance wins for coding the hash algorithms direct to the register specs of either say ATI or NVidia GPU's but i dont think people are utilizing that with the GPU miners for exactly the same reasons of hardware dependencies) There are a zillion and one SDK versions, all proprietary and changing rapidly. This is a huge effort for a program that runs on Windows, Linux and Mac. We have enough trouble just getting the current Windows code to build, as it is. It is far more likely that we remove the CPU mining code from bitcoin, than add GPU mining code. |
|
|
|
|
Please post a link to a diff versus mainline bitcoin, showing just your RPCv1 changes.
It increases the burden on reviewers, if we must clone and diff and do all sorts of things, just to see what changed.
Thanks.
|
|
|
|
VISA is a private company that offers as a service the protection of fraudulent transactions. I believe that if bitcoin grows people will offer similar services.
mcdett has it right. VISA and PayPal are services layered on top of a base currency. Neither the Euro nor the US Dollar has any fraud-protection services attached to it; if your Euros are stolen, your only recourse is calling the police. And their job is to catch the criminal, not get your money back. Same with bitcoin. All we need to do is provide a sound base currency that prevents double-spending. The rest can be left to outside services. |
|
|
|
While Bruce's prediction seems wildly optimistic, almost anything could happen given the very small float of btc that are out there. The virality of the web can cause astounding things to happen.
Forget a shiek. If just one medium-sized virtual goods company, or a tipping company like Flattr or Kachingle, or a second-tier social network like Friendster or Hi5 started using bitcoin who knows where the price could go.
Quite true, though I really wonder now if bitcoin will ever be used for micro-transactions or in-game / in-network simple currency. If bitcoin becomes remotely popular, you're looking at amounts such as 0.0001 BTC. I imagine that people will create their own micro-currencies (like Microsoft or Facebook Points) backed by bitcoin, rather than directly using bitcoin, simply for user interface issues such as presenting "400.00 points" rather than "0.00000385 BTC". |
|
|
|
Updated.
Do you happen to have a git repository of the code? No, just the URL. |
|
|
|
Do I interpret your meaning right when I say that the code — for each value of nonce — intends to calculate the SHA256 digest of the precalculated value (intended to stay constant throughout the loop) updated with the nonce? If so, that is not what the code does. Please see this simplified example:
Well, that is disappointing. If true, yes, that is a bug. Updated. |
|
|
|
|
My cpuminer work on Windows (32-bit) as well as Linux.
No build environment yet for Windows (64-bit), alas.
|
|
|
|
|
Show Posts
