Nxt Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.14 - Latest Ardor Client: Ardor 2.0.14

Pages: 1 2 3 [4] 5 6 ... 8  All

Author Topic: A longer reply to Jeff Garzik  (Read 16460 times)

ChuckOne

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 3450
  • ☕ NXT-4BTE-8Y4K-CDS2-6TB82
    • View Profile
  • Karma: +293/-17
Re: A longer reply to Jeff Garzik
September 16, 2014, 05:49:34 pm

Because we devs trust each other.

Hehe, actually no. I check the diff before entering my passphrase into new version of NRS (which is, of coz, compiled by me). :)

Oh sorry. I was only speaking for me. ;)

Come-from-Beyond

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 4013
    • View Profile
  • Karma: +794/-671
Re: A longer reply to Jeff Garzik
September 16, 2014, 05:53:29 pm

You have still not explained why or how it is bad practice. Saying it is bad practice over and over does not make it true. Get off your high horse and eli5 to us peons what is actually so bad about it?

Crypto... Trust... Don't u hear a dissonance when pronounce these 2 words one after another?

jl777

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 6170
    • View Profile
  • Karma: +718/-123
Re: A longer reply to Jeff Garzik
September 16, 2014, 05:54:05 pm

I really want to hear what @jl777 has to say about all this.
I am just a simple C programmer so I will defer to CfB's judgement on things regarding Java

As far as human nature goes, I can make the comment that any process where there are people who are supposed to be reviewing thousands of lines of code before each release, well I dont believe they would pay much attention after their first few times. So, we would end up in a situation where the public gets a false sense of security.

I am having a hard time finding anybody I can pay money to for reviewing my code and that is just for the first critical review. Just exactly what type of person will want to review 20 releases per year?

James
There are over 1000 people in SuperNET slack! http://slackinvite.supernet.org/ automatically sends you an invite

I am just a simple C programmer

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:00:42 pm

You have still not explained why or how it is bad practice. Saying it is bad practice over and over does not make it true. Get off your high horse and eli5 to us peons what is actually so bad about it?

Crypto... Trust... Don't u hear a dissonance when pronounce these 2 words one after another?

Ok, but we are currently trusting JL so I don't get your point. We are also trusting that he hasn't been compromised. Something multiple signatures would prevent.

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:02:24 pm

I really want to hear what @jl777 has to say about all this.
I am just a simple C programmer so I will defer to CfB's judgement on things regarding Java

As far as human nature goes, I can make the comment that any process where there are people who are supposed to be reviewing thousands of lines of code before each release, well I dont believe they would pay much attention after their first few times. So, we would end up in a situation where the public gets a false sense of security.

I am having a hard time finding anybody I can pay money to for reviewing my code and that is just for the first critical review. Just exactly what type of person will want to review 20 releases per year?

James

All you need to do is confirm a build hash matches the hash that is published for release and then sign. Not review every single line.

Dunster

  • Full Member
  • ***
  • Offline Offline
  • Posts: 247
    • View Profile
  • Karma: +35/-27
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:03:25 pm

I guess Garzik is getting a bit worried that his Atlas Fawkes dreams are at risk.

Quote
Atlas Fawkes, a man who spent much of his youth mining for Bitcoins and enthusing about them to the amusement of his friends. The tables turn when an "extraordinary turn of events" in the year 2019 leads to Bitcoin being the only viable global currency, leaving Fawkes the richest man on earth.

Come-from-Beyond

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 4013
    • View Profile
  • Karma: +794/-671
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:04:11 pm

Ok, but we are currently trusting JL so I don't get your point. We are also trusting that he hasn't been compromised. Something multiple signatures would prevent.

Hm, is it an endless loop? Multiple signatures is a road to hell. Just read http://nakamotoinstitute.org/trusted-third-parties/

Edit: Here is a good quote from that document:
Quote
Often the protocol designer can't figure out how to fix a vulnerability. If the attack one needs a TTP to protect against is not a serious real-world threat in the context of the application the designer is trying to secure, it is better to simply leave the small hole unplugged than to assign the task to a TTP [Trusted Third Parties].
« Last Edit: September 16, 2014, 06:06:49 pm by Come-from-Beyond »

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:06:02 pm

