If the company has never heard of Bitcoin it will require a little work simply because there is no "bitADP" (ADP is major payroll provider in the USA) at this time.  However if a company is interested it wouldn't require more than an exchange account that accepts wires from the US (like MtGox).  The exchange account would be in the name of the company. The cost of the wire plus trading fees is still <1% which is a reasonable cost to provide this as a perk for employees (a cost of doing business, traditional payroll also has operating costs).

What would be useful is for MtGox (or a third party service provider) to have the ability to setup standing periodic market orders (i.e. buy $x worth of BTC every 24 hours at market). The company would also need a signed agreement with each employee on the amount of the election and clearly laying out the terms. 

One thing which needs to be considered (and should clearly be articulated in the election agreement) is how will the exchange rate be calculated.  The simplest method would be for the company to simply use the exchange rate at the time of payment.  If the company owes an employee $1,000 in "bitcoin elected salary" the company on payday would buy $1,000 worth of Bitcoins at the current market price and transfer it to the employee.    That is the easiest way but elected to but it diminishes the power of dollar cost averaging (what if on payday the exchange rate spikes up 10% before crashing back the next day).  In my instance our company uses the volume weighted average price for the entire pay period.  If the company does not have significant Bitcoin cashflow it would make sense for the company to to pre-deposit sufficient USD into an exchange account to handle employee Bitcoin purchases and buy in equal installments throughout the pay period. 

Example:  A company has 5 employees who combined have elected to have $6,000 of salary per pay period paid in BTC.  The company would make a single wire transfer to an exchange prior to the pay period beginning.  Say this company issues paychecks on the 1st and 15th of each month.  Everyday during that pay period the company would buy $400 worth of Bitcoins.  This way the company has the Bitcoins on pay day and they employee gains the advantage of dollar cost averaging. 

