The reference client stores the UXTO in the data directory under the subfolder chainstate.  It is stored in leveldb. 

270 Hashes per second?  That is less than nothing.  A somolian refugee would starve.  We are talking a faction of a US penny a decade. 

No double spend attempts don't cause coins to be returned.

However if you delete a transaction then your node will stop broadcasting it.  Eventually all nodes delete the oldest transactions so without continual rebroadcast the tx will simply cease to exist.  At that point you can create a new transaction.

Understand this is a hack and in the future you should follow network rules.  The default client won't allow you to send a tx which requires a fee without a fee for this specific reason.

Scrypt doesn't use a massive amount of RAM unless you consider 128KB (yes Kilobytes not Megabytes or Gigabytes) a "massive amount".

Even full strength scrypt doesn't use "massive" amounts just enough that CPU with their significant cache are better optimized than other choices.  The scrypt used in litecoin is significantly crippled.  The low security (realtime) settings for Scrypt recommend by the author are 2^14, 8, 1 and the high security settings 2^20, 8,1.  Litecoin uses 2^10, 1, 1 making it roughly 100x less memory intensive then real time scrypt recommendations and ~8,000x less memory intensive than high security scrypt recommendations.

Yes.  It is possible (depends on the underlying public key) to have multiple leading zeros.  

For example the public key:
00000000000000000000000000000000000000000094A00911

Produces the Bitcoin Address:
1111111111111111111114oLvT2

Yes it is a valid address:
http://blockchain.info/address/1111111111111111111114oLvT2

Yes the removal of excess zeroes is covered in the link I provided.


In your example all of the leading zeros 00000071F5AB3BE5657C2B8742575C9D5EED6220BBC3565FA8 are removed and encoded as a single "1" for each byte before encoding the rest of the value.

So 000000 = 111

the the rest 71F5AB3BE5657C2B8742575C9D5EED6220BBC3565FA8 is treated as a single large (256 bit) number.  Take the number divide by 58, calculate the mod and store the excess.  Convert the mod value (0 to 57) into a base58 digit.  Continue this process until the number has been reduced to zero.  You will be left with a string of base58 characters.  

For example the first (least significant digit):
0x71F5AB3BE5657C2B8742575C9D5EED6220BBC3565FA8 mod 0x3A = 0x10 = "H"



Honestly this is one of those things which I think Satoshi made excessively complicated for no real benefit, but he did and to change it now would be a breaking change which isn't going to happen.

The conversion to base58 is done by dividing the ENTIRE address ( which is a 256 bit number) by 58 taking the reaminder (mod), recording the value, and continuing that process until the number is reduced to zero.

You can't look at just one value at a time.  There is no 1=1 relationship between bytes and base58 values.  If you think about that logically it can't be.  A byte has 256 possible values to convert that into single "digit" ASCII values would require base256.  Right?

For more info on how to perform base58 encoding ...
https://en.bitcoin.it/wiki/Base58Check_encoding

This.  Looking it at the game company perspective why would they want you to use Bitcoins when they can make you use credits or gold or whatever they want and print quadrillions of units for nothing.

So only bears took the weekend off and bulls worked over the weekend buying?

It may go higher or it may go lower but your "reason" probably has nothing to do with it.

Nope not correct.  Tenebrix was.  Litecoin was just a copy-coin.  Now ultimately it ended up more successful but you can see the irony of bashing "copy coins" when promoting Litecoin which was one of the first "copy coins".

Also to say changing the hashing algorithm is a "major change" is kinda silly.  It is about a dozen lines of code.  If your favorite game developer released a sequel which had about a dozen lines of new code would you consider it novel and ground breaking?

PPC (despite its issues) was a major rewrite.

Why do you think the economic lifespan of an ASIC is only 18 months.  Imagine for a second you bought a GPU 18 months ago and no FGPA or ASICs existed.  Would the economic value (not resale) of your GPU be $0.

You may say "wait people can make faster ASICS" and that is true but we are talking about a marginal increase not a magnitude increase.  Going to a smaller process means about 2x the electrical efficiency (MH/W) and maybe 1.5x the MH/$.  So people have more efficient rigs but no so much more efficient rigs that yours will not be able to cover the cost of electricity.