Ok, but we are currently trusting JL so I don't get your point. We are also trusting that he hasn't been compromised. Something multiple signatures would prevent.

Hm, is it an endless loop? Multiple signatures is a road to hell. Just read http://nakamotoinstitute.org/trusted-third-parties/

Mine as well take down the multigateway then - it offers nothing over a centralized exchange. We don't need blockchains either. Let's just use a centralized bank.  Group consensus is useless.

I'll have to read that tonight.
« Last Edit: September 16, 2014, 06:11:49 pm by _mr_e »

Sebastien256

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2818
  • ^LOOK UP^ = Nxt community!
    • View Profile
  • Karma: +169/-24
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:07:22 pm

As long as JLP has a high stake in NXT. I do trust him.
Please drop your ideas concerning Nxt and/or NRS in this topic -> List of feature request for Nxt and/or NRS (with the full list in OP).

Damelon

  • Administrator
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 2314
    • View Profile
    • Nxt Inside
  • Karma: +792/-54
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:07:49 pm

I can see how "trust" and "crypto" sound weird in one sentence.

However, I feel the reasoning is flawed when it is implied that trusting say 5 people is the same as trusting one person.

Collusion becomes harder once more people are involved. Unless a person suffers from a serious case of MPD collusion with oneself is easy.

The reasoning "If we cannot do it perfectly, then we might as well not do it at all" is also flawed. "A world with the money cannot be perfect".

This goes for monetary systems ánd crypto systems. Making it less easy to take advantage of a position seems desirable, if it's possible.

If it's relatively easy and would allow us to be more trustworthy, why not do it. If it's bad practice to trust a group of people, surely it's also bad practice to trust one.

Or is your resistance to it more on a philosophical level: "One should not give people a false sense of security, because trust in people is inherently gameable"?

Edit: going to read that article by Szabo to be able to speak at sufficient level about the topic. Apologies in advance if I am making dense observations.
Member of the Nxt Foundation | Donations: NXT-D6K7-MLY6-98FM-FLL5T
Join Nxt Slack! https://nxtchat.herokuapp.com/
Founder of Blockchain Workspace | Personal Site & Blog

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:08:27 pm

As long as JLP has a high stake in NXT. I do trust him.

As do I. But trusting that him or his machine isn't threatened/compromised is another story.

chanc3r

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1019
  • NXTInspect
    • View Profile
  • Karma: +124/-50
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:11:15 pm

what we need surely is consensus as to what the correct version of NRS is - as we don't want to have to trust? ???

how about everyone understands how to get the hash of the NXT.jar they are using.
submit it as an AM to an account ? include the NXT version in the AM
people can then either check manually or all the block explorers can adapt to provide a function to show the correlation between the hash you are using and he hash others are submitting.

problem is if I were hacking NXT its a lot easier to put the hack in the javascript client not NXT.jar so all this talk about funky java builds is a bit academic....
NXT: 29996814460165 (NXT-JTA7-B2QR-8BFC-2V222)
@imrimr @NXTinspect

Come-from-Beyond

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 4013
    • View Profile
  • Karma: +794/-671
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:12:59 pm

Collusion becomes harder once more people are involved.

Hehe, u have just explained how Ripple's consensus works. It's funny that Bitcoin devs/users attacked Ripple for usage of exactly same approach that is used in "securing" Bitcoin core software. Double standards in their best manifestation.

ThomasVeil

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1397
    • View Profile
  • Karma: +183/-11
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:22:13 pm

Wait - can't anyone who doesn't trust, just compile themselves? Solution found. Or am I missing something here?

That NXT gets a Bitcoin core dev to behave like a troll (even if he would be correct on the technical issue), could be seen as a seal of approval for NXT. Maybe the consistently dropping BTC price makes them nervous.

Nassim Taleb uses to say that only once you have enemies you know you're doing the right thing.
NXT-BPV3-837M-QZTQ-9DQ69  oxpal.com

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:24:30 pm

