I started it with my comment, so an explanation is due: I don't think I'm touchy because of scams, but because I feel people - even nice people - often manage to convince themselves how world is full of selfish assholes who would never return lost or stolen property to the original owner. This assumption makes even nice folks act not-so-nicely, in defense from an erroneous image of reality.
Things are better than that, but will keep getting worse if we assume the worst. I am sure the majority of people reading this would return the money sent to them by mistake like this. There's a saying that an optimist is a happy idiot, and a pessimist a sad idiot... Most people are by default evil and won't do something good without some ulterior motive. On the other hand, most people have motives: staying out of jail, better reputation, etc. The approach I usually try to use is to assume the best of people, but expect the worst. That being said, this forum is particularly full of trolls. While I can't speculate on readers, realistically I think the majority of people who might reply to this post would not return the fee. |
|
|
|
|
What confuses me is how people can presumably-accidentally waste this much money, and apparently never even notice so they can try to recover it.
|
|
|
|
The code in findnonce.c leaks the contents of work structures. It seems that postcalc_hash() should call "clean_work(&pcd->work);" before "free(pcd);". Good find. Also, postcalc_hash_async should use calloc instead of malloc, otherwise when it calls __copy_work which calls clean_work, there is a risk that clean_work will try to free uninitialized pointers. Immediately before __copy_work, it initializes *pcd. Per the C standard, any unnamed field is initialized to 0 this way (and calloc has some potential portability problems, since it initializes byte-for-byte; eg, null-byte floats might not be zero on some platforms). This problem likely exists elsewhere in the code. Several other source files use __copy_work but not clean_work, which is suspicious. Perhaps it would be safer for all work structures to be allocated on the heap with make_work rather than embedded in other structures. The Icarus/ModMiner usage never frees the structure containing the work, so they're cleaned implicitly whenever __copy_work goes to replace them. |
|
|
|
Well.. finally making progress on my chargebacks no thanks to Thomas McScam
Have two paper checks FINALLY being ripped and sent via mail...
Opt'd to keep a negative balance on one card and just use that one more..
Thanks for all the hassle Tom McFuckFace!
What are you talking about? Last I heard, 100% of credit card orders were refunded a long time ago. |
|
|
|
I dont think what SD does is good, but blocking addresses isnt really in the spirit of bitcoin  I'd welcome a better solution myself, but I haven't been able to think up something that works without screwing up Bitcoin adoption at the same time. |
|
|
|
I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing. Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries. What device(s), pool(s) etc? Can you post a debug.log somewhere? I'm using the following command line (user and pass obfuscated): bfgminer ^
-o http://us.ozco.in:3333 -u uuu -p ppp ^
-o http://mint.bitminter.com:8332 -u uuu -p ppp ^
-o http://us3.eclipsemc.com:3333 -u uuu -p uuu ^
-o http://api.bitcoin.cz:8332 -u uuu -p uuu ^
--disable-gpu --no-submit-stale ^
-S all
Debug output here: http://pastebin.com/gj9LnKidUsing the same command line, 2.99.0 uses 0% cpu but 2.99.1 uses 100%. The pastebin output is from bfgminer 2.99.1. This is a system with 2 BFL Singles only. Can you meet up with me on IRC for some more aggressive investigation? |
|
|
|
I've uploaded alpha2 Windows builds of BFGMiner 3.0 for testing. Luke: 2.99.1 uses 100% cpu on my system. The previous 2.99.0 uses 0%. Same settings for both. Operating system is Win7/64; I'm using the Win64 bfgminer binaries. What device(s), pool(s) etc? Can you post a debug.log somewhere? |
|
|
|
OK, there is a patch for miners to blacklist SD tx's from being included in blocks...
What about a patch for normal nodes to blacklist the relaying/verification of SD tx's and drop them without relaying/verifying? The patch I posted should prevent relaying, but still checks one direction so it can detect the other. Where'd you post? |
|
|
|
OK, there is a patch for miners to blacklist SD tx's from being included in blocks...
What about a patch for normal nodes to blacklist the relaying/verification of SD tx's and drop them without relaying/verifying? The patch I posted should prevent relaying, but still checks one direction so it can detect the other. |
|
|
|
|
The value affects the average expected spend amount, so would influence the minimum payout.
I'd wait a bit and see if the new price holds for a month at least first, though.
But last I heard, wizkid057 was planning to make it user-configurable anyway.
|
|
|
|
If the Devs really think SD is a problem, they haven't seen anything yet. Bitcoin can't handle more than 1000 transactions a second? There is no way a Bitcoin will have value in 20 years! Handling 1000 transactions per second for 10 active users (SatoshiDice) and handling 1000 tx/sec for 100000 active users are two totally different things. The latter grows the infrastructure, the former overloads it. Filtering out satoshidice transactions would make it trivial to double spend a losing bet. If it takes double-spending to stop SD's abuse, then it's good that it's easier to do. If SD is going to take the "tough, we don't care about the problems we cause" road while they abuse the network, I don't see one reason why the network should give a care if miners exercising their by-design choices makes SD more vulnerable because they don't even follow common best practices in accepting transactions.
While I agree that eventually the block size limit may need to be raised somehow, that day is far far in the future. With miners doing their job filtering out flooding attacks (the only major one currently being SatoshiDice), we are nowhere near even the soft limit being a concern. Bitcoin's scaling problems are mostly limited to using the blockchain. There are many ways to avoid using the blockchain. Already, the vast majority of Bitcoin transactions (yes, even more than the SD flood!) occur within MtGox's system never touching the blockchain! The new payment protocol should help with some use cases as well. There are various possibilities for transparent trust-chain type transactions as well. But all these different improvements require time to develop, understand, and implement in clients. With the current situation of active developers, it will probably take years before Bitcoin can scale nearly as well as competitors. Bitcoin Foundation is helping improve this situation by paying at least Gavin to work on things full time. Real adoption among rational people (ie, not gamblers or druggies) also brings with it an equivalent percentage of potential open source volunteer developers to join in the efforts. SatoshiDice flooding the network does not. Anarchist nuts daring the government(s) to ban Bitcoin does not. These are counter-productive, and only harm the probability that Bitcoin will be able to achieve the adoption it needs to get to the point that it's truly viable. |
|
|
|
And yes, the 250Kb artificial constraint seemingly has had an immediate effect upon fees!
So, despite the block reward being >$1000, and not due for halving until 3.75 years time, fees are forced to do a moonshot.
Is there now to be an arm-wrestle between the bitcoin-happy public and dice gamblers as to who can tolerate the highest fees? It has been noted how thick-skinned gamblers are to fees. Will we see the whole network exist solely to support dice gamblers? Is that the future for Bitcoin? How's your graph look if you filter out SD flooding? |
|
|
|
BTC Guild started setting up a new server this morning running modified block rules. Currently trying out a 500,000 byte maxblocksize. The problem is with larger blocks, you increase the chance of orphans since it will take at least twice as long to propagate, if not more. I've modified the fee settings to prefer fee based transactions when increasing the block size past 50 KB, so hopefully the increase in fees per block offset the orphan rate increase.
I'm actually hopeful that you won't notice much difference in propagation times. We're talking about 500kb data structures here. Any mining pool worth its salt is running out of decent colo facilities in the USA or Europe with good connectivity. Transmission time is negligible at current sizes. The slow part is validation and disk IO. However Bitcoin 0.8 has two features that should make acceptance of a new block fast: 1) The signature cache means that when you see a transaction appear in a block, you are very likely to have already checked its signatures when it was previously broadcast through the memory pool (your node is "warm"), so there's little or no ECDSA computations required. 2) LevelDB means the difficult parts of managing the disk is done on a separate thread. In theory you should need only a handful of disk IOPs to accept a new block because all the compaction is done on a separate core in the background. I think it should be quite feasible to accept and announce a new block in something like 30-40 msec. So I'll be very interested to see if practice matches theory - if it does then you should not see a 2x propagation time, certainly not more than 2x. And if you do then we just need to fix it  You're forgetting that every node needs to receive, then process (incl signature checks) each block before it even begins relaying it to its next peers. |
|
|
|
The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network.
Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement.
Would the latter two of those "messages" not represent a transfer of value, of which you just stated that Bitcoin is a system for? I presume (I haven't looked at exactly how Satoshi Dice works) that when you place a wager, the player is transferring value to Satoshi Dice. Then, if they win, Satoshi Dice is transferring value back. I see no transfer of value in the "You Lose" message as I would assume Satoshi Dice keeps the value, so I completely agree with you there, that would be a completely informational message. While there is a value attached to the latter two, it is primarily a message. Otherwise, a gamer would just transfer a deposit, play, and withdraw (as I notice your site does) - no message passing involved. For an easy analogy, this would be like WalMart charging your credit card for every item you pick up off the shelf, and refunding you if you put it back (actually worse, since SD uses 2 transactions for every action). Not even VISA/MC could handle that kind of abuse, and their system (being centralised) is far more efficient than Bitcoin. |
|
|
|
Personally, I see the miners who are refusing all transactions (so their blocks propagate faster, less chance of orphans), who are only mining for the reward, completely ignoring that the purpose of mining is to process transactions in the first place, as being a bigger problem than Satoshi Dice is.
As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business.
Look at the block explorer from time to time. I see plenty of found blocks that have 0 transactions in it, just the reward generation.
That is the big problem.
-- Smoov
I agree this is a point. I know mining is a (mostly) free marked. But this guys are basically hurting the bitcoin users. Wouldn't it be possible to thread this behavior as an attack on bitcoin, therefor not accepting this blocks, when there is a significant amount of transactions required? Something like: if unconfirmedtransaktions >= 1000kb and blocksize <= 150kb then reject block Of course at least 51% of all miners would have to agree to this, otherwise miners that agree would only hurt them self. It's not that simple. For example, it's pretty common for SD's flooding to fill more than 1000kb, so your rule would reject blocks from only the responsible miners. |
|
|
|
is there a simple patchfile available to exclude SD? $ git diff 5b98972..block_dice | wgetpaste Your paste can be seen here: http://codepad.org/7RQZIkhd |
|
|
|
As long as Satoshi Dice's transactions are following the rules, that's all that matters to me. I don't care what the purpose the transactions are for. Not my business. SatoshiDice does not follow the rules:The blockchain is a system for transferring value, of which the final total is specified in advance. Those are the terms of the social contract every Bitcoin holder has adopted understanding. Those are the terms every node has agreed to voluntarily participate in the network. Nodes and miners have not unanimously agreed to have their resources/time spent inefficently processing informational messages like "you lose", "you win", or even "I bet on <this> game with <this> much". This was never part of the agreement. Nor is the system supposed to hold up to flooding. If you go back to even the original paper by Satoshi, miners are expected to filter out flooding attacks like this. The proposed transaction fee solution works in most cases, but not SatoshiDice because they have social-engineered gamblers into covering the fees for them, and to make it worse the gamblers are willing to pay a higher fee than real users. If Bitcoin had achieved critical mass already, we might have been able to just say "too bad, deal with higher fees", but at this pre-adoption stage the response to that would almost certainly be "screw you, I'll stick with VISA". Yes, this is a problem because 50% of TXes would never confirm. No, filtering out flooding attacks responsibly improves confirmation time of transactions. |
|
|
|
Sorry if this was brought up elsewhere in the topic, but I used search and couldn't seem to find mention of it. Does anyone have a decent workaround for hanging stratum connections? Already a known bug: https://github.com/luke-jr/bfgminer/issues/177I was going to write a script that monitors the hashrate via the API and restarts it if needed, but I figured I'd check if there was a more elegant solution. Thanks! You can workaround the issue by adding the stratum URI as one pool, and the getwork URI as another and --no-stratum to prevent the getwork from trying to auto-upgrade. This way, the stratum one will just die like normal, and then BFGMiner will failover to the next pool (getwork). |
|
|
|
Bet at least most of those blocks were by pools neglecting their duty to filter out flooding attacks.
i have read some of the threads about SD generating tons of 'spam' tx and it seems clear that it is difficult to prevent this sort of flooding. are there any countermeasures planned for such flooding attacks? Bitcoin's design has miners serving the role of filters. For the majority of flooding attacks, the planned deterrant of transaction fees work pretty well: an attacker would need to waste a bit of their own money to successfully flood. Unfortunately, SD is the exception that has managed to make use of social engineering to get someone else to cover the expense of getting around the fees. Not only that, but because SD's enablers are gamblers, they are throwing their money away anyway so are willing to ignore fees higher than rational users of Bitcoin who just want to send money. Thankfully, detecting and blocking SD specifically is also fairly easy. |
|
|
|
|
Show Posts
