Can Electric isn't an electronics manufacturer, but Tom still needs to explain why he told people that an electronics manufacturer had taken over bASIC if that wasn't the case. You're getting the time frame wrong. The CAN-ELECTRIC scam was long after all hopes of the project completion were off the table. It's quite likely that Tom would have liquidated the domain during the time it happened. All it took was some scammer to offer him a reasonable price, then set it up that way. And by writing the rant such a way that it "sounded like" Tom, they could basically frame him in the eyes of everyone who saw through it, while themselves collecting from those who didn't. |
|
|
|
|
Thanks Tom. I'm guessing BitcoinASIC.com was liquidated and whoever bought it was behind the CAN-ELECTRIC scam? Would probably be good to clarify this for the benefit of the accusers here.
Wish you and your family the best.
|
|
|
|
|
For reference, this has been assigned CVE-2013-2272
|
|
|
|
I've been trying to figure out how to use stratum on this pool. My understand was that instead of using the proxy.exe you were just putting "stratum+tcp://us1.eclipsemc.com:8333" in the config file. However that does not seem to be working, what am I missing?
- Whether you need/want the proxy or not depends on your environment (mining software and number of rigs), not the pool.
- Port 8333 is bitcoin p2p, not for mining. Stratum uses port 3333 or 3334 usually.
|
|
|
|
While Bitcoin software is still in development, SatoshiDice provides an invaluable service to the network by stressing those attributes of the system that would become a larger problem in the future when adoption grows. No. Bitcoin is not meant to scale to SD's abuse. Also, while adoption grows, so does the overall network capacity to cope with higher (reasonable!) use. Finally, we already know Bitcoin is harmed by SD's abuse in practice. Continuing to "stress" something after you know it harms it, is clearly hostile. We probably wouldn't have performance improvements that we do (in bitcoin-qt 0.8.0) if it wasn't for SatoshiDice. So it seems like a natural component of the ecosystem at this point which might get less popular as the network rebalances and changes some of its characteristics that make SD viable right now. What-ifs are kinda pointless to argue, so I won't try. But even if SD is to credit for bringing attention to some performance problems, it does not justify their continued attacking. |
|
|
|
What some people here do not understand that it's not SatoshiDice that is to blame for the inefficiencies of the blockchain. That service is completely following the rules of Bitcoin. It's a fee-paying, fair service, I see no problem with that. The problem is with Bitcoin, not with S.DICE. That should be very clear.
No. SatoshiDice violates the "no flooding" and "financial transactions only, no information" rules. Bitcoin's solution is to block flooders. Miners filtering out floods is part of the system. |
|
|
|
Now that 0.8.0 is tested and out the door, please help test some of the stable maintenance versions  These are bugfix-only releases. Please report bugs by replying to this forum thread. Note that the 0.4.x wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. Also note that CVE-2012-4682 and CVE-2012-4683 are not fixed in 0.4.x: 0.4.x did not have any anti-DoS system at all, and that is not changed with this release. If you want to be secure against this class of DoS attacks (network flooding of invalid data to verify), upgrade to a newer version! As there will now be 6 stable branches, I am announcing the following end-of-life (EOL) schedule. - 0.4.x - EOL by 2013-11-21 (2 years after 0.5.0 released)
- 0.5.x - EOL by 2013-03-30 (1 year after 0.6.0 released)
- 0.6.0.x - EOL now: this is the last release of 0.6.0.x
- 0.6.x - EOL by 2013-11-21 (over 1 year after 0.7.0 released)
- 0.7.x - EOL by 2014-02-18 (1 year after 0.8.0 released)
- 0.8.x - Long-Term Support (LTS): 2-3 years after 0.9.0 released
These are not guarantees. If you need me to maintain any branch longer, please let me know ASAP. bitcoind and Bitcoin-Qt version 0.7.3 release candidate 1 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.5 release candidate 1 ( sigs) are now available for download at: bitcoind and Bitcoin-Qt version 0.6.0.11 release candidate 1 is now available for download at: bitcoind and Bitcoin-Qt version 0.5.8 release candidate 1 ( sigs) are now available for download at: bitcoind version 0.4.9 release candidate 1 ( sigs) is now available for download at: Important fix: These releases should not be vulnerable to Sergio's "know your peer public addresses in 14 minutes" vulnerability. See git for full changelog |
|
|
|
By the way do you have any feedback from someone who has tried it BFGMiner's "avalon" branch. Is it hanging? No, I just merged and pushed it tonight. It's pretty much just a clean merge at this point, so any hardware-related problems are likely identical to the cgminer Avalon. |
|
|
|
You dont have to use openwrt on the machine for routing / running bitcoind.
it seems you are looking for solo mining or p2pool? personally the solo miner should keep the connections to big known nodes.
I know learning to configure openwrt could be helpful, but it seems xiangfu wont let you install any other packages, so ipv6 on the openwrt of the embedded 703n is not possible unless you'd like to spend time recompiling.
I'm just excited / anxious about getting the box, I think I should prepare somehow and can't think of anything else intelligent to do. I've set almost everything in my SOHO/lab to work with IPv6, so I naturally thought I would do the same with the Avalon. I GPU mined for a few days on a couple of different pools, that seemed to go ok, though I'll never get close to the payout threshold with GPU. I've made a couple of PCBs, so I have a tiny bit of skill. I don't feel called on to do that much customization on the Avalon, as I view it as an appliance, at least until it is paid for. Still, it bugs me now that I don't have OpenWRT working. I don't really see how that is OT in a Bitcoin forum, but by all means feel free to go there. I need to customize image because: 1. I need 3g modem support as backup for the internet 2. I need openvpn so i could be able to access the unit remotely always 3. I need php so i can be able to view miner.php as i used to 4. I need snmpget, set so i can be able to automate power off on when there is a problem with the unit and it stops hashing for some reason. As stated power off/on is the only way to go for now 5. I need to be able to hack/upgrade cgminer as soon as something new pops up And i need 8M flash to do it:) Yeah... don't think you're fitting all that in 4 MB flash  Might try out BFGMiner's "avalon" branch while you're at it - they you could point it at bitcoind for GBT solo mining |
|
|
|
I'm coming up on 2 days uptime with BFGMiner 2.99.0 myself... pretty happy with how well it's working out so far - now I just hope the SC driver changes work without problems (haha). In other news, it took about an hour to basically just merge Avalon's cgminer fork into BFGMiner. It doesn't work nicely yet (the whole thing appears as a single Processor), but should work. And since the new driver API is abstracted nicely, you can build an Avalon BFGMiner that supports all the other devices as well. I don't have a complete firmware image for it yet, but that may be right around the corner since we already have OpenWrt support. Too bad I don't have an Avalon to test on.  I was actually surprised how simple merging it turned out to be. While the cgminer fork requires hacks, those ended up all being in code that I could just mirror inside the Avalon driver (since it's abstracted now). The code is under the git branch "avalon" if anyone wants to give it a go or check it out... |
|
|
|
You do understand that Bitcoin either suffers from higher fees at some point or weakens and dies completely? Yes. "At some point" needs to be after Bitcoin has attained critical mass of adoption. The only question with option 1 is how much the fees will rise, not if they will rise. And when they rise. Timing is everything. |
|
|
|
I don't think that trying to ban S.DICE is a proper solution to anything. Higher fees are a solution, even if it does affect regular usage somewhat. As far as I know, majority of S.DICE transactions come from martingale bots which would be very much affected by higher fees. For the martingale strategy even small differences make it much more suicidal. It's exactly these kinds of spammy gambling transactions that should be deincentivized. Transaction fees are just another form of a ban, one that is suicidal to Bitcoin in this scenario. |
|
|
|
I believe S.DICE is one of the top 5 services in the Bitcoin economy and it has brought a massive amount of publicity and new users. I also think it's plain wrong to somehow say it's a "lesser service" because it is gambling. It's a service that has demand and adults should be free to play with their money if they want to. Sure, that's fine with me (though I bet not the State of New York), but he can't justify attacking the network with "publicity" that only brings a few fools and government crackdown. There is no evidence there are any "massive" amounts of new users involved of any sort. The problem it causes for the blockchain can be solved by simply smoking it out with fees. I mean, services such as S.DICE will be hurt more than anything by higher tx fees, which would be a certainty if the block size max is kept untouched. They would be the first to consider an alternative way which doesn't use the blockchain. Did you even read my post? The problem is that increasing the fees to "smoke it out" would kill Bitcoin adoption. Do you really want that? The reality is there already are alternative ways that don't use the blockchain; SD just refuses to do things efficiently. This is very off topic and I'm already tired that we have 100 threads in this forum about this same issue, but I'm starting to agree that we actually should smoke out certain services by not touching the block size max until it hurts them. I mean, let's see if users of S.DICE truly want to pay for it, or not. They almost certainly will. Gamblers are psychologically inclined to tolerate a higher fee than rational transactors. |
|
|
|
First, SD has paid more mining fees than everyone else in the world, combined. Just because you pay the fine for vandalism, does not mean it's acceptable to vandalize, or that it covers the expense in cleaning up the mess you made. Even with the "standard" transaction fees, miners are still subsidizing transactions at their own (direct) expense in hopes of improving their (indirect) gains from the increased value of Bitcoin as adoption increases (which depends a large part on lower fees right now). <meaningless propaganda> SatoshiDice achieves all this publicity, demonstrates the power of Bitcoin and provably fair gaming to the masses, and brings Bitcoin to the attention of casino operators around the world, and yet still people complain because it "makes too many transactions" and for their antagonism decide to block SD transactions from their mining pools  SatoshiDice does nothing beneficial for Bitcoin. What little adoption it brings is from irrational gamblers and the casinos out to exploit them; these are not the kind of people who improve the value of Bitcoin at all, just make it more likely to be banned. What it does do is flood the network with abusive "transactions" conveying more information than finances ("I bet x BTC", "you win", "you lose" are information), using more activity than any payment network today could handle (relative to actual usage). Other reasons aside, this alone would get your attack blocked by VISA et al. Bitcoin attempts to block this attack as well: even in the original paper, miners are expected to deal with flooding attacks. Obviously the original suggestion of using merely fees is not sufficient, since SatoshiDice uses social engineering to fool gamblers into paying 100% of the cost to bypass this anti-flood measure. While we could simply increase fees until the flood stops, the extent we would need to do so would effectively kill adoption of Bitcoin. Blocking SD directly is the only known viable method of Bitcoin surviving this attack. Note that Bitcoin is a lot of things, but it is not meant to ever be more efficient than other processing networks like VISA. Centralized services are by nature more efficient, so that is unavoidable. You refuse to stop flooding the network, and insist we deal with it ourselves. Blocking SD outright is how Bitcoin deals with this kind of attack. Deal with that. Of course, the best way forward is for you to stop attacking Bitcoin. There is nothing inherent in SD's design that necessitates the flooding by any means. A similar service (that I would setup myself, if it weren't illegal) could be done very easily: - Use compressed public keys for everything. There is no need to waste 2x the space for no gain by using uncompressed keys.
- When a user visits your site, prompt for a withdrawl/cashout address immediately, so there is no opportunity to lose bitcoins. This fixes your bug whereby SD is assuming the first input's previous destination happens to be a valid return address - this bug causes bitcoins to be lost in all cases it isn't true, and creates real security problems when Bitcoin implements post-quantum cryptography upgrades (currently, post-quantum crypto requires that addresses never be used more than once).
- After users provide their cashout address, give them a deposit address. They send however many bitcoins they want to gamble with.
- Display the gambling game(s). Let the user play as much as they want, with instant feedback. RageCoin has an example of just one way to have easier and instantly-verifiable provably fair gaming.
- When the user is done (leaves the site, clicks a button, or just stops doing anything for N minutes), send whatever balance is left to their cashout address.
Edit: And in case anyone thinks SD would somehow be less "popular" with these changes, note that they could very well support both ways of using it and find out for sure. (not that there's any doubt in my mind) |
|
|
|
I know they all need unique IP but I'm surprised they're not configured to use DHCP by default. Anyway, I'll see when my unit arrive.
Why they must use DHCP by default? 95% devices I saw, was configured with static address, cos users often don't have any dhcp-service running. Even more complicated hardware (for example ISP hardware) have static addresses by default... If device have dhcp client enabled by default, it have fallback option to preconfigured ip address or custom software to change ip address without any address binded. Huh? What decade are you living in? Everything made for end-users today assumes a DHCP environment. If by end user you meant someone who can barely use a router... Sure, the wan will be dhcp and lan have a static ip with dhcp. But all other gear for people with a clue, well supposed to have a clue like a bitcoin miner, static ip is very reasonable. No ISP gear has dhcp turned on by default like a switch, router, dslam, etc... Only because DHCP can't scale to networking. DHCP is the routing protocol for last-hop; would you run your ISP equipment without any routing protocols? Your point is true. But cant you imagine if they did use dhcp? Ppl would be saying they plugged it in but cannot figure out the ip. Then ppl would say download nmap to do a ping scan.. And etc... Using a static ip is reasonable to me. A lot of gear comes that way. Well at least specialized gear that is. You make a good point, but at least it can be accessed on a normal network this way. And I suspect most home routers come with a handy interface to view the DHCP lease table along with hostnames of each machine. Now if only they more consistently ran a local DNS server like mine does (I can just ping nameofdeviceIjustpluggedin), it'd be perfect.. |
|
|
|
I know they all need unique IP but I'm surprised they're not configured to use DHCP by default. Anyway, I'll see when my unit arrive.
Why they must use DHCP by default? 95% devices I saw, was configured with static address, cos users often don't have any dhcp-service running. Even more complicated hardware (for example ISP hardware) have static addresses by default... If device have dhcp client enabled by default, it have fallback option to preconfigured ip address or custom software to change ip address without any address binded. Huh? What decade are you living in? Everything made for end-users today assumes a DHCP environment. If by end user you meant someone who can barely use a router... Sure, the wan will be dhcp and lan have a static ip with dhcp. But all other gear for people with a clue, well supposed to have a clue like a bitcoin miner, static ip is very reasonable. No ISP gear has dhcp turned on by default like a switch, router, dslam, etc... Only because DHCP can't scale to networking. DHCP is the routing protocol for last-hop; would you run your ISP equipment without any routing protocols? |
|
|
|
I know they all need unique IP but I'm surprised they're not configured to use DHCP by default. Anyway, I'll see when my unit arrive.
Why they must use DHCP by default? 95% devices I saw, was configured with static address, cos users often don't have any dhcp-service running. Even more complicated hardware (for example ISP hardware) have static addresses by default... If device have dhcp client enabled by default, it have fallback option to preconfigured ip address or custom software to change ip address without any address binded. Huh? What decade are you living in? Everything made for end-users today assumes a DHCP environment. |
|
|
|
Hi
I've got strange problem with mining under OpenWRT Attitude Adjustment.
BFGMiner sees ZTEX and started to mine but I've got about 99,9% of HW errors.
The same FPGA has not any problem under Windows on the same active USB hub.
Do You have any idea what is wrong ?
Not 100% hw errors? Some shares are accepted? Or are they all hw error? |
|
|
|
While there aren't any special checks on transaction data (yet), just fetching it means someone could be checking it, and deters any possible abuse.
Put another way, are you going to rob a vending machine if your bosses are all standing right there, even if they're not specifically looking for foul play at the moment?
It's already actual, since pools can't know who is or isn't verifying what.
Umm what? So you just said that there is no verification of the transaction data that GBT sends. So if there is no double checking, how is there an actual increase in security? Say my boss installs a security camera by the vending machine, purposefully doesn't turn it on, and then leaves the room. We both know there's a security camera, but we both know it's not working. Is there an actual increase in security? Am I actually deterred from stealing? I would say no. This is more like he installs a security camera, leaves it on, but "never" looks at the monitor/tape attached. You really don't know if today might be the day he checks it... |
|
|
|
Is it possible BitMinter is vardiff and the others are not? Could be a clue. I will check it. But I have a low hashrate (<50MH), IMO even if vardiff, I can't be on a higher diff… Hmm, yeah, it would be strange for 50 Mh to hit a higher diff. Can you get it to behave more as expected by using older versions and/or --no-stratum? Maybe try --no-gbt --no-stratum both as well? The community-developed standard ("new bitcoin way") is getblocktemplate (GBT). Stratum supports less functionality, was developed behind closed doors, and uses more bandwidth than GBT unless used in a way harmful to Bitcoin. Oh, sorry for my mistake, this is bitcoin.cz which confusing me, because they push all the pool to stratum. Ok for GBT, but is there any way in bfgminer to enable stratum only on some pools ? --no-stratum disable it for all pools, but some need it (bitcoin.cz e.g.) ! --no-stratum only disables automatic switching from getwork/GBT. You can still specify the stratum URI manually. eg stratum+tcp://host:port |
|
|
|
|
Show Posts
