My willingness to help Elephant should definitely not be construed as any kind of official endorsement; I am generally happy to help just about any projects building on Ethereum.

So just to clarify, I looked at Pokereum's whitepaper a bit and provided a few comments; I'm not any kind of official advisor. But will be interesting to see this progress.

Thanks for the update, Charles, and thanks for all your contributions to Bitcoin education. Looking forward to seeing what you do next.

It's quite well under development now; a couple of hardware people we're talking to are saying good things about our general approach, and the main thing it's missing is a really rigorous professional review, which we'll obviously be able to much more easily attract post-sale. If we are not satisfied, we can always use SHA3 as a fallback.

In the long term, I don't think botnets are an issue; they may prove an inconvenience to certain specific individuals, but it's very hard to see how one can get over 50% assuming a sufficiently strong network. In general, the reason why botnets are scary is that botnet activity tends to be directed toward anti-DDoS tasks, where the limiting variable is how many pings the network can do against a particular site or the number of IP addresses; because of this, only the number of nodes is relevant. In mining, however, it's not just the number that counts, it's also the hardware strength. With this in mind, note that the average "legitimate" miner has several advantages over the average botnet computer:

1. A botnet computer tends get infected at least partially because it runs older and insecure OSes, eg. Windows XP, implying the computer is old and therefore weaker
2. Miners are predominantly run by technically skilled people, whereas botnet computers are owned by technically unskilled people, once again implying that botnet computers are going to be weaker in raw CPU power than average
3. Miners don't care if their mining takes up 100% CPU power, whereas botnet computers will need to cap to a fairly low percentage to avoid getting caught
4. (3) will eventually include during the night, because antivirus software will adapt to detect high CPU usage as a warning sign

Now, in the short term, it's a somewhat different question, since antiviruses have not fully adapted to the existence of malicious miners and the network is also fairly weak in the big scale so 1000000 * 0.1 can still overwhelm it. However, in the short term it's not really avoidable; even if we make it ASIC-friendly no matter what algo we use it will take a while for it to get ASIC'd (and if we use SHA256 then we make ourselves vulnerable to Bitcoin mining pools and if we use Scrypt then we make ourselves vulnerable to that one guy in China who is producing 50% of Litecoin hashpower), so I would submit that it's an empirical question to what degree botnets at that stage are a problem. Existing history seems to suggest that while botnets can earn a moderate amount of income there aren't too many examples of them trying 51% attacks.

Finally, if it is deemed a problem, there is a chance our algo will be GPUable in any case (it may be a necessary sacrifice to accomplish very high levels of ASIC resistance), in which case bots would not be a problem at all.

One problem I have started to think about a lot about PoS in general is long-range attacks: what if you try to 51% attack a PoS blockchain straight from (or very close to) the genesis block?

To explain this, consider the following. First, suppose that 90% of all coin owners suddenly disappear. Will it be possible at all to generate any more blocks? Suppose yes. Then, an attacker with 10% stake will be able to fork the blockchain at some point 3 years ago, and then let it develop inside a virtual server. After generating a few million cost-free blocks, the attacker now publishes this new chain. How does a new node differentiate between the legitimate chain and the offending fork?

The second problem is long-range nothing-at-stake. Slasher fixes the short-range nothing-at-stake problem, but if a fork does start 50000 blocks ago, then there still is no incentive not to mine on both in parallel. Even with transactions-as-proof-of-stake, transaction senders have the incentive to send conflicting transactions into the other chain in order to double spend themselves. But maybe this issue will turn out to be not that important in practice.

Agreed. The only truly "fair" coin is one that gives X per person per year forever. And, before you ask, yes it is one of our major interests to get at least a few of those launched as sub-currencies on ethereum, and you're free to create forks of each one on aethereum which are distributed via proof of ownership of the corresponding ethereum sub-currency at block N. With Merkle Patricia state trees, we even make "proof of subcurrency ownership at block N" trivial for you.

