But frankly, I am not seeing FinCEN going after Bitcoin itself. I'm sure they are quite dumbfounded as to how to do such a thing. But what they can do is put pressure on any legitimate entity that hooks up to it in a formal way.
Perhaps not FinCEN, but financial reporters at anti-money laundering conferences report that the FBI is "very aware" of bitcoin, as is the SEC. The leaked FBI report on bitcoin was quite knowledgeable and matter-of-fact. Yesterday's FinCEN guidance makes it seem more likely that LEAs would target individual criminals, rather than bitcoin network and users en masse.
|
|
|
For purposes of regulation, it doesn't matter how the money gets to Japan. It must be monitored for money laundering activities. Dwolla will not be able to continue to escape this.
Recently, my one-person microbiz had to AML/KYC with Dwolla, to continue transferring to/from MtGox. Based on my experience and conversation with the Dwolla employee, it sounds like this is a special procedure for MtGox, that does not apply to most other dwolla users.
|
|
|
In my estimation, e-Wallets are perfectly safe right now from government prying both implicitly and explicitly. They will go after the exchanges first. Anything connected to the US dollar -- they can squeeze that with existing policing infrastructure. BTC to BTC seems impervious to me right now. There are simply no mechanisms built to police it. Time will tell though, but I believe some of the earlier commenters are right that there will always be another "alternative route" to exchanging and/or storing your BTC value.
That's very interesting, thanks. Agreed on "seems impervious" (we hope) and that existing policing mechanisms seem scant, but may I challenge you with a highly specific question: Consider a US-based entrepreneur and company running a purely bitcoin-based e-Wallet service on US soil. Pick your US state, excluding New York and California. Could the entrepreneur run this e-Wallet without contacting any regulators[1]? One of the projects discussed on IRC was an IRC micropayment bot, which is nothing more than an IRC-based e-Wallet. Easy to code and run, but seems like it might run afoul of regulators. Would love to be proven wrong [1] Besides the standard ones needed to operate a US corporation, such as the IRS and state-level tax dept., municipal business licensing, etc.
|
|
|
If you are into Bitcoin to follow laws, I will just laugh at you.
Some of us want bitcoin to be useful to the whole world, not just the teenaged lawless/anarchist part of it.
|
|
|
Looks like mining and converting BTC to USD is now illegal unless you are a licensed corporation with hundreds of thousands for licenses and bonding requirements. Hardly. US miners will just have to AML/KYC with a regulated US bitcoin exchange, to get US Dollars. It is also doubtful that regulators even care about small time miners. Pool operators might be a grey area, on the other hand.
|
|
|
It always made sense that US Government would monitor and regulate gateways to/from US-Dollars (bitcoin exchanges, in this case).
I am curious about purely bitcoin e-Wallets: users of this service can (a) deposit bitcoins, (b) send bitcoins to a specified bitcoin address, or (c) send bitcoins to another user of the service. No USD involved at all.
Where do purely bitcoin e-Wallets fall, in the regulatory realm?
|
|
|
By the way, what's up with the bizarre Flicker API? It's been a while since I did any kernel programming, but is there some jihad against adding new syscalls? Writing single character commands to a control fd seems like a very strange way to do things vs just invoking a syscall with the set of params being marshalled that way.
The general trend, in the Linux kernel at least, is to base everything around a poll-able file descriptor. Google for "epoll_create", "signalfd", "eventfd", "timerfd_create", etc. New syscalls take a long time to fully deploy on some platforms, and are often under-used for that reason. It is easier to create a driver that services standard, long-deployed file descriptor syscalls: read, write, poll/select, etc.
|
|
|
Respectfully, I disagree entirely with that interpretation. If you mine and sell via an exchange that is MSB/MT-registered, seems like you are ok.
|
|
|
With the standard "I Am Not A Lawyer" disclaimer, my read is that miners might be ok if - They sell bitcoins for fiat, via a licensed exchange
- They purchase goods and services entirely within the bitcoin economy
The first is obvious. The US government is certainly within their rights to regulate the US Dollar, and ditto for other government fiat currencies. The second is vastly positive. Stimulative for the bitcoin economy, encouraging a broad market of services priced in bitcoins. And the third, more general point is implied: bitcoins are legal for regular users to possess and spend.It is true that bitcoins were never illegal, but having a big government issuing an affirmative statement "bitcoins are legal" (in effect) is great news.
|
|
|
tl;dr... bitcoins are legal
And you need a +$1million dollar worth money transmitter license if you want to mine and sell them for fiat I don't read it that way at all... assuming that the miner is selling via a licensed bitcoin exchange (MSB/MT).
|
|
|
tl;dr... bitcoins are legal
|
|
|
This whole thread reminds me of a book I read a couple years ago called "Daemon" by Daniel Suarez.
You mean the book that was mentioned twice up-thread already?
|
|
|
Domains for sale:
bitbanc.com
emultipay.com
fxbit.com, fxbit.co
smartcoins.co, smartcoins.net, smartcoins.org
apistor.co, apistor.com, apistorage.com
PayPal or bitcoins accepted. Open to any reasonable offer.
|
|
|
On the other hand maybe oversize blocks should have been tried longer with pre-0.8 versions? Or were they but no one was watching orphans to notice 0.7 was orphaning some of them due to a database problem?
1MB blocks were tested long, with 0.7 and before, on testnet. The problem was not the size of the blocks.
|
|
|
It's not the miners who make the call in the max_block_size issue, right? I mean, all the miners could gang up and say: "we're not going to process blocks with more than 2 transactions," if they wanted too. It's the validating nodes that make the call as far as what will be a valid block. If all the nodes ganged up, they could change the limit as well.
Correct. Any miner that increases MAX_BLOCK_SIZE beyond 1MB will self-select themselves away from the network, because all other validating nodes would ignore that change. Just like if a miner decides to issue themselves 100 BTC per block. All other validating nodes consider that invalid data, and do not relay or process it further.
|
|
|
2 blocks is 50. That's pretty impressive, are you strictly solo mining now?
Yes. Are you solo-mining through your own pool software or directly to bitcoind?
bitcoind + eloipool. cgminer does not support direct-mining to bitcoind. It appears to work, but eventually HTTP problems and other oddness appears. Luke-Jr's BFGMiner should support ASIC mining directly with bitcoind, but I think Luke-Jr is still looking for a volunteer to test BFGMiner + Avalon.
|
|
|
For reference, my Avalon miner solo-mined two blocks in the past 24h (50 BTC + fees).
Statistically this was quite lucky, of course.
Or maybe your friend should sell them for nnnn BTC + a percentage of ongoing revenue for 1 year.
|
|
|
Well, I just earned 50+ BTC last night solo mining. Are you just using a computer running the bitcoind server for this or do you actually have a pool software (like stratum-mining) going that only you're using? I didn't figure the bitcoind server would be responsive enough to handle the requests from the ASIC's in a timely manner, but I don't really know much about that system. Sadly, mining to bitcoind directly does not work well. I use eloipool with bitcoind.
|
|
|
Global difficulty probably wont be for a while. Eligius, surprisingly, has quite a few very low hashrate miners still. So, global difficulty increase could make some of them submit only a few shares per day!
Correct. They will get paid the same rate, and it reflects the increased network difficulty.
|
|
|
|