heh, definitely loading the chain prior to launch.  That's part of the pre-flight tests in fact.

As revealed at June's Bitcoin Beltway conference, the BitSat satellites will carry the full blockchain, and fully validate every block sent to it.

This is in contrast with other systems that simply broadcast a datastream without validation, and therefore require much higher levels of trust than with BitSat.

An ad in USA Today's NASA special edition: http://imgur.com/RMdY7EM

Currently stuck in ITAR queue, waiting for US State Dept. to clear things which non-US people already known about and have access to...

Yes.  Quite serious.

Proof-of-Stake has serious problems, that must be mitigated.  Stakeholders in PoS control consensus.  That means they control what transactions may, or may not, be permitted into the chain.  They are the 100% gatekeepers to the chain.

If you have a tiny initial distribution -- just 8 people holding 40% of a certain coin for example, just 64 people getting the rest -- then the central bankers are in place, for life.  It is screwed from the start (unless, against their economic interests, the major stakeholders divest their stakes "fairly").

Proof-Of-Stake is fundamentally not permissionless.  In contrast, building a mining ASIC might be expensive, but it is doable to anyone in the world with a computer engineering background, and some money.  You don't need permission from existing bitcoin holders, to make more bitcoin.

Yes.  As I said,


It is important for the community to demand this of themselves.  The community must get into the habit of rigourously checking each release.  "Anyone can check for themselves" is not sufficient, because in practice, people are lazy and do not check before 10000x users have downloaded and run the new release.  Cross-check before massive download.  Anyone in the community can do this.  You do not have to be a developer.  The critical point is establish the habit, the process of protecting users with a cross-check prior to general release.

