Taking irreversible actions on unconfirmed transactions is not safe. This is not news.  Big hashpower consolidations are not safe. This is not news.

While I'm sympathetic about losses and don't support theft— it appears that many Bitcoin gambling services are run from places where their legality is probably questionable, and as a result getting help from the courts may not be an option— and even if it is, it's very expensive and takes a long time. Your best bet is to protect yourself by not transacting in a way which is insecure relative to the network that exists today.

The operators of high transaction inefficient gambling services (the ones with two transactions per tiny bet) have many times responded to the Bitcoin community members concerned about their services abusing our common network resources and costing money node operators saying that we should all be thankful for the valuable "test" they are performing and the encouragement it provides to improve the infrastructure. Some parallels could be drawn from people exploiting insecure unconfirmed transaction behavior …

Proof of stake has thus far proven unworkable.

The main problem with Proof of Stake appears to be that is that there is nothing at stake:  In PoW systems you burn energy to mine, and that mining is only worth while if the chain your mining on survives long term, so you are generally incentive mine the chain most likely to survive. In PoS the rational strategy is to mine all possible forks constantly, because doing so costs you nothing.

Last I checked the, headline, best known PoS altcoin has controlled centralized signatures being announced to lock in every block.  I think it would be awesome if PoS could be shown workable, and there was a time when I was very excited and hopeful about it... but its beginning to seem unsalvageable. You can keep pumping the idea until your ignore throbby burns the color of the sun, but that doesn't solve things.

Not so, it just means that the security is outsourced.  E.g. your security depends on python randrange doing the right thing. Look how well that worked out for that PHP bitcoin shopping cart interface package.

Electrum provides a whole wallet, and an easily memorable, strongly generated, 128 bit key which also has strengthening to help preserve security even if someone shoulder surfs the key.  Electrum has an enormous number of users.

It's run by "Joric". As was the similar wallettools.appspot stuff which predated it in the role of helping fools and their Bitcoin split ways.

I have some pretty fun IRC logs surrounding the creation of Brainwallet.org... e.g. Joric searching for guessable sha256 keys and redeeming them.

He was really resistant to using a strong KDF. Not because he's malicious, as far as I can tell, but simply because anything worthwhile is going to be slow in javascript.

As they are usually implemented today pools create a substantial amount of centralization which violates Bitcoin's security assumptions. Today the unequivocal answer to your question is yes.

Even when a pool does not have "$pick_your_threshold" the problem still exists— E.g. a pool with 40% hashpower would still have a quite high success rate reversing two-confirm transactions (and will still be successful reversing 6-confirms half the time), or two 30% pools being compromised gives you a majority.  "Our security assumption is that _two_ computers won't get hacked, or _two_ operators won't be coerced" doesn't sound all that good (Also works for any small integer instead of "two").

It's possible to construct pools that don't create this problem in a number of ways— P2Pool is one example, though it's not the only way to do it— there are other ways that are compatible with doing PPS pooling, for example.  Though any way of fully removing the centralization pools bring requires miners to participate in and validate the Bitcoin network... and we've gone pretty far down the path of people with $100k in mining asics powering them from a rasberry pi, so turning that back might be hard even if people did suddenly start paying attention to the centralization pooling is creating.

There are also ways to go about pooling which may reduce the harm of the centralization somewhat without the full cost of having miners participate in the Bitcoin network. E.g. miner software that is skeptical about they work its issued and won't participate in certain kinds of bad behavior that can be detected without full validation.

On the subject of Bitcoin fairly few academics have bothered to communicate with the experts in "industry" (e.g. core devs, folks here posting with books-badges, etc). It's a shame: the failure has resulted in a lot of really confused papers which could have been very easily improve a lot with some expert pointers.

But there are a lot of broken things out there— e.g. no ethical review on experimentation, etc. (I loved one paper I saw that said something like there was no ethical concerns with their live fire privacy attacks on the unwitting public "because anyone else could have performed the same attacks").

Really the network has only done about 73.6 bits of work so far, our lowest is lucky.

Most modern hardware works absolutely fine with it, your data is outdated. I have multiple avalons on it and am slightly ahead of expectation. Were it not so it wouldn't have 28TH/s right now— significantly more hashrate than the whole network had at the beginning of the year, with an expected two blocks per day.

But indeed, it's a smaller pool and has its own setup costs (including the cost of cutting through misinformation like the claim that it doesn't work well with most modern hardware... which is why I'm posting about _other_ things you can do.

