It was irrelevant? And obvious from the photos showing BFL's location too. I wasn't thinking about bets when I made the post, let alone that some bets might or might not have hinged upon trivial things like this. |
|
|
|
If you want to 'encourage and enable' Bitcoin, then do what everyone else does, make reliable software for it that works and facilitates trade as well as promote Bitcoin itself in a passive way Yes, that's what I tend to do. I'm not the one who constantly brings up religion. |
|
|
|
I'm surprised nobody has mentioned betsofbitco.in and the BFL unit, when BFL has not shipped anything but merely let Luke-Jr ssh into it
I accepted a hosted device I paid for in full 10 months earlier, which had been losing value rapidly for months since competing ASICs had delivered. Wouldn't anyone? It's unfortunate that a certain wager was badly worded such that a single delivery satisfied it, but IMO it's a bit unreasonable to blame me for that. |
|
|
|
What particularly pisses me off is the way the 'Bitcoin' foundation has tried to hijack this currency instead of just making their own one and establishing their own rules about the currency, that would be a better use of everyone's time. Then surely you agree with my points about how the Foundation should encourage and enable Bitcoin rather than try to control it? Question about whether BCF should control bitcoin.orgI think the Foundation should focus on its mission; being a centralized point-of-control would not only be outside that mission, but IMO would be contrary to it. That is, it should offer assistance to help improve Bitcoin-related websites, but not try to take control of them. Bitcoin.org as it is today seems to be a very helpful resource, without the Foundation's needing to get involved in it. Question about what the BCF should/shouldn't do in generalShould do: - Promote legal uses of Bitcoin.
- Provide educational materials (of both technical and legal nature) to help merchants safely transact using Bitcoin.
- Help Bitcoin informational websites improve their content.
- Encourage developers to participate in Bitcoin code review, even if they are not themselves developing Bitcoin code.
- Encourage Bitcoin developers to use the Bitcoin Improvement Proposal standardisation process for protocols which need interoperability between software.
- Encourage users to help test Bitcoin software.
- Political lobbying to ensure Bitcoin remains a legal currency to trade with.
Shouldn't do: - Promote illegal use of Bitcoin, or otherwise encourage governments to make Bitcoin illegal or overly regulated.
- Make Bitcoin sound better than it really is with false statements.
- Promote Bitcoin as merely a means to some ulterior motive/end (eg, anarchy or tonal).
- Take control over Bitcoin websites, services, or software.
- Fund development of non-free (closed source) software or proprietary protocols.
- Discourage users from adopting competing Bitcoin software.
One simple idea for expansion might be funding an effort to discover and document the intricate details of the Bitcoin blockchain protocol. Question about whether the BCF should act to prevent tax evasion and such civil violationsI'm not sure the Foundation should take an active role in this. It could perhaps, however, publish clear legal guidelines for paying taxes in major countries and/or prepare and offer educational documents to law enforcement on how to trace bitcoins through the blockchain. Request for elaboration on how BCF could publish clear legal guidelines when legalities are not clearI didn't have anything specific in mind here, just was giving some examples. While the legal rules around Bitcoin are too uncertain, it would seem reasonable for the Foundation to give some attention to getting them clarified. Taxes are an important issue to solve for adoption - otherwise it's usually easier for companies to just ignore Bitcoin, despite its benefits. Solving it may take time/research/lobbying, but eventually Bitcoin needs to be able to provide businesses with some level of legal comfort. Question about whether it will be helpful to grow BCF membership and funding, if people know it is issuing grants to develop forensic blockchain analysis docs/toolsThese documents and/or tools will almost certainly be developed whether or not the Foundation has a part in it. Making them available to everyone only improves the situation: - By involving Bitcoin experts, it avoids incorrect assumptions resulting in arrests on bad reasoning (for example, someone was recently the target of police investigation because blockchain.info claimed their IP address had broadcast a transaction).
- People concerned about their own privacy can audit their own public trails, and improve on their precautions.
- Bitcoin wallet developers can make better-informed decisions on how to improve privacy with the same information.
- Law enforcement and prosecutors gain positive experience working with the Bitcoin system, and are less likely to want to simply ban it outright.
If the decision to fund these kinds of projects is made, I certainly don't think it should be kept secret from members. In fact, it might be a good idea to make a list somewhere of all the different kinds of projects/goals the Foundation has assisted with. Question about BCF's role in changing block size limitsWhen the block size limits begin to become a problem (I don't expect this to occur any time soon), it might make sense for the Foundation to sponsor research into what solutions may be available at the time, if a solution has not already been found by then (which seems unlikely, given all the early attention this problem is getting). The Foundation certainly should not try to assert some kind of authoritative declaration of which solution is to be adopted, but should leave that decision to the economic majority where it naturally lies. Should there be problems reaching a consensus, it might make sense to assist in ensuring the competition and eventual transition goes smoothly. Also, note that I haven't ruled out it being a problem sooner rather than later either. I am looking forward to reading Gavin's upcoming whitepaper on the topic, and would of course, as with anything else, consult with the community before any action as part of the board. |
|
|
|
I'm particularly against agendas of this sort which focus on promoting tax evasion, anarchy, or other anti-government activities. I'm against pro-government activities particularly starting wars, drug prohibition, counterfeiting and other violent acts against otherwise peaceful people. Guess we are diametrically opposed. Surely you can oppose those things without trying to force it on everyone using Bitcoin? |
|
|
|
I've got the basic concept working as a new driver for BFGMiner: CPU 0: | 3.71/ 2.52/ 0.00Mh/s | A: 0 R:0+0(none) HW:0/none
SGW 0: | 82.29/89.74/100.6Gh/s | A:2035 R:0+0(none) HW:0/none
SGW 1: | 12.05/22.13/22.13Mh/s | A: 1 R:0+0(none) HW:0/none Each username creates a new SGW virtual device, and hashrate is measured by shares. In this case, I have my main dev miner running on SGW 0, and a lucky CPU miner on SGW 1. |
|
|
|
Would it be possible for the importaddress function for watch-only wallets to be merged in? This is something that merchants & services desperately need - to be free from thirdparty sites like blockchain.info Here it is: https://github.com/bitcoin/bitcoin/pull/2861That's just watch-only addresses, and not necessarily useful when you need watch-only wallets (ie, every real-world use case). It missed the merge window for this next-test (it was outdated code and unmergable when I made this), but perhaps it will make it into the next one. Please also remember next-test is not necessarily a good idea to run in production. You can easily get a watch-only wallet today by using keypoolrefill with an absurdly high number (5 times your expected transaction volume is good) on your spending client, making a backup, and using wallet encryption on that backup with a crazy-long password (you can/should throw away) to destroy the private keys. Note that this will break after <keypoolrefill number> transactions, and is probably pretty dangerous to try for non-experts, but if done right can get you a watch-only address that works until Bitcoin-Qt has real support for them. sipa is working on HD wallet support for Bitcoin-Qt (a prerequisite to real watch-only wallets), so I expect we should see that pop up sometime before 0.10 is released. |
|
|
|
Yes, its working. And will need to disable BFL in the second instance now  Thank you Luke, what I need to disable LS? Thanks Is -S bitforce:noauto really so hard to guess?  |
|
|
|
Where is the version of bfgminer for android (not the bfl version)
You get to compile it yourself... Could you be bribed.. with BTC? Possibly, but when I looked at it last, it would be numerous hours to figure out how to build Android's bionic library sensibly. On top of that, I haven't the slightest idea how to make an Android package or upload it to Google Play, and I suspect doing so might not be possible with free software.  It'd probably be much faster/cheaper to find someone who does regular Android development. |
|
|
|
Where is the version of bfgminer for android (not the bfl version)
You get to compile it yourself... |
|
|
|
Hi Luke,
I cant disable my eruptors with --disable-icarus in my .bat. They working together with my BFL LS, but diff 32 is too high for them. I wanna run them with other worker with diff 1
--disable-icarus is a compile-time option. -S erupter:noauto should do it |
|
|
|
Yeah, for more than 5 Gh/s or so you definitely want to use GBT or stratum with a difficulty much higher than 1 |
|
|
|
I think it's only plagerism if they copy the results?
In any case, I'm not aware of any formal produced research, just observations and solutions.
Nope... plagiarism is the use of ANY (non-general knowledge)material from another source , without giving proper recognition of the material. It can be an Idea, data, research... OR EVEN material you have previously produced YOURSELF!!!! Ok, but maybe in this case they didn't know anyone had done it before, and came up with the same concepts on their own? |
|
|
|
In this case, the work does not cite a single piece of the industry discussion of block propagation timing concerns or potential solutions which occurred prior to and during the time under study. While this complaint is not unique to this work, I've reviewed preprints which have done far better, and I do not believe some other authors' similar behavior excuses the exclusion of the relevant citations here.
Then send them and the IEEE a plagiarism warning, because basically they have failed to perform due diligence and correctly research the subject matter prior to publishing the paper. If the paper covers research that has already been produced and they have failed to accredit the original researchers, it is plagiarism. At the very least the IEEE will investigate the claims, and if necessary get them to retract/amend the published paper. I think it's only plagerism if they copy the results? In any case, I'm not aware of any formal produced research, just observations and solutions. One practical problem here is that you can't effectively observe all forks. Your peers actively work against you seeing them, and in some cases they never leave the miner at all (eg, when they are also a stale share). |
|
|
|
The program runs perfectly, hash rate is good, but should I be concerned about these compilation warnings? util.c: In function ‘notifier_read’:
util.c:2564:2: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result [-Wunused-result]
util.c: In function ‘notifier_wake’:
util.c:2554:2: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result]
util.c: In function ‘json_rpc_call_completed’:
util.c:504:6: warning: call to ‘_curl_easy_getinfo_err_string’ declared with attribute warning: curl_easy_getinfo expects a pointer to char * for this info [enabled by default] These are bugs in your compiler and libcurl, fixed in newer versions of such, and harmless in any case. |
|
|
|
when the temperature reached 86 C on one BFL device, that device was not disabled. Do I have to setup any other "auto" parameters for temp-cutoff to work?
After a careful review of the code in question: - --temp-cutoff acts when the temperature exceeds the argument. This is how BFGMiner/cgminer have always interpreted the value, so this is a documentation error.
- While a device is resting, the hardware error counter continually increments. This is a regression in 3.1.4 (older versions worked correctly).
- It works for me, with the above in mind.
|
|
|
|
Hey there, I`m having a little issue with my block erupters on BFG 3.1.4. I appears like BFG might be adding a phantom erupter, and so I have two number 9`s.  Any ideas? The only way i`ve managed to get rid of this is to restart bfg, but I`d like to keep it going. Thanks. It's just a rendering glitch if they have the same id. |
|
|
|
This seems like a serious problem!
Apologies if I am asking a question with an obvious answer, but is there a way a user can easily check to see if the same random number was used for a second transaction before broadcasting it?
It's not much of a problem if you're using Bitcoin correctly (ie, not reusing addresses). That can't possibly be your proposed solution to this problem - "Just never use a bitcoin address more than once"? No, not the solution. Just pointing out that this isn't a serious problem, just a problem that's pretty important to address. On the other hand, if whatever's causing k to be the same is also causing the private keys generated to be weak, that of course definitely would be a very serious problem... While it makes sense for privacy reasons, it shouldn't need to be done just so you don't get your coins stolen. Address reuse has never been just a privacy issue. Even with correctly chosen k values, there are still theoretical coin-stealing risks to address reuse. And even ignoring coin-stealing risks and privacy issues, there are still other problems from address reuse (that slip my mind at the moment). Hmm... so none of the clients mentioned re-use an address for change (as this is not something the end-user generally has any control over)? If a client is reusing addresses like this, it reveals a fundamental misunderstanding of how Bitcoin works. Then the question I'd be asking myself is, do I want to trust this author got k correct, or doesn't have other subtle problems in their implementation? |
|
|
|
This seems like a serious problem!
Apologies if I am asking a question with an obvious answer, but is there a way a user can easily check to see if the same random number was used for a second transaction before broadcasting it?
It's not much of a problem if you're using Bitcoin correctly (ie, not reusing addresses). |
|
|
|
What font is your console using?
Is it this？  and my system is win7 64bit Simplified Chinese version I'm sorry to say that I cannot read Chinese Can you figure out what the font is, and whether I might be able to download it somewhere? As a temporary workaround (but let's keep trying to get it fixed!), you can use --no-unicode |
|
|
|
|
Show Posts
