Liar.

http://www.youtube.com/watch?v=gsYT8YHL-R0

or

http://www.youtube.com/watch?v=LaVIIoRKBlk (starting at 5:30)

Who am I kidding, there isn't a single line Khan said that isn't pure gold.  

Sure because it works.  POW has been proven to work.  POS is more efficient and is "close" to working but requires significant centralized control (checkpointing) something which may be improved upon in future versions.  You keep talking about Ripple as if it works. It doesn't or at least it hasn't been shown/proven to work in an open network where some nodes are malicious.   

If it works then great but why not cross that bridge when (never) you get to it.  My belief is that Ripple will never work in an open psuedo-anonymous network.  So anyone planning to go that route is planning to build a closed source, central authority coin.  The good new is it will be very efficient.

This is why it is useful for you to have elementry level knowledge of how Bitcoin (and clones) work.  The reward to a miner IS PART OF THE BLOCK.  The miner has to know how much the reward is BEFORE they start looking for a block solution.

While this could be radically changed it would require a significant departure to how crypto-currencies work.  Plus any new idea would be untested and would need testing and peer review.  Can it be done possibly although it isn't going to be done for the ($40 ? ) you paid.  The amount you paid was worthy of a clone scamcoin and it was exactly what you got.

To build a new crypto-currency based on novel new concepts?  We are talking hundreds of hours.  It would be rather stupid to do all that for something as gimmicky and useless and random blocks.

The base unit is hash/second

We don't use a special name for Kilowatts or Megawatts, it is just a prefix (i.e. Kilowatt = 1000 watts) and the base units watts.

What client are you using?  The tx is "low priority" however the included fee (0.01 mBTC) which is smaller than the min mandatory fee on low priority txs (0.1 mBTC).  The reference client should have prevented you from creating this transaction.  Most miners running default rules will ignore these transaction as denial of service attempts, in fact most nodes will refuse to even relay this transaction for the same reason.

I have never got a satisfactory answer.  I will point out that it is intentional though.  The default parameters for Scrypt are (N=2^14, r=8, p=1), the parameters used by Litecoin are N=2^10, r=1, p=1).

I am not sure if was a scam but the end result is the same, Litecoin is 99% less memory hard then the default Scrypt and about 1/7000th as memory hard as the parameters recommended by the author for high security (not realtime) applications.

AFAIK the constants merely need to be psuedo-random values.  Using truly random values would provide security but wouldn't provide transparency (are those randoms really random).  The use of squares/cubes of primes is soley to be a "nothing up my sleeve number".  It could have been first 240 digits of Pi instead or a sequence of true random numbers based on radioactive decay or quantum RNG.

If the constants aren't randomly distributed it could undermine the security of the algorithm.

You lost me here.


We are relying on the fact that the constants are psuedo random.  Any 49 truly random constants would be equally secure however the issue with that is if NIST provided you a list of 32 bit numbers they "randomly" generated would you trust them?  Essentially trust of SHA-2 would hinge on trust of NIST. If the constants are random then the algorithm is trusted and if they are not then it may hide a flaw.  Given that that randomness of the constants could never be proven it presents an interesting problem to public adoption.

The use of first 32 bits of square and cube root sequential primes is merely a method to introduce entropy into the algorithm.  We aren't relying on any specific property of square and cube roots merely that no exploitable relationship exists.  As for proving that, I doubt believe that is possible. 

Well that is the point of "nothing up my sleeve numbers" it simplifies the crypto-analysis.  Rather than try to determine if there is any special relationship between 72 seemingly random constants, the use of sequential primes simplifies the question to is there any special relationship between the square and cube roots of a set of sequential primes that would undermine this algorithm.  

Granted both questions are well beyond my capabilities however the later question is a far simpler question if only in scope.    The quick detection of the flaw (intentional backoor) in another cryptographic system, by the international community provides a level of assurance.   SHA-2 has been extensively studied for the better part of a decade being the prominent hashing algorithm in a variety of applications.  Finding a flaw (intentional or otherwise) in one of the (if not the) most widely used hashing function is a huge deal for cryptographers.  Any lack of evidence to a special relationship certainly isn't due to a lack of trying.  When you compare the speed at which flaws were found in Dual_EC_DRBG and consider that is a far less know/used algorithm than SHA-2 it would have to be an amazingly well hidden backdoor.

Why so you keep referencing "elliptical curve"? SHA (or any hashing algorithm) has nothing to do with Eliptical Curve Cryptography. I misread the statement.

