No, that's not true. Mining at the beginning of a round is better no matter what. It's better because if you find a block before anyone else submits a share, you get the same reward as if you were solo mining and if a block is found shortly after you submit a share, you get a non-zero payout. Thus mining at the very beginning of a round is better than solo mining and clearly it cannot always be better than solo mining.

All you must do to show that a pool is vulnerable to hopping is show that there is some point that an attacker can identify at which the expected return exceeds the expected return for solo mining. If I understand this payout method correctly, it has such a point -- before the first share is submitted in a round.

That's all true, but has nothing to do with anything. Sure, there are lots of ways one could hop pools that don't work. The question is whether there are any ways that do.

I agree. That's why the pool is vulnerable to hopping. There are good times to mine and worse times to mine. (Assuming I correctly understand how the pool pays out, which I hope I don't, since this is really an obvious flaw.)

Maybe I'm missing something, but it seems that this payout strategy is obviously vulnerable to hopping.

If there's any time a miner can identify where he gets a higher payout than he would get solo mining, the pool is vulnerable to hopping. Obviously, the payouts can't always be better than solo mining. So if it's sometimes better, it must also sometimes be worse. If a miner can tell when it's better, he can mine only when it's better.

Say it's the very beginning of the round. If I mine a block before anyone else submits a share, I get the whole 25 BTC. So the payout at the very beginning of a round is as good as solo mining. And if I don't mine a block and someone else does very shortly after me, I get a non-zero payout. Thus mining at the beginning of a round is better than solo mining.

I must be missing something because this is pretty obvious.

No. What would make Bitcoin's implementation useless would be if someone could produce a private key whose public key hashes to a given address. There are many compromises less than that which would not threaten Bitcoin at all. For example, if an attacker could produce two private keys that both yield the same address, that would be a collision, but it wouldn't provide him any useful attack.

I suspect the reason Satoshi decided to use both SHA256 and RIPEMD-160 is that he feared that he could not be absolutely certain there might not be some weakness from the way ECDSA and RIPEMD-160 might interact that might permit a collision exploit, but the idea that there could be some exploitable interaction in ECDSA->SHA256->MD160 seemed rather absurd.

Mostly for fun, I put together a 13 GH/s mining setup two weeks ago.

I started mining with Ozcoin and mined block 242128. Sadly, being in a pool, I just got a normal share.
https://ozcoin.net/content/block-history-bitcoin

Then I switched to Eclipse and a few hours ago, I mined block 243360. Again, being in a pool, I just got a normal share.
https://eclipsemc.com/block_stats.php

Now, I have some philosophical questions: If I had been solo mining, would I have still mined these two blocks? Did choosing to mine in a pool cost me $5K? Am I clearly a lucky miner and should begin solo mining immediately? Should I buy a lottery ticket? Or did I use up my luck and need to stay in pools forever? Should I look both ways twice before crossing streets?

Could someone who understands the nature of luck please help me with these confounding questions?

Using the "full range" doesn't ensure there won't be collisions. The whole point of using 160-bit addresses was to keep them as short as possible while still meeting the security requirements. Increasing the expected time to the first collision from a hundred billion centuries to a trillion centuries isn't worth having all Bitcoin addresses be 80% longer.

The RPi will not work reliably with hubs that try to draw 500mA from their host. The RPi will not work reliably with cascaded hubs. Unfortunately, this rules out a lot of 7 to 10 port USB hubs. Also note that a 10-port hub with a 4A power supply will probably run no more than 8 erupters reliably under any conditions.

He could mean anything. But at best, he means that he believes early investors are profiting only from the investments of later investors and that there is no realistic prospect for any actual value to be produced and thus, on net, investors must necessarily lose money.

Mt. Gox customer service is correct, they don't hold the funds. He's just doing a poor job of explaining the issue. The OP erroneously told SatoshiDice to send funds to some random guy's Mt. Gox account and now he wants Mt. Gox to get him back the funds. Mt. Gox can't do that because Mt. Gox is a hard money system. Their customer service is doing a poor job of explaining that Bitcoin transfers are irreversible and if you send funds to someone, even if by mistake, you cannot get them back.

Looking at a few other images of what appear to be similar devices made by the same people (or at least the same methods), the assembly quality appears shockingly poor.



