I'm dumping Nxt and here's why you should too

[inBitweTrust]

Funny that you don't have to cite articles with scientific proof when you raise your concerns that to having known devs is better than having anon devs  

All your facts are subjective at best. It's not clear how they contribute to "to have known devs is better than anon devs"

Scientific proof was not requested, what I asked for was much lower bar.

When an comparative analysis cannot be made than I refer you to refuting my original statements with logical rebuttals.

subjective. If he was not a liberal statist you would trust him and not be on guard?

No, being a paranoid developer, I would trust no one but knowing the motivations, background, and politics of fellow devs allows me to focus and scrutinize certain aspects of others work more which is helpful whether it involves watching for malicious code or simple being on guard for potential bugs when someone contributes code out of their area of expertise. To expect a full and complete security audit with every change is unrealistic.

BULLSHIT. Code quality is the most important criterion of a dev. Nice try evading an argument.

Did I ever state otherwise?

But the best is, we have known devs, but since some of them are anon, it's all bad, right?  

another false dichotomy.

[inBitweTrust]

Now you see why a claim that "non-anon" devs are better is a nonsense. If Nxt had 1000 devs then laws of statistics could be applied (even if your claim was true), Nxt has only 3 anon devs and anyone claiming that it lowers quality of the code says a silly thing, statistics simply doesn't work for small numbers.

First of all, what is the truth 33.3% anonymous devs or 66.66% anonymous devs?

Anon Devs: we have around 9 core (ish) devs, 3 of whom are non-anonymous.
Not perfect, but, hey, it's crypto.

Secondly, you are presenting a false dichotomy again. Anonymous devs are fine, but with Fintech the majority of core devs and the project maintainer should be transparent.

I was thinking about excatly that all the time! It's quite subtle. (not pretending that my arguments are flawless)

Perhaps its nuanced because I am more interested in the truth and am open to admitting where I am wrong (like I have done multiple times).

Nxt was open-source since day 0. Unobfuscated Java binary = source code. Google around and you will find several repositories with decompiled source code. It repeats the original source code with 99% matching (the rest 1% is caused by empty lines).

While not entirely true, I agree that this attack was over-reaching because it isn't fair comparing the transparency of the development process of Bitcoin (in this context) with NxT. Bitcoin has already enough of a network effect where it doesn't need to worry so much about clones ripping off their code. Nxt had good reasons to with-hold code and still has good reasons not to show all in development in progress. I can see this is slowly changing as well with NxT growing.
The true shift is if or when many merchants start using NxT so it could start to transform from being mostly a speculative instrument to a useful one. At this point NxT devs should be more comfortable showing unreleased code.

[Come-from-Beyond]

First of all, what is the truth 33.3% anonymous devs or 66.66% anonymous devs?

I don't know exact numbers, only 3 devs were anonymous and I saw somewhere that Nxt had 9 devs. Let's assume that there are only 3 devs and all of them are anonymous. What does it change?

[inBitweTrust]

First of all, what is the truth 33.3% anonymous devs or 66.66% anonymous devs?

I don't know exact numbers, only 3 devs were anonymous and I saw somewhere that Nxt had 9 devs. Let's assume that there are only 3 devs and all of them are anonymous. What does it change?

Doesn't change anything, NxT should still be less trusted than Bitcoin, and specifically because it has a mostly anonymous dev team and core maintainer(one reason amongst others). There should be higher standards with FinTech because you are dealing with peoples life savings. Bitcoin still needs a lot of work before I can suggest people use it 100%. NxT is in a completely different category of risk.

If Gavin commits some malicious code to steal bitcoin's in the next core release we can go after him. If Jean-Luc does this with NxT than finding him will be more difficult. It is the same reason I warn people to not deposit any funds in Bitcoin banks and exchanges with anonymous owners. Huge red flag!

Additionally, bitcoin developer have social consequences if they make mistakes, their real reputation is on the line, not some pseudonym reputation. There is a day and night difference between the two.... and frankly me having to be so explicit with what should be obvious is a little disconcerting.

You cannot hide behind the fact that the source code is included within each release and the responsibility lies within the user to do audits and compile from source. That isn't realistic for 99.9% of users.

[achimsmile]

BULLSHIT. Code quality is the most important criterion of a dev. Nice try evading an argument.

Did I ever state otherwise?

Yes, looks so to me:

the background of the developers can give us some understanding of their technical proficiency -> So does the quality of the code they write

Yes, I agree with this in a utopian fantasy developer world. Completely, ignoring reality, and my previous comments.

So you agree in an utopian fantasy world AND in the real world?

