Most people (as in 99.999% of the planet and rising) have absolutely no idea how to configure a router.  There is a reason why just about all networked software uses upnp.  Now if you are a power user, or want complete control just disable upnp and config port forwarding manually.


Once again you massively overestimate the networking knowledge of "most people".  Most people if offered a $1,000 reward couldn't show you how to disable upnp on their own router.   When routers shipped with (paper weak security) WEP by default and WPA as an option the overwhelming majority of routers were never changed.  Hell most people wouldn't know how to configure a SSID or security key ("the wireless internet password") if it wasn't for wizards.   Most routers for home use now have windows install programs which find and configure the router because the concept of going to an IP address 192.168.0.1 results in too many tech support calls.

This +21 quadrillion.

RFC 6238 is a robust and peer reviewed standard.  There is absolutely no reason to roll your own.  Google auth isn't RFC 6238, Google Auth is an IMPLEMENTATION OF  rfc6238.  If you wanted to there may be value in making an independent implementation of the same standard.

i.e. you code and google's code given the same input would always produce the same values.

I mean the logic of rolling a new standard (a crypto one at that) would be like saying "I don't trust Verisign certs so I am going to roll my own alternative to SSL".  The obvious (at least to me) solution instead would be to keep using the robust and peer reviewed standard and making an ALTERNATIVE to Verisign.

That is the problem with a noob, non-miner, non-programmer "building" a coin.  He is completely wrong but he honestly doesn't know it.

This.  Also random block or not the expected reward over the long run remains proportional to hashpower so much for the revolutionary concept which will provide a bonus to small miners.  I had a feeling but I was hoping it would be something novel and interesting.

As gmaxwell indicated it doesn't really matter.  You can prune the tx in a block which are spent (it doesn't need to be all or nothing).  Regardless you need to keep the block header to validate the chain integrity.

This.  It would seem obvious (common sense but legal precedent) that while a state can regulate Money Tranmission within the state it can't regulate money transmission between the states.  That hasn't stopped 47ish states from passing regulations doing exactly that.  As stated above if you have $20M+ you are willing to light on fire and a willingness to spend years (if not a decade) you likely could fight it all the way up to the Supreme Court and have a 50/50 chance of getting state interference in interstate commerce overturned.