No numbers are repeated.  The first set of constants are the first 32 bits of the SQUARE ROOTS and the second set of constants are the first 32 bits of the CUBE ROOTS.  Cryptographic functions often need some set of constant values.  It becomes difficult to prove after the fact that a claimed random set of constant values don't hide malicious intent which is why most functions use a concept called "nothing up my sleeve numbers".  

http://en.wikipedia.org/wiki/Nothing_up_my_sleeve_number

If SHA-256 uses a set of 48 "random" values I might be inclined to agree, at best it would be very difficult to prove there was not some unknown relationship between the numbers.  However SHA-256 uses the square root and cube roots of sequential primes which provides cryptographers a reference point rather than obscuring any potential weakness with a claim of "randomly chosen constants".


As for the use of various right and shift lengths.  That is the cross mixing function.  It is going to be difficult to "prove" that these numbers have no special significance.  Then again if they were 9 17 3 19 13 11 instead of 7 18 3 17 19 10 would that make you feel more secure?  I would imagine not. There possibly is a very large set of shift lengths which would work equally well however a single set is necessary.  It probably didn't need to be 7 18 3 17 19 10 but it needed to be something.

As for your final question can the algorithm be mathematically proven to be secure.  The answer is no.  AFAIK there is no hashing algorithm which is proven to be a one way function by any strict mathematical proof.
 

I think the latter.  In looking at the white paper, FAQ, and wiki there are some significant "issues" with their explanation of achieving consensus.  Of course it "might" work but the devil is in the details and being closed source there is no way to expose those details to sunlight.

So it is more like "trust us it works, the magic black box says so" and "at some point in the future which will not be named and may change at our sole decree" we will let untrusted people run servers because it won't be a problem.  If you have doubts see the first quote.


Well we don't know it works.  As described I see a lot of potential issues.

Just one example:


Ok so in the event two or more nodes (servers) disagree consensus will be acheived by a deterministic algorithm.  The conflicting transactions will be sorted by hash order and the included in order until tx can't be included due to conflict.

Ok so I am going to send you coins, I generate tx until I make one with a high tx hash.  I then double spend it with a tx to myself that happens to have a low tx hash.  If I can ensure that no consensus is acheived (partial sbyill) attack then the deterministic algorithm will always pick my double spend over your tx

As described this is a massive vulnerability, one sure to be exploited once the server source code is open sourced and anyone can run a server (or 10,000 servers in a botnet). Now maybe the FAQ is just incomplete but since the server source code is closed source nobody can say for sure how weak this is.

https://ripple.com/wiki/Consensus

Ok they are worse, however the OP question is "was WDC premined?".  The answer is yes.  The fact that there are worse coins in this respect some laughably idioticly worse doesn't change that answer.

I wouldn't say that.  Combined they all alt-coins other than BTC & LTC have <1% of the total CC marketcap. http://coinmarketcap.com/ Not really "successful" and beyond the top 4 or 5 it goes down rapidly.    Sure they have some non-zero value in the same way that pennies stocks usually never go to zero despite having no real value.  No doubt some people will be able to dump them on the "greater fool" but I wouldn't say the market has rewarded those coins for being successful with massive market share gains.

There is no preset time limit.  The node psuedo-randomly rebroadcasts transactions.  Your node has no method of knowing if other nodes are still retaining a copy of your unconfirmed tx, only that a tx is self created and has been broadcast.  It broadcasts the tx, and then wait, if it sees the tx in a block it removes it from its memory pool.  When a self generated tx in its memory pool becomes stale it broadcasts it again.  It is possible peers already know of that tx however it doesn't check it simply broadcasts the tx and refreshes its status in its memory pool.

Spamming a tx to all nodes continually until they appear in a block would use up a lot of network resources and that could be exploited by an attacker as camouflage to create a denial of service attack.  In other words if "well behaved" nodes are spammy then it becomes harder to identify and ban truly malicious nodes.  As it is right now actual malicious are easy to spot and ban.

Bitcoin is an open source project.  The rebroadcast algorithm can be improved so feel free to do a pull (or bounty for a pull).
Keep in mind however that:
a) an node has no method of knowing if an arbitrary unconfirmed tx is in the memory pool of peers without asking
b) when a node drops a tx from its memory pool either on receipt (invalid tx or insufficient fee) or when memory pool is full it does not notify the sending node.
c) a node should rebroadcast tx to peers on random intervals to avoid giving away information (i.e. your node sends the same tx every 1 minute to all 8 peers an a malicious entity is two of your peers you have essentially identified yourself as the originator)
d) the volume of communication should not make it possible for a malicious node to use that as cover to spam the network.