[Come-from-Beyond]

If Gavin commits some malicious code to steal bitcoin's in the next core release we can go after him.

No, he will say that the key was compromised and he didn't know about that.

[inBitweTrust]

So you agree in an utopian fantasy world AND in the real world?

No, I agree with you conceptually if that reality existed, but it doesn't.

Well, so what happened to Mark Karpeles aka CEO of Mt.GOX ? He is still a free man and no one is going to lynch him ? Good that we know him right...

First of all, the legal system of the state is usually slow and inept at bringing justice. The investigators just released their preliminary reports and he still might find jail time.

Secondly, regardless if the state is effectual or not there is a another type of justice which is immediately brought to light with frauds like Josh Garza and Mark Karpeles. They have to hire body guards , they have to spend a lot of resources and forever fear that retribution will be around the corner, they are socially ostracized, they will have a really hard time with any future business pursuits or contracts. Their credibility is shot.

With a pseudonym you aren't putting much on the line. Once you commit the fraud or fuck up , you can just create a new persona. Do you really believe that there are separate dev teams for all 700+ pump and dump scamcoins ? No, of course not, there are anonymous devs recreating new scams and ponzis when the last one folds all the time.

If Gavin commits some malicious code to steal bitcoin's in the next core release we can go after him.

No, he will say that the key was compromised and he didn't know about that.

Than we can scrutinize and investigate to validate. Additionally, that was one of the original criticisms of NxT that Jeff mentioned-

“What is necessary, for NXT or any other crypto-finance software, is to prove independent reproducibility. The next step is to proactively have developers and community members cross-check each other, to make sure the build produced is the same for all. This helps ensure that the release manager is not under duress, unknowingly infected with malware, or corrupt. No security solution is perfect, but it raises the bar significantly. You should never trust just one person to produce release binaries, in any crypto-finance project.  That’s called a Single Point of Failure, and it is easy to attack such a narrow victim vector.”

https://www.cryptocoinsnews.com/bitcoin-core-developer-jeff-garzik-believes-nxt-is-a-scamcoin/

NxT has a single point of failure , while the bitcoin core team cross checks each other with each build. Additionally, Bitcoin has multiple implementations interacting with the blockchain, so you don't even have to trust Gavin or the rest of the core team.

What I have noticed you doing repeatedly is making a shifting the sands or moving the goal posts logic fallacy by repeatedly discussing flaws or weaknesses within the improvements we are suggesting instead of realizing what any security researcher knows that nothing is 100% secure and we can only make attempts at increasing the levels of security.

[Come-from-Beyond]

Than we can scrutinize and investigate to validate. Additionally, that was one of the original criticisms of NxT that Jeff mentioned-

After the damage is done? Not very smart.

“What is necessary, for NXT or any other crypto-finance software, is to prove independent reproducibility. The next step is to proactively have developers and community members cross-check each other, to make sure the build produced is the same for all. This helps ensure that the release manager is not under duress, unknowingly infected with malware, or corrupt. No security solution is perfect, but it raises the bar significantly. You should never trust just one person to produce release binaries, in any crypto-finance project.  That’s called a Single Point of Failure, and it is easy to attack such a narrow victim vector.”

[/quote]

Why reproducibility is required?

[inBitweTrust]

After the damage is done? Not very smart.

Its being done before and after. Are you suggesting there is no value in investigating mistakes or crimes after they happen?

Why reproducibility is required?

That is one method, amongst many, in our tool chest for auditing code.

[achimsmile]

So you agree in an utopian fantasy world AND in the real world?

No, I agree with you conceptually if that reality existed, but it doesn't.

Sorry for playing games with you, but now I can conclude that you don't agree in the real world to this bold part

the background of the developers can give us some understanding of their technical proficiency -> So does the quality of the code they write

This means you agree to this:

the quality of the code of the developers can not give us some understanding of their technical proficiency in the real world

which is pretty bold

[Come-from-Beyond]

Its being done before and after. Are you suggesting there is no value in investigating mistakes or crimes after they happen?

People think that a non-anon dev won't try to scam them and in the end we get an insecure system.

That is one method, amongst many, in our tool chest for auditing code.

Java code doesn't need reproducibility. Jeff showed that he understands nothing in Java, this automatically reduces value of his advice to zero.

[inBitweTrust]

So you agree in an utopian fantasy world AND in the real world?

No, I agree with you conceptually if that reality existed, but it doesn't.

Sorry for playing games with you, but now I can conclude that you don't agree in the real world to this bold part