However lets game theory this for a second say you DID have $20M it would be faster and cheaper to just comply with the regs even if you 100% are sure they are Unconstitutional.  Why would you do that (i.e. why hasn't PayPal, ADP, etc fought MT regulations on the state level)?  Simple it creates a massive barrier to entry for future smaller more innovative competitors.

So TL/DR version the only entities with sufficient resources to fight this out are the exact entities which would do everything possible to ensure that never happens.

This would actually be awesome.  Where there are a hundred or so new coins every day then maybe people will get the idea that yet another coin doesn't really mean anything.

The funny thing is pretending 1% is small because it is a small number.  Lets take Bitcoin for example.  Say Satoshi had hardcoded a founder wealth system of 1% of all coins mined. 

To date 11,413,275 BTC have been mined so 1% would be 114,132.75 BTC @ $100 ea = $11.4 million.  Current blocks are worth 25 BTC so 1% is 0.25 BTC or ~$25.  6 blocks per hour means the founder wealth would be increasing by $3,600 per day.  Now imagine Bitcoin increased by a factor of 50.  Starting to see how "only 1%" sounds silly?

Now I am not saying don't premine.  Do it, or don't do it.  The market will react accordingly.  If your right and a copy and paste clone like the hundreds or so before it is worth 1% then the coin will do less.  If it isn't then it will go nowhere.  However please save everyone the "poor me, only 1%" routine.  Just do what you want to do and be done with it.

Because all the coins are simply copy and paste nothings.  The "devs" know that and know in the long run the coin is going to zero.  So premine a million crapCoins dump then on an exchange for 10,000 crapCoins per BTC and walk away with 100 BTC.  The losers are the ones who mined and held and of course the suckers who traded BTC/LTC for something that a couple weeks later isn't even trading at 1,000,000 crapCoins per BTC.

It isn't one or two times that exact process has played on like clorkwork a couple dozen times with the exact same results each time.

The order or index of blocks in the blockchain.  The genesis block is block zero.  For bitcoin the most recent block is 246495.  Some people say block number but block height is more accurate as blocks aren't numbered and two blocks (in competing chains) can have the same height.

If you really must premine it would be trivial to make the coins in the premine unspendable until after a certain block.  It should take about a half dozen lines of code.  

However I doubt it will really matter.  It is a confidence thing. Most will just see it as a pump and dump.  Those that do mine it will be mining it to dump first.  This creates a race to the bottom.  Those that hold lose, so already lacking confidence they see price fall and dump as well.  Nobody is buying and everyone is selling.  Then difficulty is too high for the negligible real returns so miners quit in droves and time between blocks skyrockets.

Welcome to the coin graveyard where coins enter and never leave.  Maybe not dead but possibly undead.

Except that it wasn't.  Other than that you are spot on.

You could do that or you could just do
process 1: extra nonce n, nonce 0 to 2^32
process 2: extra nonce n+1, nonce: 0 to 2^32
process 3: extra nonce n, nonce 0 to 2^32
process 4: extra nonce n+1, nonce: 0 to 2^32

Neither method is any more efficient than the other one.  Neither method is going to find blocks any faster.  In the long run no matter how you change the block header you are only going to find one block solution for every (difficulty)*(2^32).

Ever miner back to the 0.1 reference client uses extraNonce.  ExtraNonce is simply a value in the coinbase.  You can put anything in there you want, you could put random values there but all miners put a numeric value and then increment it every time the nonce overflows.  In hindsight it would have made sense to just make nonce a 64 bit value, but that isn't going to change now.



Well by that categorization every single miner that has ever existed (even the basic internal miner in the v0.1 reference client) is "smart" and no miner has every existed (and likely never will exist) which is "dumb".  Not a very useful categorization,  I think the OP is trying to solve a problem which doesn't exist.

This.  The fact that it is ~0% not 0% is hard for some people to grasp until you realize the odds of many other things people consider safe are many orders of magnitude more likely.  The odds that an asteroid will wipe out civilization as we know it is trillions of times more likely than the odds of a collision.  The odds that you (the person reading this post right now) already has terminal cancer, just doesn't know it year, and thus the risk of losing funds is pretty much academic isn't just trillions of times more likely it is thousands of quintillions of times more likely.  While I can't quantify it I would be willing to say that I am more likely to eat some random red pill given to me by a stranger and wake up in a Matrix pod then see a random collision in my lifetime.

It isn't a bold statement, it is merely a statement of fact.  Lets ignore the potential added security of double SHA hash and just focus on single SHA-2 hashes.

SHA-2 uses 64 or 80 rounds.  There are no known attacks against 64 or 80 round SHA-2.  None.  No first preimage attacks, no second preimage attacks, no random collisions.  

This isn't for a lack of trying.  SHA-2 is one of the most analyzed algorithms in the world.  It is used for just about everything from banking to PGP to SSL.  A lot of different entities in a lot of different places all around the world have a very vested interest in knowing if SHA-2 is secure.  Cryptography can never be mathematically proven secure, the best we can do is (collectively) look for flaws and if enough people look hard enough for long enough the probability that an unknown flaw will appear suddenly and without warning is reduced, never eliminated but reduced.

An academic attack on a theoretical variant of SHA-2 which uses 41 instead of 64 rounds isn't an attack vector unless Bitcoin happens to use this modified variant with 41 instead of 64 rounds.  For the record it doesn't, nobody does, anywhere, for anything.  Publishing a reduced round version of an attack is essentially saying "we looked for a flaw but couldn't find one however if this algorithm only used x rounds instead of y rounds here is a flaw".  It is a way for other researchers to potentially expand upon but often many of these reduced round attacks are simply dead ends.  What works for 41 rounds may NEVER work for 64 rounds.  It is possible that these known reduced round attacks are dead ends.  That is to say that eventually SHA-2 is broken but it is broken in a completely unrelated manner and researchers who will try to expand on these known attack vectors will spend countless hours it what will ultimately prove to be "barking up the wrong tree".

I never predicted that SHA-2 won't eventually be broken but to claim it will be broken this year requires some significant supporting evidence and none was provided.  When asked for a cite, link to tweets unrelated to the claim were provided.  When confronted the person left saying he "doesn't need to prove anything to anyone".  That isn't what I would call "significant supporting evidence".  

Maybe SHA-2 will be broken this year, or maybe next year, or maybe it is never broken because over time most applications migrate to SHA-3 (after significant cryptoanalysis) because it has less theoretical flaws.  If that happens a exploitable flaw in SHA-2 may never be found because the focus of global analysis will shift to SHA-3 as it will be the bigger target.  To make a long story long regardless of if/when SHA-2 is broken the statement that "it will be broken by the end of the year" is rubbish.  Nobody credible said that, and nobody credible would.

I never claimed buyer will (or are) getting a good deal.  If your math says the deal is bad then don't buy.  If enough people do that (or eventually buy lower priced competitor goods) then ASICMiner will be forced to lower their prices.  It really is that simple.  

Either way the situation is self correcting.  If ASICMiner is making profit hand over fist that just encourages competition.  If you don't buy a rig because they are overpriced but someone else does (maybe less informed) then the network still gains security. 

Very nice I will have to grab a copy and play around with it this weekend.  I know the answer is probably read the code but what are you using for a datastore/database and what libraries are you using for the functions crypto (Native Framework? OpenSSL? )?

No it is much simpler than that.

English version.

Your activity is the smaller of
a) your actual post count
OR
b) the number of two week periods since you signed up (rounded up) * 14

Maybe an example helps.

