Your array and batteries aren't even in the ballpark. A 160W array puts out 160W per hour in PEAK sunlight.  Peak sunlight being 100% mid-day at the equator sunlight.   Depending on where you live your average solar insolation is likely 4-5 hours per day.  So in 24 hour day you only get about 4 to 5 times the nameplate rating of the panel.  A solar insolation of 4.5 means in 24 hours you get the equivelent solar energy as 4.5 hours of peak sunlight at the equator.  A 160W panel only outputs 160W under peak sunlight.  That doesn't mean it only works for 4.5 hours it just means that it isn't always outputting 160W. 

So 160W /1000 * 4.5 = 0.72 kWh daily.
1 Single @ 80W * 24 = 1.92 kWh daily.  
You would run out of juice 1/3 of the way through the day ... every day.
1920W / 4.5 = 430W.  
So your array cost is now ~$1500.

However it gets worse.  Without a charge controller you are looking at losing 20% to 30% of your power due to voltage mismatch between panel output (variable) and the battery optimal charging voltage (also variable).  Given the cost of solar panels the charge controller is cheaper than trying to "brute force" it.  So that adds another $150 or so.

Still we haven't even got to the really bad news.  That 4.5 hours is avg solar insolation, it is roughly 35% less in the winter.  So unless you plan to run your rigs only 9 months out of the year you need to size your array so it is large enough even in winter.  So we are more like looking at 640W array (~$2000).  Yup that also means you will be wasting the excess power it produces in the summer.  No way around that limitation on off-grid system.

Your battery will need at least 1.92 kWh of capacity but you likely will want more.  You may have a rainy day (or 2 or 3) so really you want enough capacity to last 2-3 days to ride out the day to day variance, unless you want your single shutting down a couple times each month due to overcast or rain.  We are talking a dozen of deep cycle batteries.  Maybe $500 in battery capacity.

So excluding mounting, rails, wiring, installation costs you are talking somewhere in the tune of $2000 (640W array), $150 (charge controller), $500 (8 kWh battery bank).  At $2650 in capital cost and $0.10 per kWh average electrical rates.  You will get $0.19 in "free power" per day.  Break even point is in 39.7 years.  Direct DC (offgrid) solar systems are prohibitively expensive, small solar systems are prohibitively expensive.  One that combines both is just foolish.

A gridtie system will still be expensive but is easily half the cost (or less).  It really is your only option.  Still break even is likely in the 10 to 15 year range.  Why is a grid tie system cheaper.  It allows you to exploit the AVERAGE solar insolation.  Once again using 4.5 hours as average annual solar insolation.  A 80W BFL Single will use ~700 kWh annually.  Lets increase than 10% to compensate for system losses.  Say ~770 kWh / 365 / 4.5 = 460W.  Smaller array and no need for batteries = cheaper system.  

It prevents a scammer from using a non-Dwolla bank account and signup up for Dwolla service but it does nothing to protect against keylogger and using a victims already established account (one w/ facebook links, and 30 day of account history).

It is feel good security.  If most of the attacks are from creating new accounts using stolen non-Dwolla enrolled bank accounts then the attackers will simply shift to stealing existing dwolla accounts.

All clients have the starting source ... the genesis block.   The only way to validate block #1 is to ensure it meets block requirements and has the block hash from block #0.   As such all full-clients must include the genesis block.  From there every node can validate every tx from block #1 all the way to current block.   As indicated above clients may also include hardcoded checkpoints.

Nodes are NOT secure.  They are inherently insecure.  You have no idea how dishonest your fellow "peer" connections are.  Hell they could all be the same attacker.  As a result Bitcoin DISTRUSTS all blocks received from the network until validated and added to the chain tracing all the way back to the genesis block.

A broadcast system for blocks wouldn't be any different.

What are you talking about.  Each client validates their own blocks starting from the hardcoded genesis hash in the client.  The method of delivery doesn't need to be secure.  You are aware that a node can give you a bad block right?  The client has already considered that attack vector.

Someone using the service to publish bad blocks would simply find those blocks invalidated by nodes.  At best they could prevent nodes from getting new blocks via this mechanism (service denial) nothing more.

BTW that isn't two factor.