As for accounting or tax implications.  For the employer the accounting (from company book's standpoint) is no different than paying an payroll only in USD.  Any costs beyond the payments to employees are operating expenses.  Companies already have to withhold various taxes, and insurance premiums from an employees pay and the company then incurs the liability of making sure those payments are made.   I am not a tax attorney but at least in the US there are no tax implications for paying an employee by alternate means.  If the company realizes a capital gain (or loss) on their Bitcoin holdings they will need to account for that but this is true even in non payroll situations.

Example employee (based on this free tool:  http://www.paycheckcity.com/calculator/salary/ )
The example employees is opting to receive 20% of gross pay in BTC.


As you can see Payroll is already complex and this doesn't include employer matching portion of 401K, employer's portion of FICA taxes, unemployment insurance, etc.  Payroll involves a lot more than "paying the employee"  It is taking a employee's gross pay and disbursing it to a variety of accounts.  Often like in the case of taxes those funds are only paid quarterly but accurate payroll requires the company to account for the liability of those future payments.  Adding yet another post tax deduction to a paycheck to allow employees to take pay in BTC is pretty simple in any payroll or accounting software.

There is no hard value.  You vote by setting the dust threshold for your node.  5430 satoshis is simply the default.  If a significant minority of nodes make it 1000 instead then smaller tx will be relayed.  So the framework for your "vote" is there right now.  Staying on an obsolete version is just silly though.  You do realize you can set the dust threshold to whatever you want in 0.8.2?

Dropped the price $5.  Will drop it $5 everyday until lot sells.  Someone might get a nice deal but don't wait too long.

Also biometrics are not deterministic.

Meaning your fingerprint can't be a decryption key because if you scan your fingerprint 100 times the resulting image will be different every time.  Biometrics look for an image which is "close enough" to the original.  This means that you can't employ strong security with biometrics.  You can't use the image to generate a encryption/decryption key because everytime you scan you finger the key produced will be different.  Thus if software can unlock your wallet on a fingerprint scan that means the software already has the decryption key.  If the key is available a hacker will find the way to extract it.  Your system would be less secure than a strong passphrase.

I am working on an API which will provide a global volume weighted exchange rate and glad to see others doing the same.  However a 30 day period is just far far too long to be of use to anyone at anytime.  Internally we use 24 hour, 1 hour, and 5 minute VWAP depending on the purpose.

Mixing in non USD is likely not going to be useful for most people.  If you want to I would recommend making that an option (i.e. "pure USD" or "USD including converted non-US trades")

It does not state that.  There is ANOTHER exemption for entities who's activity who's activity otherwise meets the MSB requirements but the activity is only done infrequently and not for profit.  For example if you one time sell your friend some BTC technically you meet the requirements as an MSB and would need to register however you could claim that you are not regulated under the "infrequently and not for profit" exemption.


The exemption in ((iii) is independent of the one in (5)(ii)(B)



Simplified version:
A) if you infrequently exchange virtual currency for real currency and do so not for profit your activity would be exempt under the exemption in ((iii)
B) If you operate a payment processing network to facilitate payments from consumers to merchants (aka a clone of BitPay) you would be exempt under exemption in (5)(ii)(B).
The two have nothing to do with each other.  You don't need to be a payment processor to gain the exemption in ((iii) and you don't need to be not for profit to gain the exemption in (5)(ii)(B).
NOTE: the above if informational and should not be construed as legal counsel.  If you have a specific question about your specific activity you should retain legal counsel.


This doesn't "help", banks are also exempt from Money Transmitter registration (see ((i) above) because they are required to register under separate regulations.  Issuers of prepaid access are required to register as MSB just not under (ff)(5) "Money Transmitter" they do so under ff(4) "Provider of prepaid access".   Remember there are 7 categories on activity which require registering as an MSB.  Money Transmitter (#5) is just one of seven.  The regs make it difficult to follow because after they name on type they then go into multiple pages of exemptions, and other supporting regs.  Here is what it looks like stripping out all the supporting paragraphs:








No.  That isn't the reason Bitpay is "playing by the rules".  BitPay is a payment process which are exempt.  Period.  They don't need to meet any other criteria other than being a payment processor.  In the same respect VISA and MC are not MSBs they are payment processors.  
Be sure to read the regs multiple times, there are lots of categories and types.  Prepaid vouchers are "prepaid access" under MSB rules and are regulated.

At the federal level issuers of prepaid cards and gift cards are MSBs under the category "prepaid access".  The previous term was "stored value" and they are essentially similar.
Just about every state regulated issuers of stored value and requires pretty massive bonds and licensing requirements.  For that reason almost no retailer actually issuers their own gift cards.  They are issued (read small print on back of one) by a handful of companies which specialize in that business (and have licensing in all states). 

The reason is stored value is a promise to pay in the future.  If starbucks issues you a $100 starbucks card although you may hand Starbucks the cash today, that cash doesn't below to Starbucks.  Starbucks technically hasn't generated any profit yet.  They add $100 to their prepaid account (asset) but the also gain a $100 liability (accounts payable).  Only when you make a purchase with that card is the liability removed.  The company is prohibited from using, spending, even comingling any of the funds on prepaid cards that haven't yet been redeemed.  States regulate this heavily because imagine what happens if a company sells $50M in gift cards and then the CEO wires it to a non extradition treaty country and hops a plane.  Ooops.  Your stored value is worthless piece of plastic.

Bitcoin isn't stored value for a whole host of what should now be very obvious reasons but if it were the regulatory requirements at the state level are just as high for stored value issuers.


Amazoncoins are a virtual currency under FinCEN guidance.  If you ran a business converting USD to AMZ or the reverse (which you can't because AMZ prohibits all such activity) then you would under FinCEN guidance be a MSB.
Of course if you sell "traditional" gift cards instead you would still be an MSB (or required to be an agent of an existing MSB).  Take GreenDot for example.  They are an MSB however lots of places (wallmart, 7-11, etc) sell MoneyPaks which aren't MSBs.  An MSB can choose to make a third party an agent of that MSB and the agent is not required to be licensed or registered as long as they are acting only in the capacity of an agent of an existing MSB.

Where did bitcoin-24 keep USD balances?

I receive part of my salary in Bitcoins.  The simplest way for a company to pay using Bitcoins is to make it an "after tax deduction elected by the employee".  My salary is $X USD.  The company already deducts payroll taxes, income taxes, and benefit premiums.  I elected (by written authorization) to have a certain amount of my salary paid in BTC.  The options my company gave me were a specific USD amount, a specific % of salary, or entire net (after withholding and deductions) amount.  

On Payday the company converts the USD amount to BTC using the volume weighted average exchange rate over the entire pay period.  Our company's program covers all costs and fees but a company could charge a reasonable fee for the service.  I am sure on a long enough timeline payroll companies like ADP will offer this.

Now there are other ways to do this but the advantage of doing it this way is that it is very simply for any company to implement.  All Payroll software allows post tax deductions.  The amount deducted becomes a credit on the company USD books and an equivalent debit is made on the company's BTC books.   The tax implications are already taken care of (other than any capital gains on rising value) as the taxes were based on gross salary.  The company can still deduct the entire cost of the employees salary with no changes to accounting.  

TOS can't violate existing laws.  For example I can't put in a TOS by using the service you agree to transfer all property to xyz corp and then go into court and say "see he agreed give me the deed to his house".  A company can refuse to do business but they can't refuse to do business and "hang on to" another persons assets.  The honest and clear thing to do would be for the service provider to have client complete any requirements first and then accept funds. For example if the service provider is worried about ACH fraud they could send a random small amount of funds to the clients account to verify it.  If they need any docs they can design the site such that the client can't send funds until verified.  

Nothing in MSB regulations requires or even allows a company to just keep client funds.  The purpose of AML is to prevent the TRANSFER of suspicious funds not to deprive criminals of them (note not saying the OP is a criminal just pointing out the purpose of AML programs is to prevent not seize).  Seizure of assets is a law enforcement activity pursuant to a warrant by a judge.  The company has no authority to seize funds of clients under any circumstances.  If funds are returned then there is no transfer. In the event of a "suspicious transaction" the proper procedure is to file a SAR with FinCEN.  If the company had completed mandatory AML training and had a written AML compliance program as required by a MSB they would already know the proper response.  Companies doing stupid shit like seizing the property of another person is why money transmission is so heavily regulated at the state level.  State regulation and licensing has nothing to do with AML, it is about protecting clients from illegal actions of companies.  Illegal actions like seizing without due process the property of another person.

I mean you are a logical person, obviously if was the case that a company could just keep funds based on vague terms of service it would be a good way to turn a profit doing nothing.  Sorry before we can complete this transactions we need a copy of your DL ... now we also need a copy of your utility bill ... sorry we also need three personal references ... sorry we need your SSN and written permission to access your credit report .... sorry we also need a notarized copy of your high school diploma ... what you are refusing to comply well we will just keep these funds then. 

http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=017335056cf96e754794b9fe7336e17c&rgn=div5&view=text&node=31:3.1.6.1.6&idno=31#31:3.1.6.1.6.3.5.8

It seems strange that Bitcoin service operators are STILL using VPS.  We have been running bare metal, with a "known good copy" of OS installed remotely using IPMI remote media capabilities.  Nobody at our hosting provider either knows any login credentials or has the ability to reset them.  Whole disk encryption ensures that even physical theft of disk would not lead to data loss.   The funny thing is that even with that I was too paranoid to use a hot wallet for refunds so they required manual processing.

Very large numbers are just as annoying to work with as very small ones.

The OP points out that the JPY for example has a low valued base unit and this results in "large" prices.  Well 1 JPY is worth about $0.01 not $0.000001.

mBTC is large enough to result in small units without excessive decimal places.

i.e.
0.0004 BTC = annoying
40,000 satoshis = annoying
4 mBTC = just right

Well if bitbox intends to use reversal for fraud as a method of returning funds they won't be in business very long.  After the first half dozen fraud reversals their bank will close their account without appeal.

Your MtGox balance is an IOU.  You don't have the BTC they do.  They are just promising to allow you to withdraw your balance on command in the future. 

You can never send part of an output so the only to have no change is either
a) you just happen to have unspent outputs which exactly match the amount you want to send.
b) you send any excess as a fee to a miner

The change address doesn't "have" to the a new address that is just the way the reference client does it.  If you really wanted to you could send the change back to the funding address or to an existing address, or even a dedicated address where change always goes.  The protocol doesn't care.

All the protocol cares is: value of tx inputs = value of tx outputs + miner fee

If you are spending a 10 BTC unspent output the input of the new tx is 10 BTC.
The outputs (including any change address) and any fee to miners must be exactly 10 BTC.

You have counterparty risk with BitPay.  Your funds are as safe as they are.  Personally I believe the risk is very low, BitPay is well run, has deep backing, and shows no signs of financial problems.  I only state this because you said "ANY" risk.

Hedging is pretty easy if your goal is to limit the scope of a potential loss (not try to hedge out any possibility of a loss) it is pretty easy.  Say BitPay on average does <1,000 BTC in business per hour.  They simply hold an unhedged reserve of 1,000 BTC which is already on the exchange and ready to trade.  Now exchange rates will fluctuate and as such the value of those unhedged coins will affect BitPay's balance sheet but they can now do 1,000 BTC per hour (8.8 million BTC per year in transactions) with only the same 1000 BTC at risk. 

So you pay for an order for 2 BTC.  As soon as the unconfirmed 2 BTC hits there wallet they sell 2 BTC on one or more exchanges from their reserve of 1,000 BTC (leaving 998 BTC available for more orders before your 2BTC confirms).  Once your 2 BTC payment has 1 confirm they send it to the exchange and after it posts (6 confirms later) it is sold. In an hour they have the 1,000 BTC back on the exchange again.  This is what we did on FC4B for over a year and it works well.  Essentially a rolling reserve which is always at risk but that allows significantly more volume while the amount at risk stays capped.

As for articles as you pointed out sensationalism is the point.  Sensational articles means more readers and that means more ad revenue.  Always keep in mind those in the "news" business are really in the ad business.  They don't get paid based on accuracy, quality, or completeness.  They get paid based on ad revenue.

They aren't inefficient at mining they are completely incapable of mining.  A quantum computer of insufficient size (in terms of qubits) to "model" the problem can't solve the problem even given an infinite amount of time.   Even if a quantum computer of sufficient size (# of qubits) was built collision resistant hashing algorithms (like SHA) can't be solved using Shor's algorithm.  The only known quantum algorithm is Grover's algorithm which doesn't provide the exponential reduction that Shor's algorithm does.

To brute force a symetric key or hash function requires 2^n operations (attempts) in classical computing.  Grover's algorithm reduces that to 2^(n/2).  There has been little work done in quantum resistant hashes because despite how great n/2 vs n looks one can compensate by simply doubling the hash size. For example if someday a quantum computer could break a 2^256 hash in reasonable amount of time one could go to 2^512 hash (which would require 2^256 operations or 2^128 times as long as that "reasonable amount of time").  We routinely extend hashes beyond what is necessary.  Brute force of SHA-128 isn't even possible using classical computing and probably won't be in our lifetimes (barring some cryptographic break) but we hedge that by using 256 bit (or 512 bit) hashes instead.

For bitcoin mining the issue becomes more complex.  The Grover's algorithm looks for a specific value (which is very difficult in a 2^256 keyspace) but Bitcoin mining isn't that hard.  In Bitcoin mining where the miner is looking for ANY value that is less than the difficulty based on the target.  In other words a miner's job is easier than a simple brute force attack because any hash meeting the difficulty target is "good".  For current difficulty, the target is 0x0000000000000113370000000000000000000000000000000000000000000000 in hexadecimal and there are 1,797,329,777,810,040,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 potential hashes below that target.  

For SHA-256 a QC running Grover's algorithm would require 2^128 attempts to break a specific hash.  However a Bitcoin miner using classical computing can find (at current difficulty) one (of many) hash which is small enough in "only" ~2^56 attempts.  2^56 is still a smaller number of operations than 2^128 even if 2^128 is much smaller than 2^256.  

A common misconception is that QC are "faster" in the sense that a single operation is completed faster which is incorrect.  In actuality they are many many magnitudes slower due to need for retesting to compensate for quantum noise (errors).  They are "faster" because they need to perform less operations. It would be more accurate to say they operate more efficiently.  An analogy might help.  Imagine you have a task which requires 1 second per attempt and on average takes 3,600 attempts to find a solution.  It would take you on average 1 hour to complete.  On the other hand if you could complete the task in such a way that it took 10 seconds per attempt but on average only took six attempts the time to a solution is now only a minute.  Although the individual attempt takes 10x as long the fact that the new algorithm is so much more efficient means the solution is found faster.  This is how quantum computers gain significant "speed" increases.  They are "fast" because they exploit quantum properties to reduce the number of attempts not because each attempt is any faster.

2^128 quantum operations is still greater than 2^56 classical operations even if both systems could complete a single operation in the same amount of time.  At the current time quantum computers are much slower per operation but that will likely decrease with time.  Satoshi did well using a 256 bit hash although SHA-128 for example is essentially unbreakable even with classical computing.  Had he done so 2^64 is pretty close to 2^56 and when difficulty is 20 billion a quantum computer would require less operations than a classical one.  Even then it is unclear if quantum mining would be faster.

FinCEN seems to think it is.  Per the guidance you linked to.


Now it is important to remember that "guidance" isn't new law.  It is suppose to clarify existing law.  Normally it is used in cases where "Z" is regulated, a company is doing "X" AND "Y" which together is not material different then "Z".  FinCEN releases a guidance advising that they consider "X" + "Y" the same as "Z" and thus law/regulation 123 applies even if a company isn't actually doing "Z".

In this case Bitcoin is a square peg.  FinCEN looked at all their regs and they don't have a square hole. They have the MT "hole" but it is round.  The guidance is trying to force Bitcoin (square peg) into Money Transmitter (round hole).  Per the guidance FinCEN is indicating they interpret existing law to define exchanging virtual currency for another virtual currency as money transmission because it is a "value that substitutes for currency".  This makes "logical" sense because that is their rational for why exchanging of virtual currency for real currency is money transmission.  

Since guidance isn't new law, the existing laws on which FinCEN is providing "guidance" on can be found here:
Electronic Code of Federal Regulations -> TITLE 31--Money and Finance: Treasury ->  CHAPTER X--FINANCIAL CRIMES ENFORCEMENT NETWORK, DEPARTMENT OF THE TREASURY
http://www.ecfr.gov/cgi-bin/text-idx?SID=4ed28aff321d97007276a7736cae032e&c=ecfr&tpl=/ecfrbrowse/Title31/31cfrv3_02.tpl

To narrow it down further.
This is the section of the e-CFR on MSBs:  http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=00fd89174701c0486dc0ca18ba1d033f&rgn=div5&view=text&node=31:3.1.6.1.6&idno=31
This is the section of the e-CFR with general definitions:  http://www.ecfr.gov/cgi-bin/text-idx?c=ecfr&SID=00fd89174701c0486dc0ca18ba1d033f&rgn=div5&view=text&node=31:3.1.6.1.2&idno=31
The later is important because the general section defines key terms on things like "money", "transmission", "MSBs", etc.

At the federal level there is no MT license, or specific MT registration. There is only a MSB registration.  When you register as an MSB you indicate the reason for MSB registration.  MT is one of those sub types.  A company declares all the regulated activity they are engaged in and as such a company can register multiple sub types.

Now there is also the question on if a virtual currency <-> virtual currency exchanger is a money transmitter under STATE law.  However get ready for reading thousands of pages of regulations if you want to dive into that one.
1) FinCEN definition only apply to federal law.
2) No two states have the same definition when it comes to the key terms of "money transmitter", "money", etc.
3) Most states probably don't even know the answer to the question at this time.
4) The exact nuts and bolts of the how the exchange works will determine if that specific exchange meets the definition of a MT under any state law.
5) The bad news.  Even if you DON'T meet the definition of a MT under state law that doesn't mean a state won't incorrectly determine that you do and at that point you need to have a plan on what to do.*

