All things are subject to attacks, to make them stronger one need to be honest about them. Bitcoin assumes that the majority of the energy expended on its POW is not controlled by a byzantine attacker. Maybe there are things that can be twiddled to make the costs of attack higher?  But that isn't something that comes quickly or easily— most of the times tweaks increase the cost of one already effectively unachievable attack but do so at the expense of opening up a new weakness which is currently absolutely precluded.

Talking frankly about attack costs doesn't mean that anything is weak on an absolute scale.  By contrast, the systems where their authors claim there exists no attacks that they can imagine are almost certantly intolerable insecure since a lack of attacks— even infeasible ones that we can be comfortable with— means that there is either indifference to security, inadequate understanding of their own system, or simply a massive failure of imagination— any of which could be hiding quite serious attacks.

I didn't say anything about coming from the same stealth address. I'm specifically talking about a sendmany.

Because the bait must be small to prevent deanonymization, and so there would still be a large amount of DH overhead if the transaction contained multiple nonces, plus doubling the size of the marginal txout data.

The bloom bait should be in separate pushes in a single OP_RETURN, the addr_index patch to Bitcoin core was setup to index  separate push operations for this sort of reason.  So there should be one 33 byte public point in the push, and 1 to N bait.

This is compatible with CoinJoin too— the participants just share a random value.

Gah, if its specified that way that sinks. There is no need to have a separate public point for every 'stealth' output.

Beyond the lack of need is unreasonable to have a separate DH nonce per output both for bandwidth reasons and also for performance ones (the scanning host having to do N point multiplies per transaction is ugly).  I recommend fixing the specification to get rid of this overhead.

Currently the IsStandard behavior limits transactions to a single OP_RETURN output.

Putting it in the Bitcoin chain itself is a hard-sell because there is a serious scalability downsize (all the cryptographically strong anonymity techniques break pruning), among other pedestrian reasons.  A side-chain using it seems virtually certain to me, limited more by the deployment of sidechain tech than anything else... even more so than the ZeroCash anonymity design simply because the ring signature approach is so simple by comparison.

But it's all a guess at this stage. Technology progress in Bitcoin is slow— for good reason— and now with the prospect that altcoin pumpers may we well funded to try to disrupt that progress… well, it'll be sad if what kills cryptocurrency isn't competition from traditional financial instruments or authorities but just poisonous behavior between competing systems. :-/

Fee burning is usually ill advised for an unrelated reason—  usually they're burned as some way of escaping some bad motivation (e.g. miners might be incentive to bloat up blocks if they could collect fees!),  but forced fee burning is actually impossible because you can pay any non-forced feed out of band rather than as a fee (and forced fees have a problem of fixing the economic scale).  E.g. I can just make my transaction pay the miner as an output instead of as a fee. I can even helpfully author N versions, each paying a different miner, and the miners can choose whichever version they like.

For a long time eligius ran code that considered payment to the pools donation address as fees, I'm not sure if it still does— but it's a trivial change.

Not really an answer to your question directly, but perhaps it is one indirectly: the disincentive in those systems can be overcome by exactly that dodge to the intended incentive system there... pay the miners out of band and they're rewarded for including the transactions. 

Alas, none of the bugs or short comings were fixed in doing that— and it doesn't appear that any of the people involved in it have the background for the low level work. So you might have just written out the only active developers of the software, may not bode well for continued development.

The fork also can't claim to be roses and sunshine wrt fairness: As someone very interested in privacy technology and as someone who is usually near the hub of technical discussion in the Bitcoin system, I'd never heard of that fork until just recently— nearly a month after it's start.  And… has a very fast coin distribution, and was started with a difficulty much lower than the network could support. A lot could have been done to improve fairness (e.g. fixing the subsidy to a low level at least until the difficulty crossed the level where the prior system was, or setting the minimum difficulty to a good fraction of the achieved rate), promoting it outside of pools of altcoin speculators (e.g. why do I hear about zerocash 100,000 times for every time I hear about this stuff?), etc.   Not that I think that any of the altcoin stuff is advisable, but if you're going to make a fork on the virtue of fairness wouldn't it behoove you to actually be fair?

And, of course, the fork has now also been forked. That one at least tames the insanely fast distribution somewhat... but it too doesn't fix any of the worse parts... I can only imagine that we're going to continue to see once a month forks of that stuff— suits me fine, while the technology is interesting and useful, the speculative churn is not.

Well, they could if bitcoin were designed a bit differently, but I don't know that its worth it.

Imagine that each txout created by a transaction reduced the permitted block size by— say— 100 bytes and every txout consumed by a transaction decreases its the transaction's effective size by up to 100 bytes per scriptsig (clamped to not result in a negative size for each scriptsig)... and then there was some sanity limit on the real size to prevent silly attacks.

Then in that case the transactions that are creating txouts are effectively prepaying for the space the signatures will take to consume them. This would help a lot with the UTXO bloat.  I don't think anything short of utxo expiration of some form can be a complete solution, but if the system worked a bit differently fees would be a much better tool.

