I am amazed at how few sites in the bitcoin community are not supporting the blackout today. I just visited most of the other pools and several bitcoin blog sites, and it seems only BitcoinPool is supporting the SOPA blackout. We would like to encourage other pools or bitcoin related sites to join us in doing so. We think it boils down to this: If they get the equipment in place and legislation passed then what will stop them from censoring port 8333 instead of port 53? A few thousand angry bitcoin users? BitcoinPool is not doing a complete blackout, but every page on the site will have a blackout overlay until you click on it. |
|
|
|
notme is exactly right; the change is backwards-compatible, pool users don't have to do anything. Pools and solo miners should upgrade, or they run a (very small) risk that they'll waste time hashing a block that can't be valid. The risk is very small because it requires that somebody mine a block containing a /P2SH/ transaction that is valid-under-the-old-rules, invalid-under-the-new. That won't happen by accident, somebody malicious will have to create such a transaction and then find a miner who is willing to put that non-standard transaction in their block (and is willing to create a block they know the network will reject). They would spend a lot of time (and therefore money) on an attack that would do nothing but slow down transaction confirmations a tiny bit and maybe trip up some random, unlucky mining pool or solo miner who didn't bother upgrading. Gory details if you're not already bored: Old miners and clients will ignore all /P2SH/ transactions; they won't relay them to other nodes and won't put them in blocks they mine, because they're non-standard. So an attacker can't broadcast an invalid /P2SH/ transaction and hope it gets included in a block; they'll have to mine a block themself, or partner with a big solo miner or pool who is willing to produce bad blocks. If an attacker DID manage to create a block with a timestamp after the switchover date and a bad /P2SH/ transaction in it, then some percentage of the network will try to build on that bad block. Lets say 70% of hashing power supports /P2SH/. That would mean only 70% of the network was working on a good block-chain, and the result would be transactions taking, on average, about 14 minutes to confirm instead of the usual 10 minutes. In other words: they'd give up a $300 block reward and manage to just give the network a tiny little hiccup. Thank you for the detailed explanation. Much appreciated. |
|
|
|
Yeah, scratch that. I meant 8 @ 1 BTC. |
|
|
|
|
I've been cross-referencing digbtc.com with blockchain.info to figure out what the "Unknown IP's" are.
|
|
|
|
All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.
So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.
I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.
In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.
Gavin, I beg of you, give users MORE time to adopt this change and think about the dates you choose. We have several users on our pool that are either travelling or are away from their PC's for extended periods of time, and if this is going to require everyone to update then getting all the pool admins on board so they can then warn/inform their user's about the change is critical. Nobody sent me or Geebus a memo, I just happen to find it, and this is true for A LOT of user's on this forum and other forums. Waiting until the day when it just stops working to only find out that a critical change was made a week ago and that's why we were unable to mint new coins is frustrating to everyone involved. I think as a core developer, you should be in touch with or have a list of all the pool admins contact info in order to notify them of these types of changes, then they can send the word out to their users however they see fit. We (@BitcoinPool) would gladly put the news of this on the front page and e-mail all our users about the change. One post on one forum on the Internet and hoping/expecting everyone to read it just doesn't seem to be a good way to spread the word. Other than that, keep up the good work. |
|
|
|
Has anyone even looked at the details for solved blocks after the change? Users are being scammed big time. For instance, for block #144456 a total of 438 users had their reward halved, and only 9 got the full reward. 16 BTC went to the donations user (the pool).
That's a new and now known bug that we're working on fixing it asap. I kinda freaked out when I woke up this morning and saw everyone was affected. I'll post back here when it's fixed. It's funny how most people on this forum immediately freak out and think the worst possible thing (scammer, snake-oil, thief, hackers, etc, etc) has happened when it's just a software bug... jeez. Saying it's a 'scam' when it's very obvious that something went wrong seems premature. Anyone that has half a brain and can stop and think for a minute or two, it's become very obvious that something went wrong. Rhetorical question: Why would we run a 'scam' then make it that obvious by falsely showing everyone is a pool-hopper? We would not do that as it would be a completely stupid scam, blatantly obvious, and would have hundreds of previous solved blocks to backup such a ridiculous claim. But I'll let people think for themselves while taking a look at all our previous solved blocks. Do any other pools show ALL their solved block information?? If not, and we go by Grinders knee-jerk logic, then I guess they could all be scamming their users and are hiding the evidence. But of course, that type of logic is unfounded and we would never say that. It's reason's like this that we include the most information possible in our solved block history....to keep the level of trust in us higher than the other pools and the users of our pool honest. Further more, the level of transparency we offer has been very helpful in the past when we tracked down a user who was cheating other miners. We had one of our users point out to us that another user had an efficiency of over 380%...which should never happen (another reason efficiency matters  ). We did a bit of digging, and found out there was a evil Tor exit node that was stealing getwork request and share submissions of miners who were/are using Tor. Because of our detailed block solve history, we were able to see that this person had been doing this for at least a week before anyone caught it. We rightfully banned that user and blocked their IP addresses. So now I have to wonder, which other pools are being targeted by this Tor exit node?? I guess we'll never know because no other pool offers this level of transparency and detail for their solved block history. Just one more reason for users to trust our pool before believing a unfounded and slanderous claim like "Users are being scammed big time" from someone who obviously doesn't understand how having a open, transparent, and highly detailed solved block history keeps everyone honest. |
|
|
|
Not true. First major flaw with your logic is NOBODY knows how long the round is going to take, hence you don't know when 23% of the round is. Secondly, we totally mess with the stats to trick pool hopping software. The only people this affects is pool-hoppers, which we are more than happy to discourage from even trying to use our pool. As stated on the front news page. After much consideration and review of how our anti-pool hopping system is looked upon by members of the Bitcoin community, we have chosen to change the way in which it is working.
In the Past:
If a user participated in less than 50% of the round, their shares would be reduced by 10%, unless a donation was set, in which case, no penalty was applied.
This allowed for our users with legitimate disconnects, or reasons for being unable to mine during long rounds to avoid being hit with a penalty.
Some people seem to belive that this is a negative aspect of the anti-hopping system due to the easily cheatable nature of the system and the fact that pool hoppers are still given a large incentive to exploit our pool.
From Now on:
If a user participates in less than 50% of the round, their shares will be reduced by 50%, regardless of donation. 50% of the penalty fee will be directed toward the donations account and will be applied to server costs and future monthly contests. The other 50% of the penalty will be removed from the total shares for the round, which will in-hand cause the value of all remaining shares in the round to increase.
Example -
100,000 shares are in the round.
User A has 5000 shares and is NOT a hopper. Their estimated earnings before penalties are applied is 2.5 BTC.
User B has 5000 shares and IS A hopper. Their estimated earnings before penalties are applied is 2.5 BTC.
Once penalties are applied, User B's shares are reduced to 2500 where 1250 has been credited to donations and 1250 has been removed from the round. After the penalty is applied, User B's unconfirmed earnings are 1.265 BTC and User A's unconfirmed earnings are 2.5316 BTC.
At this time, any donation currently set on your account will remain in place. Donations will be processed prior to any penalties. As a reminder, donations are entirely voluntary and are not required to use this pool.
We will use this new method of calculating penalties for a one week trial period, at which time we will decide whether or not it is effectively deterring pool hopping and effectively rewarding loyal members of the pool.
Regards,
BitcoinPool Staff So 25% of the a pool hoppers shares goes to us, 25% is take from the total shares of the round (which causes other non-pool hoppers to get more), and the pool-hopper only gets 50% of what he/she would have gotten had then not been a pool hopper. We're feeling this out to see how it works. This new method gives MORE back to our users and less for us; and as for what we keep it ends up going back to the users anyhow... Once again we will be doing a random drawing for our monthly give away, and this month we'll be giving away up to TEN SAPPHIRE Radeon HD 6870 (1GB, 256-bit GDDR5 PCI Express 2.1 x16) cards.  (We had a few extra Ron Paul 2012 stickers laying around that we're going to throw in too  We haven't been able to offer monthly contests for the past two months due to various reasons, but we want to make it up to everyone by offering a bigger and better contest for this month! If pool speed averages 100 - 199 Gh/s for the month, we'll be giving away one Radeon HD 6870. If pool speed averages 200 - 299 Gh/s for the month, we'll be giving away two Radeon HD 6870s... ...all the way up to 1000 - 1099 Gh/s where TEN LUCKY USERS will each win a Radeon HD 6870! As always, more info in the forum post here and the rules here. Contest ends September 30, 2011. So get out there, spread the word, and keep mining! - BitcoinPool Staff The bitcoins that we do end up getting as a result of pool hoppers being penalized ends up going towards monthly giveaway, as in the $1,750 (which is about equal to 2 months of donations AND penalized pool-hoppers) I just spent last week for the 10 video cards that we are giving away for this month's Give-Away contest. Everyone seems to think that Geebus and I make a living off the pool like DeepBit or Slush's pool, BUT WE DON'T!! Geebus and I both have regular jobs like most people, and we run this pool on the side. If we depended on the pool for our living, we'd both be without a home by now. There is nothing stopping people from mining on our pool with a 0% donation set. As long as you are not pool hopping, you don't get penalized. It's that simple. This way of doing it is much more fair to the loyal miners on our pool. The only people that seem to have a problem with this is ..... pool-hoppers! It's fairly obvious who is a pool hopper and who isn't, because only pool hoppers complain about this. Lots of our loyal miners have already expressed that they like this as it rewards them for sticking around. So feel free to complain all you want, but you'll just be outing yourself as a greedy pool-hopper. As for all the non-pool hopping miners out there, if you want to be qualified to win a 6870 this month, you know where to come now. |
|
|
|
Edit: looks like you still have to have knowledge of both messages to generate a collision.
I think you actually have to be able to control both messages to generate a collision - that's actually the definition of one. In order to be able to generate a second message that gives the same hash as an existing message you need a preimage attack, and I don't think those are practical against MD5 yet. I think both of you have gotten a bit off topic here and missed one of the finer points. Collisions don't matter here since Tradehill will lock your account if you try to login too many times. |
|
|
|
I'd like to see the site log you out after x amount of time of inactivity.
I've rebooted my system several times and have yet to be prompted for a new password when I go to the site.
We've received feedback from users that love not being logged out and more that would prefer the additional security. We've evaluated the situation and decided to implement logout due to inactivity. Security trumps laziness  We're coding it in as I write this and it should be live today after extensive testing. Good man! |
|
|
|
As many of our user's have noticed service has been less than good the last few days. This was caused by a DDoS attack. We have managed to get control of the situation by notifying hosting providers and blocked several thousand IP addresses in several dozen class C networks. The main Russian ISP that the attacks were coming from is Yandex LLC. When we blocked the attackers IP address or an entire class C network, within minutes the attacker would be using a different address in a completely different class C network. After doing this song and dance for several hours, we realized that it was mostly coming from Yandex and sent off an e-mail to their abuse address. We haven't received a response from them, so we took drastic action and blocked every IP address owned by Yandex. After blocking Yandex, everything seems to have returned to normal. If you are a user in our pool coming from this network, please PM me your IP address and I will white-list it. We'd like to apologize to our users for the inconvenience of this attack. We're keeping a close eye on logs and traffic analyzers to monitor for any new attacks so we can block them before they disrupt the pool any further. Thank you for your understanding and tolerance for the situation, we appreciate it. Best Regards |
|
|
|
|
Our e-mail service provider thought we were spamming when we sent out several thousand e-mail addresses notifying users that their miners were idle. This has resulted in every e-mail being filtered. We're talking with our hosting provider right now to get them to unban our server and allow the e-mails to continue.
|
|
|
|
they wont let me sign in. Ideas?
Read the news, the news that is everywhere right now. Read their front page, which explains it. |
|
|
|
|
I think this post was long overdue. People have been reporting for over a week now that they've been getting hacked on MtGox, and then this happened. Every account, every e-mail, every (hashed) password. What's sad is that it's taken this long to post about it. Lots of people have been reporting this and it seems to fall on deaf ears. They have a whole thread about MtGox accounts that got hacked, yet no word was said to try and calm users or ease concerns.
Sorry to be so hard on you guys, don't get me wrong I love(d) the service, but you NEED to talk with users and tell them what's going on when they report getting hacked, and that needs to happen ASAP...not a week later. I hope your actions or lack thereof don't affect your business when it re-opens....cause I have/had(not sure, can't login) bitcoins with you guys and was looking forward to the value working it's way back up to 20.
HOPEFULLY people will trust you guys after this. A come back from this level of hack is hard, but I wish you guys the best.
|
|
|
|
Jacob is a drama queen that loves the attention and people talking about him. He hasn't provided shit for code to any project or group he's been associated with (which is why WikiLeaks booted his ass). This guys just talks out his ass and doesn't really know shit about shit unless he steals it from someone else's research. Jacob is a hack, not a hacker. "Do you know who I am?! I'M JACOB FUCKING APPELBAUM!!" - Jacob, BlackHat Vegas '09. |
|
|
|
|
Why do some pools get the pleasure of being pinned to the top of this thread and others don't?
|
|
|
|
I don't like that you have the mask on, creepy, im out.
REALLY? Im sending my 5Gh/sec because of the mask Awesome. Thanks. |
|
|
|
The network only enforces a maturation time of 100 blocks. The extra 20 blocks is a client limit only. How does a block go "orphaned" after it's been "confirmed" (meaning, it reached 120 blocks then went "orphaned" shortly after that)? 100 blocks to mature eh? Everywhere I've read says it's 120. Has it always been that way? Do you have a reference I could refer to for more reading up on this? A bug, probably. Or maybe you were segmented for a really long time.
We weren't segmented. Things have been really stable since we update the hardware infrastructure. Thank you for the answers and your time. |
|
|
|
Start here: http://blockexplorer.com/b/129803Follow the address it was paid to: 1LdrTWcXu5qYvEggB6PodEs2proXrQMNLs I'm going to copy and paste this, so sorry if the formatting is off. Transaction? Block? 5a91af17b3... Block 129803 (2011-06-10 11:12:25) 21a9a054a0... Block 129907 (2011-06-10 23:32:50) How did a block get confirmed after just 104 blocks? Shouldn't this be 120 blocks like the blocks before and after it? Now to make this even more strange/frustrating, our pool (bitcoinpool) had a block ( 129806 ) go orphaned *after* we paid out on it 120 blocks later. Our code explicitly checks to make sure the block is valid AND confirmed before we pay out, and it was paid out BEFORE it went orphaned. Then about 2 blocks after it was confirmed, it changed to Orphaned. Here's a dump from our 'listgenerated' from bitcoind. [ { "account" : "", "category" : "generate", "amount" : 50.04000000, "confirmations" : 239, "block_hash" : "00000000000012fbcf784971681c91eac50040480aa1525f8548d1ac6d4a06bd", "block_index" : 0, "txid" : "a445379234a83536814f8196388b295792696b79dcf8920aafd3664edf220df8", "time" : 1307676121 }, { "account" : "", "category" : "orphan", "amount" : 50.11351319, "confirmations" : 0, <-- Should be 140 "txid" : "7db5b5e710fcad4957cc1d498bf008bea27b8ded618a9f74eab9f91c9799f505", "time" : 1307705806 }, { "account" : "", "category" : "immature", "amount" : 50.12306040, "confirmations" : 72, "block_hash" : "0000000000000d5d50045d8e321b7d97f988f497b80fb1fa4ca98e9725bcdab3", "block_index" : 0, "txid" : "a53a442e87a53cd06e6298b055da89b7b59716ccfa23aba29c47ff22365bc84e", "time" : 1307733695 }, { "account" : "", "category" : "immature", "amount" : 50.26881957, "confirmations" : 36, "block_hash" : "0000000000000d74bcd54e04d45e2750af8e3700e2b6f9daa42f1a6498d331db", "block_index" : 0, "txid" : "f9ffe4f638a3c08523357351088bc8d5d260000c76305db4c4ccefa6fb09add8", "time" : 1307750373 } ] The TX ID: 7db5b5e710fcad4957cc1d498bf008bea27b8ded618a9f74eab9f91c9799f505 doesn't exist in block explorer. So here's the questions I'd appreciate an answer to are:
1) How does a block get "confirmed" after only 104 blocks?
2) How does a block go "orphaned" after it's been "confirmed" (meaning, it reached 120 blocks then went "orphaned" shortly after that)?
3) Are these signs that something strange is happening in the block chain, and if so, could it be someone else doing this on purpose?
Thank you in advance for any good explanation. |
|
|
|
Cool are you guys part of Anonymous !!! If so great work!
Being that Bitcoin is a currency that protects your identity, I thought it would be an appropriate mask to use. |
|
|
|
|
Show Posts