a) Something you know
b) Something you have
c) Something you are

One factor uses one of the factors, two factor uses two, and three factor uses three.  Adding more elements from the same factor doesn't significantly increase security.

The issue is for 99.99999999999999999% of users given two options:

a) the right but potentially long and boring way
or
b) the super fast and easy ( .... and potentially cryptographically insecure ... they already clicked a).

I do think the protocol could be expanded to do it is a p2p fashion using the nodes.
1) New nodes compress and hash 10,000 blocks into a "macro block"
2) New nodes randomly pick one prior macro block (to date there would be 17 macroblocks) and include it's hash in coinbase
3) Old nodes would ignore this but new nodes wouldn't consider a block valid unless the macroblock hash in coinbase is valid.

Virgin node bootstrapping.
1) Node requests macroblocks from peers and records their hashes. (downloading all 17 macroblocks would take node to block 170,000)
2) Node requests newest blocks normally and validates macroblocks from the coinbases.

If all 17 macroblocks have valid hashes then the macroblocks are valid and thus tx are valid.
User could even download the 17+ macroblocks from non p2p source since validation is based on the blockchain.

Well he is assumming 15% CPU and 50% bandwidth of "average computer user".


I just think that
a) limiting Bitcoin to 15% CPU usage and allowing MWAVE to use 50% of user's bandwidth is disingenuous.  Even at 100 tps Bitcoin only requires ~ 100 kbps.  I don't know how many users are willing to give up 50% of their bandwidth 24/7 forever especially in light of ISP bandwidth caps, throttling, and overage charges.

b) even if we assume the 15% CPU and 50% bandwidth limits are realistic I have no idea what CPU would be only able to validate 65 transactions per second.

c) computational power has (and likely will continue) to grow at a faster rate than bandwidth AT THE LAST MILE. 

Same here although the watercooled ones are running at 15% higher clock.  Just need to get all the rigs converted.

How do you reach the conclusion that a Bitcoin node is limited to 10 tps?

Modern (i series) CPU can process >80 tps per core and the bandwidth requirements for 80 tps is negligible.

To put it into perspective:
current:  0.1 tps
Paypal: ~50 tps (~$80 billion annually)
15% CPU load on quad core system: ~50 tps

I see from paper you put artificial limit on 50% of user's bandwidth and 15% of CPU power.  Those would be worst case scenario for Bitcoin and best case scenario for a cpu lite, bandwidth intensive system right?

Still even w/ "limit" of 15% CPU usage I don't see where you get 10 tps.  Is this a Single core ATOM processor?

      






Hmm ...

Yeah this troll account is "weird".  Previously he made this claim:


Yes he is claiming that after depositing 0.01 BTC to the site somehow the site later pulled all the funds from his Bitcoin wallet and lost it.

Floating point doesn't matter and I question the logic of using floating point due to the variety of rounding errors that introduces.  Still  % fees are not possible on a Bitcoin derived system.

Bitcoin has no concept of the value of the "spend" just the total input and total output.

So 0.1% fee.  Paying merchant 1 BTC.  1000 BTC input.  
1 BTC -> merchant, 999 BTC -> change  
0.1% * 1000 = 1 BTC fee?  
1BTC fee on 1 BTC "spend"?


Its no a question of IF.  You have given a direct financial incentive to ensure those edge cases come up.  The system will be gamed.  Large pools (or consortion of pools) can keep hidden tx and use them to invalidate blocks of miners who aren't part of the cartel (or unwilling to pay fees to gain knowledge of the hidden txs).  It doesn't matter what a miner thinks is valid if 51% of the hashing power disagrees.

You are creating a system where the profitability of large pools is enhanced by witholding information from other miners which makes the system less secure.  Y

Fixed percentile fees are also impossible (at least in Bitcoin and any derivative).

Requiring tx to be included would ultimately lead to entities gaming it to disadvantage other miners.  Given mining is a zero sum game the less efficient your make your competitors the more profitable you are for the same amount of raw hashing power.

Imagine a large pool X.  When they detect a new block they spam the network with "old" (based on timestamp) tx which make the new block invalid.  Their attempted blocks already have the "old" (but not broadcasted) tx so their blocks are never non-compliant.