As hard as it is to believe, people other than me do occasionally have really good ideas.  ... (No, I'd only heard about it a couple months ago and looked into it in depth until the last week).  I think all these altcoins are horribly ill-advised in their altcoinness. You're in the wrong subforum and thread if you want to talk about cryptocurrency speculation— my interest here is just in the techniques— and I'm not going to credit some random code aping fork for other people's work when talking about them.

(In case anyone had the impression that I thought bytecoin was all love and wonder: the implementation is currently really immature and somewhat buggy— and perhaps not likely to improve if its authors are now getting voted off the island in a fork. The POW is very slow to validate, and seems generally ill-advised to me (see https://download.wpsoftware.net/bitcoin/asic-faq.pdf), the adaptive blocksize stuff seems dangerous and the coin burning excuse for it can't work as expected in the long run since miners can get paid out of band, ... but the privacy design is very good, though even there its incompatible with pruning (but so is everything else). Of course, all these concerns also apply to forks that just aped the code.).

I think we'll never know what really happened there. SD's traffic fell off almost instantly with the change back to private ownership. I believe, and I think that the data supports, that there was activity going on to pump the level of traffic there— though for what exact motivations are anyone's guess. Hideously inefficient in any case, and not even necessary for security.

I know how to fix the no pruning problem but it comes with (your choice of) costs. PeterTodd does too— as we'd talked about it before, so it's possible ZeroCash will implement one of those solutions. (Either you make old coins unspendable or expensive (very large) to spend (and then perhaps economically unspendable).. in both cases your anonymity set is somewhat reduced. Then you can have some form of pruning.).

A key point here isn't that I believe it's impossible— it's that I believe its impossible absent some trade-off— some other attack the system becomes vulnerable to, for example— or consideration/cost, or assumption (e.g. that no past majority of shareholders will ever act against the interest of the system, even if they've long since left it), so what exactly is that tradeoff?  Keeping the solution secret also implies keeping the vulnerabilities it creates secret, which means that people will be all the more exposed to them.

The new block refers to the prior block. If you don't know the prior block you fetch that too, until you connect to the chain you know. Because the rate of difficulty change is capped a possibly longer chain cannot have difficulty below some threshold (since it can't just be minimum diff blocks), so creating a long bogus fork would be very very expensive. If you did go and make a long bogus fork that was shorter than the real ones, nodes would happily go and fetch them (not saving the blocks) back to where it connects and then realize that it was shorter and just reject it, so the harm would only be wasting bandwidth.  They might download some of the wrong one, but they'd notice when exposed to the right one and deterministically switch to it. This logic is used every day with ordinary 1/2 block forks.

If there ever were a large number of attacks trying to waste nodes bandwidth with expensively created short forks— it's possible to construct log() scale proofs of a blockchains' whole difficulty... we need to have them for some other applications in any case, and they could be employed there.. but considering the cost of the attack and the minimal effects, I doubt that will ever be required.

NullC.

I made a number of technical comments on it on Hacker news, along with some comparisons with some of the alternatives, https://news.ycombinator.com/item?id=7765455

Why wait for darkcoin v2? I mean if its just copying stuff in bytecoin then you can already use that.

One time addresses are an almost certantly, people have implementations (search "stealth address"), the ideas just need to mature and get standardized.  After trying them out in Bytecoin I can say that they work more nicely than I expected.

The ring signature is a little trickier:  The cryptography itself is simple (I'll probably add a version using SECP256k1 to Sipa's libsecp256k1 once he figures out how he wants to handle hash functions for determinstic signing and schnorr signatures), but the overall implementation requires an additional spent coin set which is another utxo like data structure— this also isn't so bad, but its completely incompatible with pruning. Effectively Bitcoin full nodes just need to track the currently spendable coins in order to validate blocks, spending coins reduces the set, creating outputs increases it. Right now that data is only about 300MBytes and it grows much more slowly than the blockchain (even with people gunking it up with forever unspendable data storage outputs). In the bytecoin approach transactions create spendable coins and transactions also create spent keys, there is no 'reduces'— it grows forever. Breaking pruning is pretty big scalability hit in the long run.  (Incidentally, all other cryptographic anonymity systems have similar long term scaling challenges)

But having this stuff available FOR Bitcoin isn't the same as having it IN Bitcoin. So I wouldn't count out having it for the Bitcoin currency even if I don't expect to see it in the Bitcoin blockchain anytime soon. It certantly seems easier to deploy than zerocash which requires a similar spent coins list plus a committed UTXO and a lot more heavyweight crypto code.

That maybe it's just handing a mining hardware manufacturing monopoly to a near-duopoly of multiple billion dollar CPU making companies that have patent warchests that probably preclude competition? And then there is the advantage they that botnet herders have… It's hard to say. I don't really believe "CPU mining" is actually possible— even if you somehow found a function that was suitable as a good POW but made perfect use of cpu hardware, you can usually get a factor of 2-10 in better (power, mfg) efficiency by cutting out fat (e.g. IO) and optimizing for mining use.  Since mining is ideally perfect competition even 'small' advantages can push all the competition out of the market. This also applies to the R&D, a lot of CPU costs to customers are NRE— cost to Intel and AMD are much lower marginally.

Andytoshi wrote a lot more about POW functions and I basically agree with his views: https://download.wpsoftware.net/bitcoin/asic-faq.pdf  Mostly I think that POW stuff is the least interesting stuff to mess with, yet it's easy to get it wrong (e.g. and permit surprising optimizations) or create collateral damage (e.g. making verifying too expensive, or precluding SPV nodes (e.g. POS coins break SPV pretty badly)). Way too much though is put into POW because its a kind of easily accessible surface technology that attracts a lot of shed painting.  About the only thing in that space that I've found at all interesting is the idea that it might be possible to make a POW out of ticking for public timelock encryption... though the fact that having "useful side-effect" actually is a point against a POW approach, we currently have basically other idea of how decentralized time-lock encryption could be created (Perhaps through indistinguishably obfuscation of some code that read bitcoin headers to get the time— but even that would require trusted initialization) ... so getting it as a POW outcome might be interesting.

Bitcoin is not a POS coin so it's a bit weird to say that a thing that is completely inapplicable to Bitcoin is inapplicable to your thing because its different from Bitcoin, especially if that reason is "secret sauce".

The simulation example is probably the hardest to convincingly wave away. Say tomorrow half the NXT value holders decide to sell their coin. Six months after that their old NXT keys fall into evil hands. The evil people create a fork of the NXT chain and in seconds mine it up to the current day. How do existing nodes know not to reorg onto the new one? If there is a threshold where they won't reorg, what prevents the malicious parties from producing blocks right at the threshold and making one half of the network stick to one chain, one half to another?  And most importantly, a NXT node that has been offline for seven months comes back, how does it know what chain to follow?  If there are protections here what assumptions do they make and how might they fail? Costless simulation isn't the only problem that arises out of nothing at stake, but its one of the simplest seemingly hard to resolve.

If you're going to not only claim that you've solved those cases but that the solution is both "secret sauce" and trade-off free I'm going to have to say bullshit. If someone else is making those kinds of claims to you and you buy them, I've got a nice bridge to sell you.

I'm really surprised to not see this technology more widely discussed. For all the hype people give the currently-vapor zerocash stuff, I think the privacy design in Bytecoin strikes a better complexity/privacy/security tradeoff.   In general, I think introducing new currencies is unfortunate— why break up the adoption and lose network effect just to get some extra transaction powers? But at least as far as the privacy technology goes the stuff in Bytecoin appears to be top notch and perhaps most importantly it already exists and works.

Sadly the Bitcoin and bitcoin-clone mining ecosystem has really made people stupid on this front. I don't know if I should laugh or cry when I see people pissing away their earnings at 5% fee PPS pools (which may well be ripping them off beyond the advertised level) then turning around and gambling their earnings at negative expectation gambling sites.

Some altcoin goes through some substantial (and probably ill-advised) effort to be 'cpu-only' for equality and decentralization and even before the ASICS appear the users are just falling all over each other to hand away their control and income to a third party, even going to the point of not participating in a technologically very interesting coin if there doesn't exist some pool to take their money... crazy.

Yea, the Bytecoin/Bytecoin thing caused me to not notice it for a long time.

The cryptographically interesting Bytecoin has a reasonable whitepaper: https://bytecoin.org/old/whitepaper.pdf  Some of the things it does appear to be pointless or ill-advised to me and I would have counciled otherwise— but as far as the privacy aspect goes, the ring signature approach appears top notch. The privacy depends on the decisional DH problem, so perhaps you could argue that its privacy has a slightly weaker cryptographic story than the basic discrete log stuff (computational DH) but in the curve they're using its believed to be equally strong.  In any case, anything that has reduced the privacy question to asking about cryptographic assumptions has gone pretty good.

Sorry for the OT tangent here. Though there may be some good bitcoin-relevant privacy things to mine out of the bytecoin design.

No, not in a meaningful sense. Validation is very cheap. You do run into block size limits if you're trying to transact too much at once, but any privacy system is limited in its privacy by transaction volume.

"Dark Coin" really strikes me as pointless. The whole idea in coinjoin is that coinjoin is already part of the design of Bitcoin. There is no advantage in having a new and different system. If you're going to do something incompatible, losing Bitcoin's network effect in the process, then you can do something much stronger.

It also depresses me somewhat to see people talking about darkcoin (or even zerocoin/zerocash) when bytecoin has a privacy system with much better properties than CoinJoin (it's similar to CJ except you safely join with offline coin holders, and all users are participants), something made possible by the fact that it doesn't have to fit within the existing Bitcoin network, and it's completely practical, reasonably performant and deployed for some time now. But strangely, it's virtually unheard of...  Bytecoin's privacy properties are in some sense weaker than zerocoin's— since its like a supercharged coinjoin— but the cryptography is much stronger and much more efficient, so in practice I'd expect it to have better anonymity just due to it being much more practical (also as evidence to it existing as a deployed system).  ... so yea, if you actually are interested in privacy technology in a non-bitcoin system, Bytecoin seems to have pretty much nailed it.