* In our case VA believes our company is an issuer of stored value which is regulated under VA law.  We believe we are not.  It isn't that we don't believe issuers of stored value aren't regulated under VA law it is that we don't believe that our economic activity meets the statutory definition.   That belief plus $5 will get you a cup of coffee though.  Either we need to (expensively) convince the state, or (more expensively) fight the state in court, or (even more expensively) accept the incorrect determination of the state and get licensed.  Even if we prevail it will be an expense incurred and a loss of revenue while we resolve it.  Business owners should keep that in mind.  You can be "right" and it still be very disruptive and expensive to get the state to accept that you are right.


Ultimately what matters is what a judge thinks and you should approach it from that direction.  If you think reg "X" doesn't apply and FinCEN thinks reg "X" does apply then eventually (it may be a month or a decade) you both will end up in front of a judge.  If a judge agrees with you then FinCEN "guidance" is moot.  If a judge agrees with FinCEN then you are probably have already (past tense) broken the law and are looking at civil and criminal liability.  "Guidance" is simply FinCEN way of saying "we see it this way and when we take you to court this is the arguments we will use to convince a judge that your activity is regulated".  It is possible that FinCEN guidance is wrong and they will lose in court.  IMPORTANT:  be sure you grasp the risk and the implicit unfairness though.  If FinCEN is "wrong" they don't lose anything (except some taxpayer money).  They either write some new guidance or they ask Congress to pass some new laws because current ones don't cover virtual currencies.  If you are "wrong" then you potentially could lose everything, your savings, your livelihood, your good name, even your freedom.   Eventually most of these issues will end up in court but there is no real case law on Bitcoin or virtual currencies yet.  In thirty or forty years this will be old news (like all the regulatory and legal issues related to non-bank entities and credit cards are now).   Bitcoin isn't just cutting edge technology it is cutting edge application of law and that means risk, complexity, and uncertainty.

