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.

FWIW, I think the current bignum free code we have in the reference client, now is moderately more clear than whats in the wiki. https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp#L66

wtf, no. Of course they know and validate the genesis block, it's part of the definition of the coin. They would ignore a greater work chain that disagrees with the genesis block.

This is far from clear to me, the obvious formulations of that would seem to have infinite convergence time to me.

You've given a pretty clear explanation of one aspect of the problem— though another one with common causes is costless simulation: e.g. some early large number of stake holders can go fork it off and with no cost produce a simulated chain which a new node cannot distinguish from the original. They can do this at any point, even after exiting the system, years later— so it doesn't seem possible that any inside-system incentives can prevent them from doing so.

You've been told some pretty weird stuff then. Nothing has been taken down, and it's not that complicated a point.

In POW to contribute to a consensus you must burn a resource, which means you must make an exclusive choice among all the possible consensus you could contribute to, to the exclusion of all others... and for your effort to not be wasted you should be spending it on the chain you think most likely to survive.  In pure POS schemes, there is no such exclusivity created.  This leads to fun outcomes like old stake holders can exit the system (sell their coins) and then sell their old keys to people go fork off the chain at a point in the past, at no cost to themselves. Someone who is later handed two histories— the real one and the simulated one— cannot distinguish them, they can tell— perhaps— that someone was naughty, but that doesn't help them decide which chain is the good one.  There are a number of other related implications.  A number of different modifications have been proposed, but so far all of them seem to be obfuscation and not actually fix the underlying issue, which seems a bit fundamental.

You can read more about this in Section 5 of https://download.wpsoftware.net/bitcoin/asic-faq.pdf

PPC was attacked utilizing this fact the moment POS mining became possible on it— a savvy miner tried all possible forks finding a sequence of forks which selected their stake as the winning stake as much as possible. PPC prevented this with block signing and discouraged it by hard forking the protocol so that POW blocks were required.

GPS is unauthenticated. Any local-to-you jammer can spoof it with nothing more complex than a USRP and some software. It's also run by US space command, and the US has been quite up front that they are willing to manipulate or disrupt the signal to achieve military objectives, they're able to perform geo-targeted alterations of the signal too.  It's pretty useful on average, but it's not a secure solution by itself.

Yup. Some altcoins have made it worse with crazy rule changes but in bitcoin it's kinda boring. We could also close it with a soft forking change e.g. detect the median dodging and add a further time clamp, but its such an unimportant thing no one has given any real though to the safe and sufficient rule for it.  I went as far as adding an attack to testnet so there would be something to test against.

I'm familiar with that paper and have linked to it on the forum before. Note that Lamport is talking about a distributed system, not a decenteralized one.  As I recall process he describes is not byzantine robust, requires a jamming proof broadcast network, and does not have anonymous membership (the players must be selected in advance, so it cannot meet our definitions of decenteralized— in particular it needs a consensus arbitrary ordering of player identities to break ties).

As far as POS goes, I've not seen anyone tender a solution to the nothing at stake problem, and so I still consider it non-viable for a decentralized consensus. PPC makes it work by requiring POW and using centralized block signatures. NXT was previously making it 'work' by not releasing the complete source to their software, I haven't checked lately.  So far POS schemes all suffer from attacks like former quorums (e.g. people who held coins at some point in the past) can costlessly replace the history by forking off from a point where they did have a quorum after they no longer do, and from things like the optimal income producing mining strategy is to mine all forks (because there is ~0 marginal cost in mining a fork) instead of a single one. Schemes like honesty bonds do not help a node decide between two different networks— the real one and a simulated one, and cannot punish someone if they perform the attack after exiting the network completely.

Using hash-chain mediated common view time transfer, as I wrote in 2011: https://people.xiph.org/~greg/decentralized-time.txt

Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work.

You cannot get nodes to accept such a chain, you're confused about what people are talking about with timewarps; or confused because this is really an altcoin question and some altcoins have further broken things. Bitcoin won't switch to a chain with less apparent work.

No competent wallet software would recognize a payment to an scriptPubKey of a kind they wouldn't have created as theirs, and no wallet programs that I'm aware of do.  The model used in Bitcoin is that the receiver specifies the address they'll accept for a transaction. You can make up random stuff that, in theory, someone else could spend ("It's just one greater than some other private key of yours!", or some script) but they're not going to notice it.

Non-standardness has nothing to do with it— a 1 of 2 multisig is perfectly standard. The reason wallets will not report payments to such a thing is that they didn't author it.   A scriptPubKey _is_ a public key.  Expecting a wallet to magically notice a random unsolicited 1 of 2 scriptpubkey that contains a EC point they happen know the discrete log of is just like expecting them to notice a payment governed by a private key one greater than one that they know.

Right, yes. You'll know about that when it's available.

It won't be noticeable at all except during initial sync, and even there only after a number of other improvements which make a much bigger difference. I only brought it up to further emphasize that computation isn't a major issue.