I can't comment on the KnC I know there have been an assortment of firmware issues there, but a significant fraction of the total p2pool hashrate is asicminer blades. The asicminer blades are getwork only and violate the getwork protocol by always returning diff 1 shares no matter what you ask for, this doesn't goof up most centralized pools since they only return diff1 getwork.  On p2pool you can tell p2pool to fix the pseudoshare diff to 1 (add +1 to the miner username) or you can run the asicminer blades through a proxy (e.g. bfgminer) that actually fixes the protocol.

[Also: you dweebs have totally taken this thread off-topic, shame on you.  I posted about some decenteralization improvements that you can do _other_ than P2pool and you flood it with complaints about P2pool]

If you want to encourage P2Pool use you can make it in more people's interest by making bursty donations to the recent p2pool miners: https://en.bitcoin.it/wiki/P2Pool#Donating_to_P2Pool_miners  (Of course if you do this, you should publicize it in order to have an effect.)  Many miners don't fully understand the issues, prize money is one way to get their attention. Switching to P2Pool also has a cost, and some tips can help bridge that gap.

(Disclosure: I mine on p2pool, but I'm under 1% of its hashrate now. Regardless, any funds I get via these sorts of payments to my p2pool addresses I'll just recycle back into other pro-decentralization uses)

Fungability. Do you speak it??

AWS nodes, especially smaller ones have horrific IO that is slower than a 4200 rpm laptop drive.  You may be better off looking for other options.

Reducing the blockchain storage will not change the ongoing IO load which you seem to be expressing problems with.  At least from what you're telling me here the size is actually not a problem for you. Am I misunderstanding?

Can you explain better what limitations you're facing. In other words, "Please explain the problem you're having / trying to solve, and not what you think the solution is".

The current blockchain size is a fraction of a modern commercial _game_ and it stores the whole bitcoin economy. Better understanding the nature and origins of your limitations you're facing avoids thinking we have a solution for you which isn't a solution.

Please also be sure to explain what you expect to do with a node. For example, if you need to be able to add new keys at will and go find their transactions ... there is no way thats going to happen with reduced storage.

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