There is a LTC thread.


Maybe thread doesn't mean what you think it means?

As for a dedicated Litecoin board.  Mods have indicated it will not happen.  This is bitcointalk.org

I sold a casciius Bitcoin to a friend this year.  It hasn't "moved" on the blockchain since 2011.  I would imagine MtGox cold wallet hasn't moved for years either despite having tens of thousands a Bitcoins a day in trading volume.

For regulation "Stored value" (technically now called "prepaid access") is a legal term with a specific definition. Nobody (not even FinCEN) is saying Bitcoin isn't a store of value, it simply doesn't meet the statutory requirements for a form of "prepaid access".  Namely there is no ability for redemption and no issuer.

Take a starbucks gift card.  This is regulated as prepaid access because it is only good if it can be redeemed at a future date.  Stabucks issues a card.  You buy a card and starbucks holds that money in escrow until you redeem it.  At some point in the future that "prepaid access" is used to make a purchase.  It is only good if starbucks doesn't steal/lose/embezzle the money in the meantime otherwise it is just an empty promise.

Anytime (well usually) a term exists in regulations it is defined.  Don't assume you know what they mean, or use "common sense" to determine the meaning.  Just look up the term in the regulations.

Older blocks are never rewritten but it is possible there are 2 or more competing chains.

Example the last block is block height 123

One miner solves a block with height height of 124 (it references the block hash 123 as the prior blockhash).  We will call this block 124a.
At roughly the same time a different miner solves a different block with a block height 124.  We will call this block 124b.

At this point the network is not in consensus. Some nodes believe block 124a is the next "valid" block and some believe 124b is.

Eventually some node will solve block 125.  If the block is built on the 124a chain then block 124b becomes orphaned. If it is built on the 124b chain then block 124a is orphaned.

If your node had received block 124a before it became orphaned it will be contained in your block history.  When block 124b orphans block 124a it will also be contained in your block history.  You can detect this because both blocks will have the block hash for block 123 as the prior block hash.

In your block parser you can built a simplified system to remove orphans by working backwards.  bitcoind will tell you the hash of the last block of the longest chain.  Working from that block you can locate the prior block hash field in the header and then locate the corresponding block, and work all the way back to the genesis blocks.  Any other blocks are orphans and for the purpose of parsing the historical blockchain can be pruned.


Simple version:
It is possible at any point in time there are multiple conflicting blockchains.  The "longest"* chain is considered the consensus record.
* longest in this instance doesn't mean just highest block height (as that can be spoofed) it means the chain with highest aggregate difficulty.

No.  This portion is incorrect.


The transaction from Mary will be a single transaction

Input0: 7 BTC sent from Bob.
Output0: 4 BTC to Freddie
Output1: 3 BTC "change" back to Mary.

It is best to always think about transactions as simply inputs and outputs.  In Bob's case if he received 7x 1 BTC inputs it doesn't matter if they were sent to 7 addresses or all 7 to one address regardless they are 7 discrete inputs.  So Bob's tx would look like this

Input0: 1 BTC
Input1: 1 BTC
Input2: 1 BTC
Input3: 1 BTC
Input4: 1 BTC
Input5: 1 BTC
Input6: 1 BTC
Output: 7 BTC (to mary)

A couple of general rules
1) Transactions consists of one or more inputs and outputs.
2) The sum of the inputs of a tx must be equal to or greater than the sum of the outputs
3) If the sum of inputs is greater than the sum of the outputs the difference is the fee paid to miners.
4) All tx (except coinbase txs) have as their inputs, the unspent outputs of prior transactions.
5) Outputs can only be unspent or spent.  You can't spend part of an output.

Well no.  First of all it is all academic because there won't be only one miner but even if there was, miners don't control the rate of generation the protocol does.  This makes Bitcoin unlike ANY fiat currency.  Fiat currency is handing the rate of generation to a cartel of elites with 100% implicit trust that they won't abuse that authority through ignorance, corruption, or greed.