DISCLAIMER: I AM NOT A LAWYER.  THE ABOVE POST IS INFORMATIONAL ONLY AND SHOULD NOT BE CONSTRUED AS LEGAL COUNSEL.  IF YOU HAVE A SPECIFIC QUESTION ABOUT YOUR ACTIVITY YOU SHOULD RETAIN INDEPENDENT LEGAL COUNSEL.

Instead of looking at doubling every x units of time how about look at how at a point where network will be in equilibrium at current price.

It will require some assumptions but you can also range these assumptions.

Hypothetical assumptions:
* Miners will not buy new hashpower when annual ROIC% is less than 100% (12 month break even).
* Miners operating cost is $Y per TH/s  (take average ASIC efficiency in terms of MH/J and average electrical rate $0.10?)
* Build cost of new ASIC is $X per TH/s.  Look as Avalon chips in bulk, estimated PCB costs, etc. 
* Market forces will eventually push margin on new units to a more reasonable gross profit of 30%? thus the sale price of new units will eventually be X*1.30

You can then estimate the point where the existing hashing power is large enough that the network is unlikely to rise without a change in conditions.  It is also unlikely to fall much because if it does then marginal miners will buy more rigs or turn old rigs back on.   Condition changes could include a significant (say 50% or more) rise in exchange rate, or the release of next generation ASICs (greater than 100% improvement in MH/J and MH/$).

Once you find this "saturation point" you can guesstimate how long it will take to get there and backtrack from there.