Most of HF's customers have no idea about the bankruptcy at this point.  I've received no communication about it.

Ozziecoin, Your pump and dump dance would probably be more effective if you were less transparently dishonest in your approach.  I'm normally happy to ignore the nonsense in the altcoin subform, but since you saw fit to go distrupt the coinjoin thread with some offtopic insult hurling I thought I'd bring the extensive response back here where its topical.

CoinJoin is trustless— which is orthogonal with centralized or decentralized, it could be implemented several ways (though trustlessness is usually a prerequisite to a decenteralized implementation). Post 5 in the CoinJoin thread writes in depth about implementing it in a decenteralized way, none of which appears to have been implemented by the darkcoin developers as far as I can tell— from what I've heard it seems that they're not even able to understand it. (This is a disappointment to me, since I was trying to describe these ideas clearly so others could understand them.)

More amusingly, what DarkCoin does is highly centralized because the software is closed— you can't get more centralized than closed source. What the actual behavior is, is anyone's guess— it's impossible to review due to it being closed— though "masternodes" does not sound like something decenteralized, it sounds like something that creates a small chokepoint which could be used to deanonymize its users, like a server based CoinJoin but worse since you have to hold a huge pile of coins to run a server.

As I've said before CoinJoin is interesting because it's inherently part of Bitcoin already— it just needed better tools (and now there are some, e.g. darkwallet) to make it available to people.  It's a privacy improvement over not having it, but it isn't perfect, but it also didn't require any changes to Bitcoin (much less a whole altcoin) to deploy it.  In an incompatible system much better is possible as is proposed by ZeroCash and much better is actually _realized_ by Bytecoin (and its forks... Monero, Fantomcoin, etc.), the later are actually working (if immature, due reinventing many wheels) implementations of much stronger privacy, decenteralized in their implementation, all released under a good open source license.

From what I can tell the only purpose DarkCoin serves is to depress me about the state of humanity.

I think you should keep your garbage pump and dump crap out of this thread, put it someplace people won't annoy me by reporting it.

The things I described above in this thread can be implemented in a decentralized manner, as is described in some depth in post five. What darkcoin does doesn't sound decentralized at all— it depends on selected servers— but whos to say? Last I checked software was both closed source and not even working. When darkcoin was announced it claimed what it was implementing, however, was coinjoin.

Bitcoin is openly developed software, anyone who wants to work on it can contribute to it, and last I checked none of the people who have ever worked on it are your payroll. If you're honestly concerned about privacy in Bitcoin you could do some things to help improve it. Pumping some sketchy altcoin in the wrong sub-forum, however, is not going to help, nor is attacking people who have no responsibility to serve your interests.

For some context for those confused about where this little OT tangent came from, someone wrote a fairly scathing analysis of DarkCoin, basically making a case that it's a substanceless effort promoted by misleading marketing. Unfortunately, in making their argument they linked back here... drawing along some vigilant defenders. I'll continue deleting any more darkcoin posts that show up.

The attacker knows everything in the blockchain. The attacker knows the identity of the payer or payee of some small number of transactions. The attacker wants to follow these identified funds forwards or backwards and expand their knoweldge recursively. The CJ users want the attackers analysis to fail, for themselves (most importantly) and for third parties.

I think of two main attack objectives— where the attacker is trying to identify a single user and where success/failure depends on how persuasive the evidence the attacker can extract for that single user.  And one where the attacker is trying to broadly deanonymize everyone in order to feed larger scale analysis. For this latter attack the defender's is successful if they're able to increase the noise level of the analysis by a non-trivial amount at low cost to themselves, e.g. success in this latter cases is completely continuous.

I outlined some more specific attack objectives in the original post— things like people you do business with being able to determine your income, net worth, supplies costs, or prices.