Not sure where you got that idea.  Stored value issuers are MSBs but stored value issuers are NOT money transmitter under federal law (SV issuer aka "prepaid access" is one type of MSB entity and MT is another).

FinCEN specifically said Bitcoin exchangers are MT because they accept Bitcoins which are "other value that substitutes for currency"
FinCEN also specifically said Bitcoin exchangers are NOT issuers of prepaid access (stored value) because those require "real currencies".


http://fincen.gov/statutes_regs/guidance/html/FIN-2013-G001.html

The average number of rounds fire in a police shooting ... 17. 

Responsible gun owners should know the laws related to self defense, castle doctrine, stand your ground, etc in their state.

If you genuinely believe that your situation does not requrie lesthal force then 1 shot is just as wrong as 5.  If your situation requires lethal force then it requires lethal force until the target is no longer a threat.  That means aim center mass and shoot until target ceases to be a threat, has left the area, or you run out of ammo.

Speaking as an 11 year Army Veteran shooting with a pistol under combat conditions is difficult.  Even trained Police Officers rarely hit one in 12 shots.  The first thing that happens is you will get a shot of adrenaline likely the largest and most intense dose of adrenaline you will experience in your life.  The bad news is this causes peripheral vision to fade, fine motor skills (like aiming and trigger squeeze) to be degraded and a sensation of time operating at a increased speed.  Many soldiers in firefights will believe it lasted 10-15 minutes only to find out only find out it was 90 seconds.

It can be very difficult to make an assessment under combat conditions if a target is still a threat (and self defense is combat).  If they are still a threat and you hesitate trying to determine if you landed two hits or not it may be the last mistake you make.

Positively identify the threat (make sure the intruder is really an intruder).
Aim center mass (no stupid "shoot him in the leg" nonsense landing body shots is tough enough).
Shoot to stop the threat (continue to engage the target until is no longer a threat).

Yeah I don't think you understand how modern DDOS work.  The attacker hits your upstream provider with hundreds of GB/s of traffic, the simply null route you to deal with the flood.  It is why DDOS are so hard to deal with.  The pipe to your server simply becomes saturated beyond your bandwidth capabilities.  You can't filter our the good nodes if they can't get to your server.

The idea that you know all miners so you can whitelist them is somewhat disconcerting as well.  You have essentially created the central mining agency.  The entity which all miners must work with to have any chance at efficient mining.  Not really sure that is the "solution" as opposed to simply using a more efficient (large) block interval.


Even at 10MB we are talking, a not so insignificant delay.  

Still lets assume for a second you overcome the philosophical and vulnerability issues of a centralized clearing house. This still means a 2 hop propogation delay.  

The critical window = (time to transmit to clearing house) + (time for clearing house to validate block) + (time to transmit to other miners) + (time for other miners to validate)

Today validating a 500 KB block can take upwards of 300 ms.  10MB would be more like 6000 ms.  Lets assume protocol efficiencies cut that in half say 3000 ms.  Remember there are two validations unless miners are just going to blindly (100% implicit trust) the data provided by the clearing house.  Say the clearing house has 100 Mbps synchronous lot latency connectivity.  The transmit time from miner to clearing house then becomes 5*8/100 = 0.4 seconds.  If there are (a guess) 50 miners using the clearing house the time to transmit to the miners is another 50*10*8/100 = 40 seconds.

Under this naively optimistic scenario we are talking 0.4 + 3+ 40 + 3 = 46.3 seconds for full validation and double hop propagation to 50 mining peers.  With Bitcoin's 600 second average block time this means an orphan rate of ~8%.  With LTC it is more like 26%.  With the idiotic 30 second block intervals used by some scamcoins it is something on the order of 80% orphans.

Now there are solutions to make block propagation more efficient.  One (not possible on Bitcoin but could be used on an altcoin) would be to use a simplified transaction structure.  I have done some modeling and see a roughly 60% reduction in block size is possible (i.e. 1.7x as many tx in the same sized block).  For Bitcoin/Litecoin a soft fork where block is separated into header and tx set would allow more efficient pre-propogation of transactions.  Still at the end of the day smaller block intervals are going to face scaling challenges much quicker and an increased loss of security due to orphans is inevitable.