I posted an update to our staking and pool balances. We're now up about 7.5% in CLAMs since the pool started in late November.

Better crypto market i.e. capital flowing into the space instead of a bunch of coins competing with each of other for the same scraps, each getting excited when it moves up a few spots on CMC, then disappointed when the pump ends and and some other coin becomes the favorite flavor of the day.

The whole thing is a bit too zero-sum at the moment. Each coin can claim to have various advantages over another and they are all correct to a point, so you mostly get churn, with maybe fundamentals driving some trends over a 1-2+ year timescale. Even that last point is questionable as Ethereum today is close to where Bitshares was a few years ago. Maybe that is fundamentals and relative potential playing out, or maybe just more churn. Hard to say.

Until more people and/or more money recognize the value of cryptocurrencies it will continue to be much the same.

Nevertheless Monero at #18 as I write this is a serious project that compares favorably with higher ranked coins (and one would be hard pressed to find similarly credible projects ranked lower) and seems undervalued to me relative to the peer group, so even in a churn-dominated environment, it can do okay. The GUI and other upcoming improvements can help unlock some of that value.

Now you're on to this corporate blockchain thing which is probably okay if you are looking for a short term payoff (but you better hurry, as that iron is hot right now).

However, it is largely irrelevant to the question of decentralized cryptocurrency and certainly to Zcash, the cryptocurrency that is being launched (though maybe not the company launching it, as they could potentially get some business building blockchain applications for businesses, as Blockstream an others seem to be doing).

As for you giving me career and financial advice, I'll not comment beyond this non-comment comment.

Anyway, if you want to build other applications based on the technology behind Zcash (the OP asked this), you can ignore Zcash (which is otherwise a rather uninteresting Bitcoin fork) and focus on libsnark.

TPTB's premise is that IP addresses and other metadata are being spied on. You can't transact in basecoins, even just to move from one mixer to another, without encountering that exposure.

I don't agree with him that transacting in zerocash without worrying about your metadata exposure is of any real value, and neither does anyone else, but that's a different issue.

Also, TPTB operates under the premise that miners will be centralized and engage in 51% policy attacks. If they do that they can refuse to allow you to move your basecoins to the new mixer unless you identify yourself.

I agree with you that the possibility of moving to a reset coin has some potential value. It also has potential risks. The more times your have to perform the setup, the more opportunities there are for it to be compromised. Especially if it becomes routine and people get careless. Zcash has not said anything about planning to do these kinds of resets, as far as I've seen.

The above comments are in regard to a permisionless cryptocurrency ledgers, not permissioned blockchains.

The process of resetting the mixer and forcing people to remint does compromise anonymity. If you were an adversary and wanted to spy on zerocash users, forcing such a reset (and then spying on them while redeeming and reminting) would be precisely one way you could go about doing it. This general pattern is a classic exploit method (e.g. force/trick user to reset password; intercept new password, etc.).

This does work, I think. However, Monero does not have a fixed block size. One of the original value propositions (stated explicitly in the white paper) is to remove those arbitrary limits (i.e. who gets to decide on the block size) from Bitcoin, and if you do that, then you do need a tail emission.

As I understand it (not a cryptographer), there is some inherent performance benefit to the curve25119-based cryptography (or maybe to implementing it on real hardware), but I don't know the magnitude nor how close either implementation is to optimized enough for that to matter.

In reality I think raw signature verification performance is really one of the least important scalability concerns in practice, currently, and both implementations are reasonably optimized once libsecp256k1 is integrated into Bitcoin Core (already done, but I think not released yet).

In NoodleDoodle's performance commit he noted a benchmark of 2.5ms/tx on i7-2600. That's 400 tx/sec on a 2011 desktop. A reasonably priced current-gen server (say dual-Xeon 10-core CPUs) is probably several times faster so close to 5K/sec, but I don't know the exact numbers. There is more optimization available still (we aren't using the most optimized elliptic curve asm library available from Bernstein for example, just his sort-of-optimized C library).