Say you signed up today and posted 100 posts today
Your posts: 100
Your time: 1 period * 14 = 14 (rounded up remember)
Your activity: 14 is less than 100 so 14
Activity: 14

Now say you don't post anything for the next two weeks. In two weeks your activity will be
Your posts: 100
Your time: 2 periods * 14 = 28
Your activity: 28 is less than 100 so 28
Activity: 100

Now say 18 more two week periods pass and in that time you make another 100 posts
Your posts: 200
Your time: 20 periods * 14 = 280
Your activity: 200 is less than 280 so 200.
Activity: 200

Well the good news is the UXTO grows much slower.  For example in the last 6 months the full blockchain has nearly doubled however the UXTO has grown from ~200MB to 250MB.  This is due to the fact that currency is eventually reused.  New transactions require older transactions to be spent.  The one exception is "dust" where the economical value of the transaction is less than the cost to spend it.  The ~250MB UXTO is about one quarter dust and most of that will never be spent.  If it is eventually spent it is only due to luck and time where the exchange rate rises enough that the dust isn't dust.  This is why the changes to 0.8.2 are so important.  By preventing worthless dust it limits the amount of the UXTO which isn't spent.  If the majority of the UXTO is regularly spent the size will grow even slower.  The size of the UXTO is more related to the number of unique users (with full control over their private keys) then the number of transactions.

Also the method of caching the UXTO is relatively inefficient right now.  The entire transactions is stored however if the inputs are already verified (which they are) then the UXTO could simply contain the already verified output only and possibly the full transaction hash for lookup against the full db.  Outputs are much smaller than inputs with average output size being 34 bytes and the average input size being 72 bytes.  This would indicate a roughly 66% reduction in UXTO is possible.  The vast majority of outputs are "standard" (OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG) for the purposes of the UXTO they could be simplified to a ledger like this:

TxHash - 32 bytes
OutIndex - 2 bytes
Amount - 8 bytes    
PubKeyHash - 20 bytes
Total: 62 bytes

Current UXTO has ~1.1 million unspent output so we are talking data (before db/disk overhead) being ~68 MB.   Obviously this isn't a pressing concern but given the UXTO grows relatively linearly, available memory grows exponentially and the current UXTO can be reduced to ~68MB the risk of UXTO spilling out of available memory and slowing tx validation is minimal.  The one threat was dust.  Since dust is almost never spent it causes the UXTO to grow much faster (they dust just keeps accumulating rather than cycling in and out of the UXTO).  With 0.8.2 that threat is removed.

This is a significant refactoring so don't expect it to appear anytime soon.  Eventually I think you will see the blockchain stored in three different formats.

1) The full chain.  Nodes keeping the full chain (containing all spent tx back to genesis block) will be archive nodes.  It isn't important for every node or even most nodes to be archive nodes but we would want a robust number to keep this archival copy of the blockchain decentralized.

2) The pruned chain & memory pool.  Most nodes will likely only retain the pruned blockchain, replacing spent tx with placeholders in the blockchain.  The memory pool contains the set of unconfirmed transactions.

3) In memory UXTO ledger.  Nodes will build this from the pruned database.  Since tx are already validated (or the tx and/or block would be rejected) it isn't necessary for the entire tx to be stored in the UXTO just the output portion.  Obviously you can't "only" have the UXTO or get the output only portion from other nodes as it can't be independently validated but this doesn't mean nodes can't build their OWN output only ledger from the pruned database.

As for CPU being a limitation I don't see that anytime soon.  A single 2.0 Ghz i7 core can perform 4,300 256 bit ECDSA signature validations per second.  Now that is just the ECDSA portion but it is the bulk of the computing needed to validate a transaction  Lets assume bitcoin implementation is no worse than half as fast and the average tx has two inputs that is a minimum of 2150 tps.  I would caution that this is probably a massive understatement of what is possible and assumes only one core is in use but use it as a worst case scenario.  To catch up 1 million transaction validation (roughly 28 hours of down time @ 10 tps) would take about 8 minutes to sync.  Remember this is just CPU "bottleneck" (or lack thereof).  For historical usage we can assume @ 10tps the first x years is a rounding error (blockchain today has ~3 million transactions or about 3 days at maxed out 10 tps).  To bootstrap from nothing the a node could validate (remember just CPU bottleneck so assuming network and disk and keep up) 185 million transactions per day or about 215 days at 10 tps.  So for near future the CPU isn't really a bottleneck.

Now at 1,000 tps it is a different story so this is why IMHO the first increase to block limit should be a single manual upgrade (to say 5MB or 10MB) to provide time to come up with more robust handling of high transaction volumes.  Those who wish to jump to an unlimited blockchain size are underestimating the risk of either through negligence or malice the blockchain growing so fast that while existing nodes can "keep up" it kills off the ability for new nodes to bootstrap. Given today we are only 0.4 tps I just don't see the potential risks of going from 1MB to unlimited overnight.  A modest one time increase (when necessary) would provide "breathing room" to come up with a more comprehensive solution.