That actually has more to do with us trying to have a solid business structure that makes multiple categories of stakeholders happy, spend more time building the product so ether purchasers have actual working code (eg. my recent pyethereum/serpent upgrades and Gav's POC4) to see what they're getting into, and actually being regulatory-compliant. The pre-sale is the only thing that's getting pushed back; everything else is humming along quite nicely with many contracts already running on the testnet.

Yes. The correct way to implement this kind of distribution model is to pick a block number (eg. 290000), and say that bitcoins at that specific block are what gives you aethereum. Otherwise, you can claim some AETH with your BTC, deposit and withdraw from an exchange, claim more AETH, and repeat ad infinitum. For the system to be trust-free and secure, it would have to be based on private key signing, which means that you would have to have them in a personal wallet.

If you don't want to set up a new wallet and deal with different addresses another somewhat technical alternative is to use my pybtctool toolkit to generate a brainwallet and put your money all in the one address just before the nucleus happens. Pybitcointools/pybtctool includes Electrum message signing functionality with the "ecdsa_sign" command; here's an example session:

You can independently verify that 04334... is the public key corresponding to sha256(cow). Then you can easily sign a transaction to move funds back out. It's literally as easy as a command line utility possibly can be. But I personally would recommend for this group to do something similar to what we're doing and release an application which people can send their BTC to (it's client side so no security risk involved) such that the application signs at the appropriate time and then sends the BTC back out. Having easy-to-use tools for doing this kind of signing would really do a lot to help Bitcoin-based issuance models gain wider adoption.

You don't _technically_. But it is a very good way of funding a decentralized protocol economically. I personally think the ugliness to benefit ratio here is several orders of magnitude lower than something like proprietary software, mandatory fees or, satoshi cyber christ forbid, DRM.

For the CPOF issue you can also use eligius_pushtx as a backup. Also, v1.1.7 will probably include a pushtx and fetchtx via some public bitcoind node that I'll run myself and you'll be able to plug in your own node too.

As much as I don't like paraphrasing Paul Krugman, I think you're conflating normative and positive analysis here. You are basically making the argument that Bitcoin has a socially undesirable element to it because it has high wealth concentration. However, that does not mean jack to someone looking to preserve the value of their own wealth, and people who have wealth will not put their money into media that try to wash wealth disparities away. Bitcoin has among the lowest inflation rates of cryptocurrencies, with the exception of 100% premined/presold coins like MSC, XRP and NXT, but most importantly it has the Schelling point aspect of being the first cryptocurrency out there. Bitcoin is temporally antecedent to every other crypto, and that is one property that it will never lose; hence, it will always be "special" amidst a sea of innumerable other cryptos no matter how powerful they are. That's why I can see it maintaining its value for quite a long time as a digital gold.

http://www.reddit.com/r/Bitcoin/comments/1ytlrf/methuselah_foundation_accepts_bitcoin/

From three weeks ago: http://www.reddit.com/r/Bitcoin/comments/1uyhvc/methuselah_foundation_considering_taking_btc/

For those who don't know, the Methuselah Foundation is a group co-founded by Aubrey de Grey that funds research into the causes of aging, and intends to eventually help find cures for each of these aging-related conditions much like any other kind of disease. Radical proponents of anti-aging believe that we may even hit "escape velocity", the point at which medical technology starts increasing the human lifespan by more than one year ever year, by 2030. I personally think that the Bitcoin community is a perfect fit for this kind of revolutionary medical research that can potentially save billions of lives, including your own, over the next century alone.

Copying my post from Reddit:

This is a bit problematic. Theoretically, we may well decide to redenominate back to 10000 ether per BTC, or 1 ether/BTC, or even some model where we release 10000000 ether and split it proportionately among buyers. So being long or especially short ether at this point in time (and someone has to be short, since a total of 0 ether have been sold/released) is insane IMO. Once we finalize the terms, however, then things like this might be viable.

Also clarifying that this platform is not affiliated with us.

Ethereum has the limitation that every node needs to process every transaction, just like Bitcoin. So on the computational side, it's not more powerful than a single smartphone from 1999. Hence, I don't think saying that Ethereum "is a botnet" is accurate. Can Ethereum be used to help monetize other botnets? That is a more interesting question; I suppose with the decentralized dropbox protocol you can also earn money by renting out other people's hard drives, but an unknown program taking up lots of disk space is something that would be very easy for antiviruses to detect.

Okay, that seems like it can work and cause nodes to waste computational resources. But the cost of such an attack is very high, as Alice needs to  do the attack instead of mining an entire block. Furthermore, miners should only broadcast a block once they are done processing it, so Alice would not reach very many nodes with her block. The issue can also be mitigated with a software change: when a node hears about Bob's block and the successor to Bob's block, and it is still processing Alice's block, it can start processing both in parallel, and then when it finishes the successor to Bob's block it would pause processing Alice's because Alice's block would not be the longest anyway. Thus, Alice is only slowing processing down 2x for one minute. So my intuition is that this is one of those "interesting in theory, not particularly worrisome in practice" situations like selfish-mining.

I don't see why so many people think of it that way. When you're getting VC funding for a startup, it's common practice to hand out something like 10-20% in the first round. Nobody ever thinks of that as some kind of evil plot where you sell the company and then pull the rug out from under the hapless venture capitalists and dilute them 80-90%; people think of it as, well, you creating X shares and only handling out 0.1X-0.2X to the VCs. It's the same here; we're taking preorders for 67% of the initial issuance instead of 100% of the initial issuance.


Actually, we never were planning to have a miner collect more than 50% of transaction fees. Now, we're debating between 0% (tx fees burned), 50% and something in between.

Blockchain-based technologies in general, whether BTC, MSC, XCP or Ethereum, will not be used for HFT. The scalability is simply not there for that. OpenTransactions servers, on the other hand, are excellent for HFT. Blockchains are for higher-value transactions and settlement.

Initial investors are not locked in. Only people benefitting from the first part of the premine (ie. "us") are affected by any lockin.

The current design does have you store blockchain snapshots for every block. That's not that expensive actually; the reason is that we're using functional data structures (specifically, Patricia trees) that automatically provide optimal deduplication, so if blocks N and N+1 are both 1 GB in size but only 100 KB of that is actually different between the two blocks then only 1 GB + 100 KB of space is required; and the savings obviously compound for many blocks (eg. 50 blocks = 1.005 GB, 500 blocks = 1.05 GB, etc.