Depening on the number of connections they have and propogation delays they may successfully orphan a small but significant portion of blocks.  The pool (or consortium of pools) could even be more evil by having "secret" tx which are only shared to other pools who pay an "information services fee".  Pools who refuse will be missing a require component of valid blocks and thus being oprhaned.  A pool collecting fees on other pool's miners.

It all comes down to cost vs benefit.

The bridge chip is actually "not" required.

PCIe spec differentiates ports from lanes.  It is "possible" to have a PCIe controller route lanes to two ports on the same expansion slot.  Support is essentially non-existent.  Most (all?) motherboards assume 1 slot = 1 port.  If a dual GPU used that feature it either wouldn't work or only 1 GPU would be usable in non-compliant motherboards.

If at some point in the future most motherboards supported routing 2+ ports to the same physical slot then there would be no need to use a bridge chip.  Each GPU would simply connect via 8 lanes.  One irony is that those GPU wouldn't be usable PCIe1x slots (i.e. extenders).

PCIe 3.0 with 16 lanes is 16GB/s bidirectional non blocking.  What scenario's would require >32GB/s?  For those 0.0000000000000000000000000000001% of the time does the cost of a proprietary solution outweigh the simplicity and economies of scale in using off the shelf components?

It simplifies drivers and OS interaction.

It is two complete, independent, and indentical GPUs (from OS point of view).

If you only had no PCIe switch then either
a) you need some proprietary switch to route I/O to proper GPU.

b) have one GPU be the "master" and the other GPU the "slave".  Only one GPU is connected to PCIe port and relays I/O to the second GPU.

Neither is really a good solution.  I don't see the switch as clumsy.  You have two independent components on a single board which need access to the CPU via a single PCIe port.  1 Port -> switch -> 2 ports each with a GPU connected.

I don't think it will ever be "deleted".  Remember 7990s are simply two 7970s.  There would be no need for 7970 to interface w/ PCIe adapter/controller via a proprietary solution. 

Are you using a static payment address?
If the address listed here: http://p2pool.info/ (under current payouts)?
What does p2pool daemon show as "Current Payout"?
What does p2pool daemon show as pool hashrate "Pool: XX GH/s"?

Take a step back.  The reason for a brain wallet isn't just to avoid writing "something" down.  It is to avoid writing a SECRET down.  Once a secret is written down it can be compromised or lost.  

The implementation isn't a secret and having that "written down" (as in drop a copy in your google docs folder, drop box, filing cabinet, email it to yourself, etc) doesn't represent a risk of compromise.

A universal standard is like a utopia.  It probably will never happen.

I have used this cartoon before but it is (sadly) accurate.


Maybe a universal standard will happen but I honestly doubt it.  There will always be differing opinions between authors on implementation aspects.  An interim goal would be to push that all deterministic wallets provide specific details (not code) on the entire process ("secret" -> set of private keys) in plain text format for archiving which would make reconstruction without any access to current code possible.  That would provide at least some level of disaster recovery in the event no existing wallet is compatible.

What Bitcoin related files?

My bitcoin folder(s) + all virtual memory is <2 GB.

The only thing I can think of is you have an excessively long log file?  in the datadir folder there is a sub folder called "database" which contains the log. You can safely delete the log files to reclaim space (I wish bitcoind had an option for max log where it would truncate oldest log file to maintain a max size).

The legal tender issue is an interesting one but I doubt it will have any practical impact.  Legal tender doesn't obligate someone from accepting currency in any specific form (for example the bank isn't required to accept a dump truck of pennies to pay off your mortgage).

As far as counterfeiting.  If the royal mint doesn't offer 1:1 exchanges even with inflation due to counterfeiting then I imagine the entire system fails.  Who would choose a chip which may lose 10% to 50% of its value due to no fault of their own when they can just keep using "cash" instead.

As far as what happens to the dollars my guess is that the brokers will be contractually obligated to hold in reserve 1 CAD for every 1 mintchip CAD token issued.   Similar laws exist for things like casino chips.  Casino must have $1 dollar in reserve for every $1 in chips held by customers or on the floor. Failure to meet the 1:1 ratio at all times can result in them losing their license.

For largest brokers if the system ever become widespread that means a significant amount of revenue from float.