If you rely on after-the-fact checking, the release manager (NXT's Jean Luc?) could be infected with malware and be producing an infected jar.  Many users would be impacted, before the problem is noticed.

Set up processes to protect users.


Quite true on both points.

That's why the community must have a quick cross-check of the release manager's output before opening up to large numbers of downloads (and potentially infecting large numbers of users).

The software protects Real Money, people.  It must be held to strict security and accountability standards.  For any project, bitcoin, NXT or anything crypto-finance, you must be able to (a) prove the developers are not backdoor'ing you, by reviewing source code + checking build output, and (b) fire the developers (by forking) if they add something unexpected that the user base dislikes.

Reading "I trust JLP!" posts on the NXT forum just makes for one big facepalm.  The processes should be in place so that the community doesn't have to trust.

To repeat for the cheap seats:  Wrong.  This is irrelevant, because the majority of users do not do this.  The majority of users just run the pre-built jar (which is what the NXT readme instructs them to do anyway).

A reproducible build process is helpful because...


And on to,


Closed dev process.  As I noted the source code snapshot is published, but not live commits and open feedback/criticism like normal open source projects.  NXT is ivory tower.

Apparently the project has bounced between open and closed source at least once.

Why?  Because there are plenty of red flags.

• It is marketed like a scammy penny stock.
• Anon early super large stakeholders + Proof-Of-Stake == the big guys run the table, if they choose. https://download.wpsoftware.net/bitcoin/pos.pdf  The central bankers are in place from Day One unless they are super-virtuous and give tons away "fairly."
• Anon devs
• Closed dev process.  Source is periodically handed down from the ivory tower to the masses.
• Certain notable personages (& key stakeholders) that dodge, dodge, dodge, when an obvious attack vector -- mitigated in other crypto-finance projects by known techniques -- is highlighted.
• Active resistance to making it easier to independently reproduce the software
• Technical criticism is routinely met with bizarre behavior (notably from come-from-beyond)
• Attacking critics, rather than responding to criticism.
• Several security incidents that smell like inside jobs.

This is not something in the past 48 hours, but for the lifetime of the project.

Bitcoin has large stakeholders and large miners, sure, but the two sets are different.  This separation ensures an easier flow of stakeholders and miners in and out of the system, and serves as a bit of check-and-balance between the two groups.

Proof-of-Stake makes it easier to establish a system where early guys control the system, for life.  I'm not saying that is always the case with PoS; that's just how pure-PoS systems can shake out in the field.  Thus, it is easier for PoS to be "gamed" by insiders.  This is inherently, logically true because there are no externalities (electricity, heat) that serve as friction in the process.

In a perfect pure ideal honest world, NXT should reset the chain and develop fully in the open, with provable builds and a better early stake allocation that pays attention to the Central Banker Controls The Timeline Problem.  More honest projects these days run a test chain for months, and then launch once most problems are hammered out, and constructive criticism from the tech community has been incorporated.

I do think PoS has a place in this world... a mixed PoW & PoS system is very interesting.  PoS alone presents a completely enclosed system, where stakeholders are far too integral to the core process of choosing which transactions are to be accepted into the chain.

Remember (from your bitcoin mining classes if nothing else), those who choose what goes into the chain also choose what stays out (censor).  He who controls the timeline controls the universe, to paraphrase Dune.

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 when multiple parties verify the build.

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.

Simplified example:

Step 1: Similar to the blockchain, git records the hash of the latest commit... and a commit includes the hash(es) of previous commits.  That creates a chain of hashes for the source code.

Step 2: Given the git commit id (a hash), obtain a source code tree.

Step 3: Compile the source code, resulting in one or more binaries (bytecode output, in Java's case).

Step 4: Hash the binaries

Step 5: Post a PGP-signed message containing the hash from step #4.

Just like in biology or chemistry, it is critical that the above process is independently reproducible and yields the same result every time.

If multiple developers perform these steps, and all result in the same hashes in step #4, then you eliminate a Man-In-The-Middle attack where an evil developer or evil malware may insert a backdoor not present in the source code, but present in the binaries that users download and trust with real money.

Finally, at any time, any outside developer may independently reproduce this process, proving that the dev team is not inserting backdoors etc.

Deterministic builds are critical for any software you trust with money.

This is how Bitcoin Core handles every release.  Multiple developers must achieve the same compiled result, or no release happens.  We use https://gitian.org/ to assist with this.

Point missed completely.

The vast majority of users simply download and run code.  They do not compile it.  A deterministic build process enables any random outsider, at any time, to prove that the given source code compiles to binary (or byte) code that matches exactly, byte-for-byte with what is produced by the official release team.

"Anyone can compile" is irrelevant.  What is relevant is that you can prove the release team binaries match the source code exactly.

An attacker may otherwise stuff a backdoor into the bytecode, but not the source code.  "Anyone can compile it" developers would never notice the backdoor... yet 99% of the users still have the backdoor.

Furthermore, you want a process like bitcoin's where multiple developers each produce a build, and PGP-sign the produced hashes.  In this way, you need not worry about a backdoor'd compiler producing evil bytecode without the developer's knowledge.

No.  Those hashes prove nothing.

A deterministic build process enables multiple independent parties to generate the exact same output, given a git commit id.

If you cannot prove what's in users hands is exactly what came out from the java->bytecode compiler, then you should not use that binary.

Plenty of people mention this.

The "headers-first" feature, hopefully in 0.10, fixes this issue.  With headers-first, the client will import much faster than torrent + import.

Utterly useless exercise, without hash proof.


Guess what?  It was a question.

It is notable when asking questions leading to paranoia and accusations rather than specific answers.

Byzantine threat modeling.

When creating a high level design, you must follow each data source to its provider, and consider how these data sources may be manipulated, to fool victims into seeing what the attacker wishes the victim to see.

I want to link my Bitcointalk name with BTCJam's. Verification code: 8d45da82-fe5e-4218-9878-63b7d72666c1

Always fun playing with a new service

Can you be more specific?  Which link is incorrect?

Not sure I understand the comment.

The lots are priced in USD.  The bitcoin price for the lots therefore continues to fall, which benefits the buyer without causing any bitcoin-related loss for the seller.

The USD price was reduced, but that has nothing to do with "Bitcoinland."  The OTP for Lot #11 that fell through was a local (USD)  buyer totally unaware of bitcoin's existence.  Lot #5 was sold to a local buyer.

Bump.  Lot #11 contract fell through (buyer couldn't get money together), so it is back on the market.

Price reduced!

Thanks for double-checking my work!