PoW would be something like Nethack.

Bots can't win because it's too complex, but it's simple enough that software can validate an honest win/ascent,
and People play it even without getting coins.

Btc addresses *are* a place to store something. You send coins to an address, they stay there for all
eternity unless you do something. Problem is, Bitcoin-qt doesn't give you control over what you're doing,
and it has the tendency to hide addresses. In an attempt to not confuse the user, it causes panic.

Beer and Aspirin... it does count as household stuff, right? 

But how is this possible? If someone finds a block and is now 1 block ahead of other miners,
either this someone is confident of being able to outmine everyone else at least short term,
or not releasing information (in order to get 2 blocks ahead) just means (50%+ probability) someone
else will find and release information for the 1 block. Now you are behind and lost block reward 

And liquidity providers do it for free just because they trust both of them, while exchanges charge 0.7%?

The exchanges could post bids (in size) for each others USD-IOUs and BTC-IOUs at 0.99x
They would earn the spread instead of a fixed fee, but
everyone could compete with them and narrow the spread.

Cool spreadsheet, thanks  
I dare to predict the "Difficulty vs. Price" will become alot less stable in the future (i.e. couldn't tell
whether btc price is 50 or 500 20 or 2000 if you would see the hashing power chart for next 12 month)
Gamers would switch their GPUs off when Btc price is weak. ASICs will always be on, and production rate
isn't very flexible.

Yes, 2 temporary issues, matching engine is down for a few minutes every 2 hours or so.
And already filled orders are sometimes still visible. Both can cause negative bid ask spread.

It wasn't daytraders who brought the price to 250, it was new "just heard of bitcoin" money,
perhaps smarter traders would have stopped the uptrend at 225, reducing volatility.
(but who knows what would have happened without the exchange crashing, Btc going to 1k and stabilizing?)

Perhaps a decentralized exchange between existing blockchains (Btc, Order blockchain, Ltc) should come first.
It wouldn't solve the problem (except to take some load from btc-e 
but proof of concept for the software part could convince some large online retailers to
become house and sell DollarCoin-casinochips.

That somebody was me.

Pretty much correct description, it's in bad shape. Not sure if you can
even initially connect to network when irc is down. And the "nobody used it for 1year+
but it produced coins" is the worst part.

Btw, I played a bit with fairbrix source and litecoin source, and while code bases are very different,
the 2 coins are almost identical twins, i.e. a dozen small changes to latest ltc code, and
it became a working (with minor display bugs) 0.6.3c fairbrix client.

Perhaps the zombie needs a new thread 

It got ahead of fundamental value (adaption and hash rate), now it's back to "normal" "long term"
uptrend. This would still mean doubling every month, really slow and boring...

Early this year there was an Apple patent about crowdsourced, peer-to-peer mobile banking.
http://techcrunch.com/2013/01/31/apple-patents-crowdsourced-peer-to-peer-mobile-banking-that-could-use-itunes-to-provide-cash-on-demand/

If you imagine such a system in action (for trading btc vs cash, participants can basically
choose to accept deposits or become ATMs) it's almost silly. Could become an unstoppable
worldwide fad 


Really extremely non-trivial to implement but more likely to be baked into a new client,
not a new cryptocurrency.

In a strange way it's just what central banks say they want, people help gross domestic product when they spend fiat
on hardware, energy and shiny things (after becoming bitcoin millionaire)

Certainly not a case of "just as planned" though. 

The low volatility USD/XRP chart is really nice

What I miss is implicit quotes (in the ripple.com/client order books).
For example when bid ask spread for bitstamp USD/XRP is 5% and for bitstamp BTC/bitstamp USD also 5%,
then the ripple exchange engine could automatically post bitstamp BTC/XRP quotes with 10% bid ask spread,
but this doesn't seem to work.

If I'm not mistaken the 2 versions are logically the same for LOOKUP_GAP == 2
(salsa(V) if not called at all if j is even, and called only once if j is odd)

Several threads per Stream Processor, apparently.

I'm just guessing: GPU could work faster but VRAM random access speed is the limiting factor
(entire VRAM is used after all, and Lookup gap > 1 means you have to write+read several times
instead of once)

Performance hit from waiting for access of twice as much mem (hyper memory, or regular ram instead of cache)
would be worse than Lookup gap -- double Lookup gap and you can always get 50% less ram use for ~50% performance hit.
This would be the same for hypothetical Asics and FPGA.


CPU is more interesting. LTC's 128KB scrypt implementation fits in L2 cache, but L3 cache is almost as fast.

http://www.xbitlabs.com/articles/cpu/display/core-i7-3770k-i5-3570k_2.html
http://www.sisoftware.net/?d=qa&f=gpu_mem_latency&l=fr&a=

i7 8MB L3 cache / normal DDR3 ram       10 times faster   (latency  ~4ns / ~40ns)
HD6850 VRAM / Llano shared DDR3 ram    <2 times faster   (random access pattern test 703ns / 1110ns)
HD6850 256kB L2 cache / HD6850 VRAM     2 times faster   (365ns / 703ns)

So, 1 or 2MB lookup table size would be the "sweet spot" for most cpus? Even celerons have 2MB L3 cache...

Ripple is the Joker in the game. Potentially much more useful than *coins
but right now ripple is vulnerable in terms of regulatory risk and,
really, we don't know much about it, how does it scale, how does it
in practice deal with sybil attacks, ddos attempts, modded clients etc.

I think tc and parallel calcs is the same (at least in the reaper
config file "gpu_thread_concurrency" means "how many parallel calcs")

for example:

gpu_thread_concurrency 4000
lookup_gap 1
>LTC buffer size: 500MB.              <--reaper says it uses 500MB, should be 4000*128KB=512000KB(?)


Sort of counterintuitive is that RAM usage can be reduced by much without killing
the hash rate completely:

lookup_gap 8
>LTC buffer size: 62.5MB.
95kH/s

lookup_gap 16
>LTC buffer size: 31.25MB.
58kH/s

lookup_gap 64
>LTC buffer size: 7.8125MB.
16kH/s

Scrypt makes it just too easy to regenerate the Scratchpad
for every lookup.

Aside from downloaded TV series I stopped watching completely when subjectively it all
became trolling (aka news) and dadaism and boredom. Even discovery and shit
just can't get facts straight.

Also: no adblock

Today something like a 4 years old notebook struggles with current block size/7 Transactions per second,
but after the 21 million Bitcoins have been mined average computers will be *so*much* better.

Max Block size will be increased. It would be silly not to.