I wish it were so, but people have odd pool preferences... and there are bunch of people who run a local bitcoind/bitcoin-qt as a wallet. But want to stay on some pool
Perhaps, but small pools are a different tradeoff, and the authors of the paper argue that it works for any size (Eh. no comment on the merit of that claims). Really the only cure for misbehaving is to control your own mining (e.g. with P2Pool) but local announcement is nice. BFGMiner will also detect pools trying to mine forks on themselves and prevents that. In any case, people have diverse preferences and I thought it was important that there were things you could do to improve the situation without going all the way to P2Pool.

Just having a bitcoind running and having solo mining setup as a fallback would be good for the network's security, since DOS attacking pools would have less effect and if several started misbehaving you'd be ready to switch.

You've drifted offtopic. All posts in a thread should be strictly related to the original post. I asked you to explain and you have commenced with adhomenim.

So you've seen the much hyped "Selfish miner" attack paper, and like a good Bitcoiner you're not falling for the hype...  But, maybe it has you a little concerned... after all, we've got massive hashpower consolidation and the risk that mining becomes more consolidated in the future is a real risk, though a distant and general one, which concerns most of the Bitcoin technical experts even if the paper isn't all the media hypes it to be. You think Bitcoin is an independent good regardless of your short term income and you don't want a pool you're using engaging in secret strategic mining that ultimately harms Bitcoin.

Ideally, for the long term health of Bitcoin, you should be on a more decentralized pool like P2Pool (or solo mining) but perhaps that is too big of a change for you today, or you prefer a PPS or quasi-PPS pool.

Fortunately, you can make it much harder for a getblocktemplate supporting pool to participate in block-delaying without your knoweldge and consent:

All you have to do is configure BFGMiner for failover to solo-mining like:

This will make your miner also submit any blocks you find to your local bitcoin node, which will undermine any attempt to delay the announcement. It should also help your pool get a lower orphan rate, since it'll start the exponential spread of the block one round-trip-time earlier.

I am an organization now? Awesome. Do I get to have a charter?

What does this have to do with Luke's comment?

Huh?

what part of my post indicated that I was "worked up"?

None of our parameters are from a seed. Thats how the NIST *r curves are constructed. Our parameters are completely explicable based on performance considerations, unlike the NIST ones, and meet DJB's fully rigid definition (our generator point is random, as are DJBs , but if one generator is weak all are weak).

Here is code the reproduces our parameters from performance and security principles: https://bitcointalk.org/index.php?topic=289795.msg3214237#msg3214237

piotr_n  you were part of the thread where we reproduced our curve parameters, were you not?

No. Timestamps don't come into this at all. (And most suggestions to tighten timestamps result in (usually minor) vulnerabilities)

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972

In [592]: math.log((2**256)/0x000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050,2)
Out[592]: 78.65083195521588

Right. It doesn't have an 18 billion diff, but the hash value is low enough to be accepted by such a one.

It also isn't the lowest block hash yet.

2013-10-27 14:55:42 SetBestChain: new best=000000000000000000028c32e6952731326747bae4be8db0f832d6eea0362050  height=266381  log2_work=73.237967  tx=26093998  date=2013-10-27 14:49:44 progress=0.999972
 
Is vastly lower, and would be accepted by a difficulty of ~110,484,089,548,580.

Bitcoin has now done ~2^74 hash operations. I'm reasonably confident that it will do 2^90 of them in my lifetime, I am not confident that it will be the only 2^90 search.

Also the workfactor to break one of your 90 bit keys is less than 2^90 the moment two of your keys have been used... If your scheme were widely used, it would be much easier to find one at random. It may also turn out that your RNG is less uniform than believed and after careful analysis doesn't require a 2^90 search to match even a single key.

Your scheme also only generates a single address, so users are stuck reusing it, compromising their privacy.

In general symmetric cryptography applications 128 bits has arisen as a general standard. Is 128 meaningfully better than 90?  Is it meaningfully better than 120? Meaningfully better than 65?  Part of the purpose of having a standard size is so that you don't have to constantly engage in a complicated tradeoff discussion: you just demand that everything is 128 bits.

Is 128 bits more to memorize than 90? Yes. But relying on memorizing keys which can never be recovered via any other means is already skating on thin ice. People are used to it being possible to recover access if you forget— though sometimes with great effort. Crypto is different. Memory is just reliable enough for its unreliability to be surprising, especially since you don't remember all that you've forgotten by definition.

Of course, once you're up to that size you could just use the scheme electrum uses (or the one that it will use). Of course, the implementation isn't 1024 bytes— but neither is yours: The dictionary is an utterly essential part of the implementation.