The privacy tech is indeed very interesting, the rest of the tech... uh. some is very clearly ill-advised (e.g. the "CPU-only" pow is now much faster mined with propritary gpu software— now it's just acting as an albatross, the slowest to verify POW yet deployed and failing at the advertised goal in record time—  the blocksize control algorithm is totally incentive-busted in the long term) and the software is very immature.

The history around the launch is pretty sketchy, and as far as I know there is no evidence that it's as old as it claims to be, but why the heck would anyone lie about such things? It isn't like anyone is really going to believe it or that it matters if they do or don't. Now there are a zillion forks, it's not clear which will survive, they're also being secretive for "competitive" reasons  ... in any case, this is the tech subforum, and the tech is interesting without regard to the (usual) altcoin drama.

Back to the question, it would be trivial to prove something— like a blockchain or a program— existed at particular point, it would have only taken someone who knew about the something to have posted a hash of it someplace durable, like in the Bitcoin blockchain. This doesn't seem to have happened here, but instead things outside were very aggressively committed in that chain, which proves the other side of the boundary (it wasn't created any earlier), so aggressively that the absence of any proof in the other direction is additional suspect.

But perhaps who cares? Alt these "CPU" altcoins seen to end up sending most of their coins to a small number of fast speculators, seemingly powered by stolen computing power and private optimizations... if you go by hashrate you'd see numbers like a coin that hardly anyone has heard of having 60k fast cpus worth of mining a month after it was created... Uh yea, right. The unfairness of some launch or another I suspect mostly impacts the squabbling between very early speculators, and fairness to other people depends more on transparency and on "fitness to purpose", allowing people who are not speculators to participate in the economy. So the bigger question is if anyone is going to go complete anymore of the ecosystem, rather than if someone got an early advantage, because its very clear that in all these things someone did.

There are a healthy amount that are configured to accept connections— its a default in full nodes— but simply don't because some NAT/FW prevents it. SPV nodes do not advertise themselves.

It's not completely clear to me that the nodes in question there actually weren't accepting connections either, but in any case it's expected that there be a large number of advertising nodes which are actually unreachable.

They don't, what you're describing isn't how the Bitcoin protocol works at all.

Other peers don't share information about you, you broadcast it— or  you don't. If your node is not configured to accept incoming connections (e.g. listen=0), knows its not in sync with the network, or is unable to determine a plausible external IP it won't broadcast an addr message for itself.

Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.

We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.

Yes, — since we can't distinguish tor clients from each other banning them would just ban all tor peers, which isn't helpful so we don't do that.

I'd like to have some costly resource peers can optionally use to get themselves a preferred position, see the link I gave for some thinking about that... but absent any smarts it's still best to not increase an attackers power by letting them ban other nodes.

Right, most 'smarter' topologies are highly vulnerable... And bitcoin only requires one of its peers to be working well for the node to work well, so connecting to a couple nodes should provide  pretty reasonable performance most of time without further intelligence.

Having different or the same IPs doesn't prove anything.  (I don't have access to that info, but MinerTechnologies asked me to— I think doing so would be pointless).

No it doesn't, as change can still be taken. For all combinations of inputs and outputs there is some party/party payment matrix that allows any output party to be any input party, though indeed, some are more plausible than others.

WRT payment protocol, indeed, you'd want the receiver to also be able to specify additional inputs you'd like them to include, which is also good for consolidating the receivers wallet— sort of the opposite of merge avoidance, but privacy superior because it results in confusing merges... but the payment protocol is extensible, so it just requires someone who cares to specify that out and get it implemented.

This is getting offtopic, but you cannot distinguish a "careless join" from one with different correspondence  which transferred value. E.g. A provides 1 btc, B provides 2 BTC,  C takes 2 BTC, D takes 1 BTC. Is it a trivial B->C A->D or is B paying A and the roles reversed or is it a single party transaction with change and some odd coin selection?  If you'd like to discuss this further, take it to the CoinJoin thread— better to discuss this there than half of what has been there recently.

It can't in that case, thats why it has an optional scriptpubkey argument.