In this picture (taken from an auction), we can see bits of solder that have splattered on the capacitor due to inexcusably careless assembly practices and a complete lack of post-assembly inspection or standards. These could fall off and short out whatever they happen to land on and they are likely hiding thermal damage caused by their contact with the plastic sheath while molten. The soldering quality is extremely poor and gaps and stragglers are visible. The long parallel leads of the capacitor have been left bare, they can easily make contact with each other either directly or through anything that happens to come in contact with them. The yellow wire's insulator appears to have been torn or bitten and there are visible burn marks. The solder joint is doubling as the mechanical connection with no heat shrink tubing. Yikes!

As for your picture, I think the two bare leads shorted out, causing the yellow wire to overheat. The burn marks on the capacitor likely came from the insulation fire, not from the capacitor itself failing. If you look closely, I suspect you'll see the capacitor was just burnt a bit from the outside. It's hard to be sure though -- that would just be my guess. You were just a victim of the lack of insulation and generally abysmal assembly quality.

That is true for algorithms they can put backdoors in (where it's obvious to everyone that it's possible the NSA could have done so because the constants are "magic"). But it is not true for public algorithms (like SHA256, RSA, and so on) where the constants have known derivations. If the NSA can break it, they know that other intelligence agencies can too, and they can't get the public to change algorithms often. US companies have the most valuable intelligence. Such a strategy would be most unwise.

Update: And what oakpacific said below me.

Not a lot of people buy marijuana tax stamps. You can either regulate something or you can ban it, but you can't do both. Banning something means giving up the ability to regulate it, and that's an awfully high price to pay. People who are breaking the law anyway won't care if they're laundering drug money or financing terrorism, and they won't go the cops if they suspect people they're dealing with are doing bad things.

Two questions:

1) Does it have a fan inside it?

2) Does it have anything else inside it?

I asked you to post a link or two. You didn't post any links. I still might search for it to see. But you have to remember, I asked for those links while I still thought you were asking honest questions and open to reason. There's very little point in engaging with you know that I know you aren't.

You can't reason a person out of a position they didn't reason themselves into, I guess. As for "drinking the kool-aid", I'm not the one saying things like "Imo the hype of Ripple is due to clever marketing and awarding social media sites with free xpr and for the sake of humanity I hope Opencoin and Ripple die a quick death." That sounds like the kind of thing a person who had drunk the kool-aid would say to me.

I'm the first person Jed McCaleb hired to explore whether the double spend problem could be solved by consensus rather than proof of work. I'm also OpenCoin's Chief Cryptographer. My signature mentions that I'm an employee.

Yes. Part of my job is to explain Ripple to the Bitcoin community.

I honestly can't comprehend the logic behind this. If you think my arguments are weak, they should be easy to respond to, you can put in even less effort than you think I did.

I addressed those in the other thread where you posted them: https://bitcointalk.org/index.php?topic=142261.msg2399066#msg2399066

I wish I had seen this before I took your other post seriously.

As he mentions, we're already adding a way to control this. If that's his only complaint, then he'll have none when this is changed. (You will be able to set an option on a pathway. When that option is set, funds can only flow out from your account along that path if it's the source of a transaction, if the input pathway to you had a negative balance, or if you placed an offer.)

He just doesn't get Ripple and he doesn't look interested in understanding it either. His core argument is that Ripple is bad because it allows people to do bad things. I reject that argument fundamentally. The right question is whether Ripple makes it possible for people to do good things without forcing them to do bad things.

Can you post a link or two? I'd like to see what you're referring to.

Do you still beat your wife?

It wouldn't shut the mouths of any critics, they'd just move on to some other argument that they don't actually believe.

It is simple to do it right, but it's also simple to do it wrong. Making it harder to do things wrong without making it more difficult to do things right is the challenge. It's harder to hit a nail with a hammer than to hit your thumb -- your thumb is a bigger target. But that doesn't mean there's something wrong with hammers.

I am personally committed to ensuring this happens by the end of the year at the very latest and, I hope, around September. We have been focusing on outside audits of the source code, increasing the number of, and geographic distribution of, organizations that run validators to gather more real-world data on the behavior of the code, testing the logic that controls changes to the transaction processing rules, and so on.

Bitcoin makes a lot of design sacrifices to enable it to operate as a distributed system with no central authorities. Whenever anyone suggests making a centralized system based on Bitcoin, everyone rightly points out that you have to accept all those sacrifices and in exchange get no benefits. That's just bad engineering. Ripple similarly makes lots of design sacrifices to enable it to operate as a distributed system with no central authorities. Not running it that way, you gain absolutely nothing in exchange for those design sacrifices (other than to validate the design).