Wait - can't anyone who doesn't trust, just compile themselves? Solution found. Or am I missing something here?.

Again, majority of users are not going to do that. Let's be real here. And when something nasty does happen the entire community is going to pay the price.

Jean-Luc

  • Core Dev
  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1610
    • View Profile
  • Karma: +816/-81
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:24:50 pm

Try this:

Download and unzip nxt-client-1.2.8.zip.

cd nxt
jar xvf nxt.jar
mv nxt nxt-orig
rm -f nxt.jar
./compile.sh
jar xvf nxt.jar
diff -r nxt nxt-orig

If you don't see a difference, this means the class files contained in the nxt.jar file included in the nxt-client-1.2.8.zip package (now under nxt-orig) are exactly the same as those produced when compiling the jar file yourself, under nxt.

The reason for non-reproducible builds is that the jar packaging tool includes time dependent information in the jar archive, which depends not only on the timestamps of the class files being packaged but the time the package is built too.

Different javac compilers and on different platforms may also result in different class files. I am using the 64-bit Oracle JDK for Linux, my current javac version is:

$ javac -version
javac 1.7.0_67

GPG key fingerprint: 263A 9EB0 29CF C77A 3D06  FD13 811D 6940 E1E4 240C
NXT-X4LF-9A4G-WN9Z-2R322

gs02xzz

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1101
    • View Profile
  • Karma: +56/-12
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:25:21 pm

I think actually we do have a group of very motivated volunteer devs to check out the source code each time after the release. They would also report any issues if found. They are those devs of Nxt clones - NAS, NFD, N2, NTX,..
Nxt Mission is to commercialize the crypto technology and build new commerce and society.

Come-from-Beyond

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 4013
    • View Profile
  • Karma: +794/-671
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:25:39 pm

Wait - can't anyone who doesn't trust, just compile themselves? Solution found. Or am I missing something here?

That NXT gets a Bitcoin core dev to behave like a troll (even if he would be correct on the technical issue), could be seen as a seal of approval for NXT. Maybe the consistently dropping BTC price makes them nervous.

Nassim Taleb uses to say that only once you have enemies you know you're doing the right thing.

Maybe Jeff wants to buy cheap NXT? :) After the conference in China the price can rise much.

ZeroTheGreat

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 29
    • View Profile
  • Karma: +3/-0
Thread: A longer reply to Jeff Garzik
September 16, 2014, 06:27:06 pm

How is it bad practice?
Cos cryptouser ultimately had to be supersuspicous (read changelog; later learn and read actual code changes before install any new code such powerful as cryptocur-client) and don't have things like auto-updating of code and bank services. Or what's the point? Use fiat and trust.

More trustless — better. Multisig actually making it less trustless, cos instead of suspecting dev (what u'd do) u'll start to trust those several signers to do it for ya.

_mr_e

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 956
    • View Profile
  • Karma: +88/-18
Re: A longer reply to Jeff Garzik
September 16, 2014, 06:28:55 pm

Try this:

Download and unzip nxt-client-1.2.8.zip.

cd nxt
jar xvf nxt.jar
mv nxt nxt-orig
rm -f nxt.jar
./compile.sh
jar xvf nxt.jar
diff -r nxt nxt-orig

If you don't see a difference, this means the class files contained in the nxt.jar file included in the nxt-client-1.2.8.zip package (now under nxt-orig) are exactly the same as those produced when compiling the jar file yourself, under nxt.

The reason for non-reproducible builds is that the jar packaging tool includes time dependent information in the jar archive, which depends not only on the timestamps of the class files being packaged but the time the package is built too.

Different javac compilers and on different platforms may also result in different class files. I am using the 64-bit Oracle JDK for Linux, my current javac version is:

$ javac -version
javac 1.7.0_67

Well finally.... at least an actual explanation. So then the question is, is there ANYTHING that can be done to lower the risk of compromised builds being published? What even is the current process of making a new release?
Pages: 1 2 3 [4] 5 6 ... 8  All