I would call it a distributed centralaised ledger.  This may seem an oxymoron but the point is that there is a redundant network of ripple "servers" (not be be confused with client nodes) however the server source code remains closed source and only OpenCoin or agents of OpenCoin run the servers.

I would liken in to a private content distribution system being distributed but still under centralized control.  The advantages are no need for mining, no need for proof of work.  What the centralized network says is the status of coins is the status with no appeals or overrides.

There is no need for "proof" because all servers are trusted authorities.  They are all run by the same entity and there is no reason or scenario where they will provide conflicting ledgers.   At a high level one could say the purpose of "proof of work/stake/etc" is to resolve conflicts in the consensus.  There will never be conflicts in a distributed centralized network.

1) Because the amount of EXISTING pre-orders are is already more than that. 

2) The margins on ASICs are still very high so once sales slow down to a trickle because annual ROI drops to something pathetic like 20% per year, the producers can cut the price by 50% and sell even more, then cut the price by another 50% and sell even more and by then have the funds to finance smaller/faster/better/cheaper ASICs.

The lowest cost method is a centralized ledger.  That is the PayPal/Ripple/Federal Reserve method.  Securing a blockchain in a decentralized will always involve a cost.  Maybe it won't be an electrical cost, maybe it will be a different kind of cost but a cost is inevitable.

You wouldn't need 6GB.  The latency on main memory for a GPU is horribly bad so bad that any process which needs random access to GPU main memory will be annihilated by a CPU in terms of performance.  GPU memory is designed to stream textures and as such it couples massive bandwidth with extreme latency.  Scrypt was designed to fill the L3 cache of a CPU.  The developers of alt-coins had to intentionally lower the memory requirements by 99% to make GPU competitive.  Yes Litecoin and clones use about 128KB of cache.  The MINIMUM memory requirement for Scrypt is 12MB.  It doesn't take 16GB.  Try it out yourself or check out various hacking forums the OpenCL performance for Scrypt (2^14, 8, 1) is beyond pathetic.  A cheap CPU will run circles around it.  

Of course this makes it optimal for botnets so maybe a higher memory requirement (say 4GB/8GB) may be an idea so that it requires a relatively high end computer.  Scrypt is configurable you can make the scratchpad as large as you want (even up to TB of space required). It would be trivial for enthusiast to add more memory/disk but I imagine the average botnet node is a relatively weak/older system.  The % which have 4/8GB or more of main memory are probably small.  One could even design the algorithm to become more memory hard over time (i.e. double memory requirement every 2 block years).

Come on you really can't see a solution to that problem, like I don't know ...
a) don't launch at difficulty zero
b) make the first xxx blocks (where xx is more than difficulty adjustment period) worth 0 coins.
c) a & b

I mean really?  You act like it is an unavoidable situation.  Bitcoin launched at a difficulty 1 and hashpower was so low the network ran at 1/3 proper speed for most of the first year.  Given Bitcoin was the first CC to pretend every subsequent coin has no way to avoid difficulty 0 is just stupid.  No offense but it is.  Either a) you already know this and are just trying to create a smoke screen or b) you are a pump & dump best friend.

We haven't even caught UP to Moore's law.  Yes in 2-3 years when all units are available with 2-3 day delivery and the network is 40,000 TH/s+ then yes difficulty growth for a fixed exchange rate will slow to Moore's law but even then if the exchange rate goes up 5x expect difficulty to follow even with no improvement in efficiency. 

So difficulty won't increase 60% per month perpetually until the universe dies of heat death but depending on the amount of pre-orders, the improvement pace of future ASICs (until caught up to current process technology = 28nm), and the future exchange rate it can rise by a lot for a very very long time.    Anyone thinking difficulty will only go up 400% or 1000% and flatline is likely going to be poorer for that faulty logic.

It really depends on how much foolishly purchased pre-order hashing power has already been purchased.  Once ordered the hashpower will eventually be delivered causing the difficulty to keep rising long after new sales no longer make any sense due to negative ROI%.

A miner who has ALREADY bought has no reason to not mine because the purchase price is a sunk cost and difficulty would need to be > 6 billion before the electrical cost was greater than the mined coins (at current exchange rate).  So you "could" see this scenario were difficulty keeps rising and rising and rising and despite everyone saying "buying new rigs is stupid now" it keeps rising as ALREADY purchased rigs are slowly delivered.