An immutable ID is not _generally_ possible— since some forms of mutability are very much intentional (e.g. anyonecanpay), and also isn't generally needed. Presenting an "immutabile ID" which sometimes isn't would seem very dangerous to me.  You can track your own transactions by which outputs they pay, or by which inputs they spend (so long as you aren't doublespending yourself), or both.

WRT, -1 confirmations, it doesn't strictly mean "never will" since there could be a reorg that takes a transaction from -1 to confirmed, but it does mean that it cannot be confirmed in the current chain without a reorganization.

Doug, you've asked several questions now which are 'down in the weeds' and don't describe what you're trying to accomplish. You can usually get more useful answers if you also tell people what you're trying to do.

It sounds to me that it is.
I'm not interested in participating in a secret process. I'll comment on public proposals, as I have time available and if they're remotely interesting.
They haven't, as far as I know.

In the case of exploitable vulnerabilities keeping people safe can be at odds with transparency. In Bitcoin what we've tried to do is narrow any vulnerability down the a non-consensus behavior where implementations would reasonably expect to differ, or the smallest 'bad' behavior, the corner case the attack requires that no one had previously considered, and narrowly fix that... The idea is that the broad behavior of the system is part of the contract between all of the users that no one has the right or ability to just unilaterally change—  but some "it crashes in this case" wasn't part of the contract, and if we carefully remove only the crash via a not-very-transparent change which is compatible with people continuing to run the old code, then we've done the minimum evil there.

Changes to the long term, broad scale behavior, stuff which isn't an immediately exploitable vulnerability— that stuff absolutely must be discussed in the open. It's hard enough getting quality review for complex design decisions in cryptographic protocols which are openly discussed, moving in the shadows is suicide.  It's true that in theory people can suss out the behavior of these things from the code-drop patches and decide to run them or not— call the alarm bells that the developers have hidden some kind of concerning change, but the cost of reliably finding that stuff is high. If a situation is created where a publicly used cryptocurrency has a cabal that is making large design changes in secret, then thats not a really decenteralized system. Technical compeition isn't an excuse for undermining the decentralization that supposedly makes this stuff valuable in the first place, it's just another example of the shittyness of the altcoin space— they're often developed by greedy people who put their profit first.  This has been a complain I've raised a couple times with the Bytecoin-forks, their openness-relative-to-bytecoin sales pitch doesn't really seem to agree with their behavior.

Of course, that kind of hyper competitive approach also makes it hard to report actual vulnerabilities— the more competition there is, the more concern that if you report it to them they'll just use it to attack each other.

In this case perhaps the brain damaged block sizes are more immediately exploitable that I suspected, I was expecting it to be discussed in the open because I believed it was only a long term disaster, not also a short term one too. If so, I'm sorry for whining that the development of the fixes isn't in the open; though I'd still encourage everyone to separate narrow fixes from more substantive changes.

Thats really disappointing, I thought that sort of lack of transparency in Bytecoin was what justified your fork in the first place?  Not to mention the practical ramifications— the brokeness of the current behavior was instantly obvious to me when I saw it, but too bad it was in an already deployed system.  You do no one any favors developing in secret.

Where is this being discussed? (sorry for the OT, but I suppose the changes are relevant for all the derivatives)

Quite the opposite. Merged mining normally has no reliance at all. It's just the same work used in two places via a commitment. The things that FCN is merged with can stop existing and FCN would continue along fine (which is also demonstrated by FCN not caring at all).

The fact the merged mining is a non-trivial protocol change should be interesting— right now it generally seems that the bytecoin ecosystem as a whole doesn't have a lot of hard core technical attention on it, which is concerning, considering some of the issues in the system (e.g. the completely unhinged blocksize controls)... the fact that FCN has people working on it who are willing and able to do lowlevel protocol work is a positive sign.

Incorrect.  People have speculated that potentially an attacker powered by non-public mathematical breakthroughs could select parameters in a way to make a system weaker against publicly-unknown attacks which require specific improbable curve characteristics. This is pure conjecture, however— though it's something prudent to be cautious about, it is not a known backdoor vector by itself. The process for selecting curve parameters already excludes known classes of bad curves, if we knew about any other classes we'd exclude those too.  In the case of Bitcoin our parameters were selected in a way where performance considerations removed their degrees of freedom (like the ed25519 parameters were selected), and are all explicable from first principles. In fact, they have an additional property that even if you drop some of the performance characteristics, and increment from the smallest possible parameter requirement the first curve of prime order you find is the one Bitcoin uses. Other cryptosystems also use nothing up my sleeve numbers, where an abundance of caution demands the designers pick them in a way that limit their degrees of freedom but at the same time no one knows of a way where control could be used secretly to do something bad— it's just a good practice, not a backdoor closed.

In the case of the GGPR'12 based SNARKs there is no comparable way to generate the parameters: The creation of the prover/verification keys requires computation using secret values, which— if known— completely compromise the soundness of the proofs. Here the backdoor is very concrete— not theoretical— when you know just a couple of the secrets you can do a few multiplies and have a false proof. Worse, there is no known way to use a nothing up my sleeve number to pick the parameters to convince people that no one could know the secrets. The best you can do is use process, like the CA system does (but potentially way better) to convince people of security.  This isn't insurmountable for _many_ applications, but it is not at all comparable to EC curve parameters, there is nothing in curve parameter selection that looks like a magic number where if the attacker knows it all is lost. As far as I know there nothing like this in widespread use, the nearest parallel I can think of is the backdoor in DUAL_EC DRBG, though in that case the backdoor was a "surprise" and no process to prove that the potential backdoor wasn't weaponized (because it was)— which certantly makes it more concerning. There are a fair number of proposed _theoretical_ cryptosystems which have similar assumptions (e.g. Any of the neat uses of obfuscation involve the obfuscation being established by a trusted party), but I'm not aware of these systems being put into production. One reason for this may be because theoreticians find trusted initialization to be more acceptable than practitioners do— the theoreticians just posit "A spherically honest cow in random-oracle derived motion faithfully creates the parameters", the practitioners are the ones that have to figure out how to approximate the spherical cow using three chickens, a reed-solomon code, and a priest.

Funny, I've seen similar disinformation published before— that person was unwilling (unable) to substantiate it— can you do better?   The comments I made on Zerocoin were, I think, reasonably positive— but at the same time the system as it was wasn't suitable for deployment, and was later replaced by a complete reboot with much better performance (also evidence by the fact that no altcoin has deployed it, though they made a nice implementation of the cryptosystem available). I don't think there was anything hostile there, I've spent time with the developers of it and I think they're great guys, ... and I don't know any other developers who have been hostile about it either, so I'd really like to know what you're talking about.

This has really gone off-topic, but I thought leaving the FUD sitting around would be harmful.

We're aware of that and specifically designed to address that— at least to the extent that we easily can, there is a lot of room for improvement here. You cannot completely disconnect tor peers using the attack they described because we use tor in two distinct ways:  One way is that we use tor via exit nodes, which that attack addresses— the other is that we use tor via hidden services. If you set onlynet=tor your tor-enabled node uses only this second mechanism, otherwise it uses both. Inbound connections from hidden services, if you have enabled them, are exempted from banning. Some nodes are dual stack— they receive connections via both IPv4 and tor hidden services, and thus act as bridges between the tor and non-tor hosts even if no tor exits are working.

It may well be the case that you could actually break Bitcoin on tor by also DOS attacking the HS-accepting hosts, since there aren't enough of them, and the defense above works in part because some of the existing DOS protections are disabled for HS peers so HS accepting nodes are more DOS vulnerable— though it might also be the case that you'd just break the tor network first, and there isn't much we can do about that.

Last year I proposed a novel approach using asymmetric storage costs to discourage hosts from connecting out to many peers concurrently, though since there have been no attacks (at least none that have risen to a sufficient level of irritation) there hasn't been a lot of interest in developing the idea further. Basically the idea has the outbound connecting host do a moderate amount of POW to precompute a table per peer they are connecting to that allows them to rapidly answer queries that the remote peer can efficiently compute (without storage), the remote peer continually challenges them, so that they must either constantly be doing a ton of POW work, or retain a fair amount of storage per peer.  I'd envisioned this to be an optional thing peers could signal at their connection time ("I'm willing to use up to 1GB storage to get priority access"). All of these "make connections costly" approaches open new attack avenues, however— e.g. what happens when you start a lot of useless nodes for the purpose of just making peers waste effort to connect? The best answer I had is that nodes would only perform the costly work to secure their connections with a small number of their 'favorite' peers (e.g. randomly selected peers which have proven themselves to be helpful in the past), but this only requires the attacker to make their misbehaving nodes good for a while before they start misbehaving. Using sustained local storage as the costly thing instead of one time POW has the useful property that the storage can be freed if a peer stops being useful, but sadly my approach still requires the initial setup be somewhat computationally expensive or otherwise an attacker can skip the storage and just redo the setup for every challenge.

WRT topology, we've worked to keep the wiring random in order to make the topology likely to be an expander graph. Concern about not screwing up the topology is why we don't yet have peer rotation— the first and most obvious way to do it that I came up with broke the topology in simulation (resulted in clustering that had a smallish min-cut). I'm reasonably confident that I know ways that won't, but it's always scary to change something which is hard to analyze.