the background of the developers can give us some understanding of their technical proficiency -> So does the quality of the code they write

This means you agree to this:

the quality of the code of the developers can not give us some understanding of their technical proficiency in the real world

which is pretty bold

I don't understand why this is so complicated for you to understand.

It would be great and ideal if everyone compiled from source and performed security audits with every version.
In reality, this doesn't happen, even if 100% of the users are capable of this task. Thus we have to implement other means and layers of security to bolster up the inadequacies of the end user security.

Understand?

[Come-from-Beyond]

It would be great and ideal if everyone compiled from source and performed security audits with every version.

You are wrong if you rely on audit of the others (as was suggested by Jeff). If you want to know why, just read Trusted Third Parties Are Security Holes by Nick Szabo.

[achimsmile]

So you agree in an utopian fantasy world AND in the real world?

No, I agree with you conceptually if that reality existed, but it doesn't.

Sorry for playing games with you, but now I can conclude that you don't agree in the real world to this bold part

the background of the developers can give us some understanding of their technical proficiency -> So does the quality of the code they write

This means you agree to this:

the quality of the code of the developers can not give us some understanding of their technical proficiency in the real world

which is pretty bold

I don't understand why this is so complicated for you to understand.

It would be great and ideal if everyone compiled from source and performed security audits with every version.
In reality, this doesn't happen, even if 100% of the users are capable of this task. Thus we have to implement other means and layers of security to bolster up the inadequacies of the end user security.

Understand?

I understand you, but I'm not sure that trusting a dev because he is known is a good layer of security.

[Come-from-Beyond]

I understand you, but I'm not sure that trusting a dev because he is known is a good layer of security.

It's not and Nick Szabo explains why. Bottom line of the current discussion is already obvious: non-anon devs is bad because people trust them.

[inBitweTrust]

People think that a non-anon dev won't try to scam them and in the end we get an insecure system.

So your logic is that it is best to act shady as hell to insure that your potential users are sufficiently paranoid and perform more audits? Or is their some special degree of heightened paranoia you deliberately try to instill with your users to add greater security? I assume this fringe benefit outweighs all the advantages of transparency, Really???

Java code doesn't need reproducibility. Jeff showed that he understands nothing in Java, this automatically reduces value of his advice to zero.

With regards to reproducibility, there are many different things we could be discussing here but I will take a stab at what I think you are referring to and why Jeff is still right:

Yes, I understand using separate compilers on different platforms can result in different class files. wouldn't it be a good idea, since you are working with Java, that you coordinate and use the same platform and compiler to create a deterministic jar so you can have the added benefit of reproducibility and verification?

[inBitweTrust]

It would be great and ideal if everyone compiled from source and performed security audits with every version.

You are wrong if you rely on audit of the others (as was suggested by Jeff). If you want to know why, just read Trusted Third Parties Are Security Holes by Nick Szabo.

We shouldn't rely on audits from others, but we are forced to in the real world. Don't tell me you do a thorough audit and compile from scratch every bit of open source code on your computer with every version. No one does that except Richard Stallman, and I am sure even he skips an audit or compile from source every now and again.

[Come-from-Beyond]

So your logic is that it is best to act shady as hell to insure that your potential users are sufficiently paranoid and perform more audits? Or is their some special degree of heightened paranoia you deliberately try to instill with your users to add greater security? I assume this fringe benefit outweighs all the advantages of transparency, Really???

No. Don't distort my position, just read what I wrote upthread.

With regards to reproducibility, there are many different things we could be discussing here but I will take a stab at what I think you are referring to and why Jeff is still right:

Yes, I understand using separate compilers on different platforms can result in different class files. wouldn't it be a good idea, since you are working with Java, that you coordinate and use the same platform and compiler to create a deterministic jar so you can have the added benefit of reproducibility and verification?

Deterministic jars give 0 (zero) benefit because decompiled binary can be compared to the code produced by compiling and decompiling source code.

[Come-from-Beyond]

We shouldn't rely on audits from others, but we are forced to in the real world. Don't tell me you do a thorough audit and compile from scratch every bit of open source code on your computer with every version. No one does that except Richard Stallman, and I am sure even he skips an audit or compile from source every now and again.

Blackbox testing, heuristic analysis... there are a lot of ways to do audit without making humans to read the code.

[inBitweTrust]

Deterministic jars give 0 (zero) benefit because decompiled binary can be compared to the code produced by compiling and decompiling source code.

Now you are conflating internal and external processes. Additionally, ignoring my repeated statement of fact that few people in the real world compile from scratch .

Allowing users the ability to confirm a hash is useful.