With the move to ringCT, it will probably be different (though some of the differences will offset, such as having fewer outputs/tx), and we will have to reevaluate.

That's a pretty big range. 5K is somewhat more plausible than 120k, for longer term.

5K can fit in a 100 megabit connection and require something like a large hard drive a month to store the blockchain. Not going to be home-based nodes at that point but it could still fit easily within satoshi's vision of many independent nodes in data centers, even small data centers (10 years is only 100 hard drives -- not really much a storage array). Ignoring future improvements in storage technology which I think is ArticMine's point.

Considering a peak 60x higher means you would need 6 gigabit connections, also plausible for a small-ish data center. As long as the peak isn't sustained too long, storage wouldn't become a problem, and verification can be almost arbitrarily parallelized.

I agree with your main point about there being better ways to scale than jamming everything into one chain though.

Small point: The block size can't grow at all without some penalty. Despite what the white paper says the penalty kicks in at the median size, not 10% above the median. The implementation has always worked that way.

wtf?

We don't know how the participants will be chosen, so perhaps best to wait and see before reaching conclusions.

Any coin that does not have full visibility and tracing is going to have this to some extent, but in practice it will vary a bit.

In zerocash since you literally can't see anything about the state of the ledger (by design, and that is a feature), there is zero possibility of detecting such a bug/exploit should it occur (other than finding the method yourself). Zerocash also has the possibility of the setup being exploited or botched, however unlikely that may seem, allowing invisible coin creation, an issue that doesn't exist with the others.

With something like ringct, where the origin is ambiguous and the amount is hidden and even regular ring sigs just the origin is ambiguous, in some cases, if a bug like that did exist, it would be visible (which would make it not really a usable exploit). But in other cases it might not be visible.

The math and code in these latter cases (ringct and regular rings) is much, much simpler then zerocash as well, so the risk of such a bug even existing is probably lower (though it is hard to assess such a thing precisely -- it mostly comes down to judgement).

Evan flat out admitted on the Dash thread that the insiders are in total control of voting system, by design (yet another FinCEN issue BTW). He said they could lose that control later, as more coins are (slowly) mined, although even that assumes they don't accumulate more coins in various ways, or change the voting rules. I wouldn't count on them ever giving up true control (other than as part of their exit, of course)

Of course it is impossible to know for sure but I'd find it surprising if he were involved, had such strong feelings about changing economics, and didn't even make his opinion heard when, for example, changes to the emissions and block time was discussed pre-launch and during the first week (though no changes were made).

Other than people following Bytecoin (which all of us were) most others found out about Monero when rpietila started talking about it, a month or so later, or possibly a bit earlier when it started getting listed on exchanges.

Just frankly more likely he misunderstood what he was buying.

I guess a simple "Buy Monero" plug in could provide instructions for buying Monero or maybe actually set up the trade with the shapeshift API (or another such service), having already filled in your XMR address for you. But actually sending the BTC or other form of payment would have to be done using a BTC, etc. wallet.

You bought in when exactly? Because the tail reward language was included in the original Monero OP from the initial instant of its creation on 2014-04-25. You might have a case if you were the bolded trade from the OTC thread below:


Those, along with two auctions I ran that week (won by eizh and SlyWax) are the only known trades that occurred before the Monero OP (during the 5-day Bitmonero era).

You can't be one of the last two because those were both NoodleDoodle selling to eizh. I also suspect the first one was NWO buying from
pandher so you probably aren't that one either, but that isn't clear from the OTC thread.

If that trade is not you, then you may have misunderstood the economic model, but it was not changed out from under you.

No it means you could enter a BTC address and pay using the XMR in your wallet via xmr.to or shapeshift. Potentially, I suppose a plug in to hold BTC is not out of the question but that is not the originally envisioned use case.

Yes, I would say the only meaningful decentralization is actual decentralization. If you have assets in CK, that is not in fact decentralized, so you should expect that the operator has control over them and you are at their mercy.

If you don't want that, hold an asset where you control the private keys.

Same for me. Thanks for your efforts aiwe.