|
I would just caution anyone thinking Reg D (Sec rules 504-506) is an easy loophole to think again. It is a legal mine field and in the US one is subject to both federal securities law and state securities law. If the company is in VA, the potential investor is in NJ then that is three sets of securities laws (Federal, NJ, and VA) that the offering needs to be compliant with. Often the states have incompatible requirements. In VA for example it is simply defacto impossible to offer anything under Rule 504 due to the way the federal and state regulaitons conflict. Lastly I would point out that Reg D is intended for PRIVATE securities. Running a trading exchange is going to blow any cover under Reg D wide open.
Generally Reg D really only makes sense if you are looking to raise $5M or more in equity because because the legal and regulatory costs you are going to spend a couple hundred grand just getting the offering off the ground. Hopefully the "crowdfunding" provision of the Jobs Act will make it easier to RAISE capital but it was never intended to allow to make it as easy as "ebay for stocks" or allow any type of public trading.
|
|
|
|
I've been doing a lot of research mysel recently. I agree with most points made in your article. The most damning of all for the SEC is that I do not believe they could consider bitcoin a currency, for any jurisdiction to consider it a currency (legal tender) would surely have to accept it as payment against tax debt, etc. However, that may not improve things: They could consider it a commodity. Something does not have to be a real, tangible item to be a commodity. In the USA energy is a commonly traded commodity. Thus I suspect asset issuers in the USA would be subject to regulatory controls by the Commodity Futures Trading Commission (CFTC) on the bitcoin side, AND the SEC for the regulations around how they have to deal with their shareholders. Simply trading a security using a commodity does not release that security from regulatory requirements. If you want to be legit, there's likely no getting around the fact that we're dealing with securities. Their definition of a security is pretty complete: (1) The term "security" means any note, stock, treasury stock, security future, security-based swap, bond, debenture, evidence of indebtedness, certificate of interest or participation in any profit-sharing agreement, collateral-trust certificate, preorganization certificate or subscription, transferable share, investment contract, voting-trust certificate, certificate of deposit for a security, fractional undivided interest in oil, gas, or other mineral rights, any put, call, straddle, option, or privilege on any security, certificate of deposit, or group or index of securities (including any interest therein or based on the value thereof), or any put, call, straddle, option, or privilege entered into on a national securities exchange relating to foreign currency, or, in general, any interest or instrument commonly known as a "security", or any certificate of interest or participation in, temporary or interim certificate for, receipt for, guarantee of, or warrant or right to subscribe to or purchase, any of the foregoing.
The good (GREAT) news is that the new JOBS act in the USA makes crowdfunding a whole lot easier and as far as I can tell, having read through several summaries of the stipulations, the securities issued (using commodities) will fit just fine into the new exchange I'm working on. The JOBS Act creates a new exemption from registration for securities sold via crowdfunding offerings, so long as certain criteria are met, namely:
(A) no more than $1,000,000 is raised via crowdfunding in any 12 month period; and
(B) no single investor invests more than a specified amount in the offering, namely:
i. the greater of $2,000 or 5% of the annual income or net worth of the investor, as applicable, if the investor has annual income or net worth of less than $100,000; or
ii. 10% of the annual income or net worth of the investor, as applicable, if either the annual income or net worth of the investor is equal to more than $100,000, capped at a max of $100,000 invested.
(C) the offering is conducted through a registered broker or “funding portal” (a new term made up by the JOBS Act); and
(D) the issuer registers with the requirements below.
(a) name, legal status, address, website, etc.
(b) names of directors, officers, and 20% stockholders
(c) “a description of the business of the issuer and the anticipated business plan of the issuer” – the devil is really in the details of this one, and it remains to be seen whether the SEC will require this “description” to be 4 pages or 40 in order to be sufficient
(d) prior year tax returns, plus financials – see below for details
(e) description of intended use of proceeds
(f) target offering amount, deadline, and regular progress updates through the life of the offering
(g) share price and methodology for determining the price
(h) a description of the ownership and capital structure of the issuer, including a lot of detail about the terms of the securities being sold, the terms of any other outstanding securities of the company, a summary of the differences between them, a host of disclosures about how the rights of shareholders can be limited, diluted or negatively impacted, “examples of methods for how such securities may be valued by the issuer in the future, including during subsequent corporate actions”, and a disclosure of various risks to investors
Much of that could be accelerated for the asset issuers via pre-prepared documents or a "registration wizard". Short term though, I suspect my exchange is going to be a virtual stock exchange trading in virtual currency and virtual securities. It will join the ranks of 100's of other sites out there that let you play stock trading simulations to study and learn about the financial industry's terms and trading process. Before you get so excited the "Jobs Act" crowdfunding doesn't do what you think it does. 1) You will be required to collect KYC and AML information of all participants (primarily for taxation reasons). 2) You will need to be a registered broker dealer (up front cost is in the tens of millions) or a registered crowdfunding portal. 3 and this is the killer) Crowd funding portals are prohibited from offering ANY trading. Period. With no exceptions. So even registered and licensed by SEC and with all anonymity removed GLBSE wouldn't be compliant under the Jobs Act unless it was a full broker dealer. As a crowd funding portal it could simply facilitate the selling of the initial offering of securities. No reselling or trading. While the crowd funding provisions in the Jobs Act are a step in the right direction and will help small biz raise capital in a more efficient manner those thinking it is some kind of silver bullet are going to be sorely mistaken. To be licensed under the SEC a "GLBSE like entity" would need to be registered broker dealer with the mountains of paperwork, legal provisions, due diligence, underwriting, and reporting requirements that come with it. |
|
|
|
Wasn't sure where to post this, so I thought I would post it here
If you guys haven't heard about FATCA, you should look it up. It's major US legislation, set to go into effect in January 2013, that requires all International Financial Institutions with American account holders... I just tried to fact check your statement about facta: So uhm... cool story, bro. When did you say this was going into effect?     You reversed the letters. Not FACTA - Fair and Accurate Credit Transactions Act of 2003 FATCA - Foreign Account Tax Compliance Act of 2010  The US has so many laws they are running out of abbreviations. http://www.irs.gov/Businesses/Corporations/Foreign-Account-Tax-Compliance-Act-(FATCA) http://en.wikipedia.org/wiki/Foreign_Account_Tax_Compliance_ActAn interesting factoid. Belize has refused to comply with the provisions of FATCA. They also don't respect the authority of any foreign courts when it comes to subpoena of financial information.  |
|
|
|
|
Update:
FastCash4Bitcoins will be transitioning to a new dedicated server this weekend.
The site may be temporarily unavailable at times. We will provide an update once the transfer and DNS change is complete.
|
|
|
|
|
The real answer is you need legal counsel.
The simple (I am not legal counsel answer) is the SEC regulates the issuance, underwriting, and trading of securities in the United States. If you offer securities involving American companies/assets/real-estate/etc or to offer securities to American residents then you are subject to their jurisdiction.
The various laws and regulations involving securities could fill a small apartment. It is a massive legal minefield even for relatively straight forward operations. There is nothing in the SEC regs which limit the securities subject to regulation to ONLY those bought and sold with USD. If you were in prison and offered CFD contracts on the price of a pack of cigarettes and inmates paid monthly premiums and margin in cigs then it would still be subject to SEC oversight and regulation. Now in the real world the SEC does have limited resources. They don't go after every small biz raising capital but once again the idiots who dumped $5M into Pirate's oh-so-obvious ponzi scheme suddenly made it "big" enough to get the SEC attention. The passthroughs on GLBSE were a large funnel to feed the ponzi machine. It is asinine to think the SEC would investigate Pirate but not GLBSE. Now that it has their attention they can't just "let it go" doing so would be a defacto acceptance of the status quo.
|
|
|
|
|
Correct. The protocol doesn't support a "datafield" in transactions. There are ways to hack around that but it will suffer from the same issue as digitally signing with private keys, lack of universal support. Bitcoin is already a tiny market, putting up barriers to commerce is going to be counter productive. If you generate a new address per order and record it in your order database and then monitor open orders for funds it will be universally compatible with all clients. I would also point out it is how bitcoin users "expect" transactions to work so any administrative/support costs are going to be much lower.
User checks out.
Site provides user a unique one time use address (behind the scenes the assigned address is stored in the "orders" table of the database).
User pays.
Site has a monitoring daemon running which monitors (using bitcoind or some other client/app) all open orders.
Site updates order/confirmation page to reflect payment status.
|
|
|
|
|
Wallet vs Address. One thing in your post which may be part of the problem is the use of terms like "wallet #". The network has no concepts of wallets. There are simply addresses. A transaction moves funds from one address to another. In the case of paying for goods and services a user moves funds from an address he/she controls to an address the merchant controls. A wallets may have more than one address (likely has hundreds) but the network has no knowledge or concept of wallets. It just verifies that a tx is valid (sends funds from an valid address, to a valid address, the inputs have proper qty of coins, and the tx is properly signed by the owner).
So you as a merchant you should probably just assign a unique address to each order/user. You can pretty trivially generate thousands or even hundreds of thousands. Then when the address is paid the order is paid. It is the simplest method, essentially foolproof, provides universal support, and trying to do anything else is just trying to force a round peg into a square hole.
Still as an alternative you could have users sign a message using the private key of the address they sent funds FROM. So if a user sent coins from address 1123456 you could ask them to sign a message with the private key for address 1123456. Only the user with access to that private key could accomplish that. Still that isn't a very good solution as not all wallets support that. Even among wallets which do support it, users may not understand how to do it properly, and you add the extra steps of needing to request a signed message, the user sign a message, the user sends you the signed message, and you confirm the signed message. A lot of extra work that when combined with the fact that not all wallets support it will lead to lots of confusion and problems.
|
|
|
|
|
Bitcoin is "Bitcoin's silver" learn about how/why multiple metals evolved as currency and you will see Litecoin isn't silver to anything.
Now hypothetically niche alt-coins "could" develop in the future however they would need to solve some deficiency in Bitcoin (no the method of mining isn't a deficiency). It is also possible some future alt-coin will replace Bitcoin (becoming a superior "gold") by providing a superior protocol. However litecoin isn't going to accomplish either of those goals.
One example: Bitcoin likely will be increasingly difficult to use in micro transactions. The cost of securing the chain, combined with the perpetual cost of storing tx forever makes it ill suited for small tx (say $0.01 to $1.00). A chain developed which can be merge mined and use a ledger type system which allows the transaction "tail" to be dropped after tx are deep enough in the chain would be useful. By focusing on the aspects that would be optimal for micro tx the alt-chain could present REAL UTILITY =VALUE over the competing Bitcoin protocol.
Litecoin doesn't present any increased UTILITY. It is a technological dead end.
|
|
|
|
Most clients do employ a checkpoint (which is updated from release to release). It is important to understand there is no centralized registry of checkpoints it is up to each developer to implement checkpoints (if any). I believe the Satoshi client latest checkpoint is at roughly block 180,000. Individual nodes will reject any block submission prior to block 180,000 if it already has a valid chain. Also when bootstapping (no blockchain) individual nodes will reject any chain who's block hashes don't match the checkpointed hashes. On edit: Would have been smarted to just read the code. https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp static MapCheckpoints mapCheckpoints =
boost::assign::map_list_of
( 11111, uint256("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
( 33333, uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
( 74000, uint256("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
(105000, uint256("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
(134444, uint256("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
(168000, uint256("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
(193000, uint256("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
;
So currently the first checkpoint is at block 11,111 and the last one is at 193,000. One potential area of "attack" (and it would be a relatively weak one) is that the checkpoints are sparse. There is ~30K blocks between checkpoints. So a "bad node" could flood a node who is bootstrapping (building the historical blockchain). Now once the node hits a checkpoint (i.e. block # 11,111) the bad node will not be able to complete that chain. However the bad node could switch and provide correct blocks (possibly via another node) through block #11,111 and then provide another 22,222 bad blocks. Since blocks can be built to have a large amount of transactions a "bad node" could greatly increasing the processing requirements of good nodes. This could be mitigated by providing a complete "checkpoint list" of every blockhash up through the last checkpoint. (i.e. the code above would have entries for blocks 1 through 193,000). On edit: I like Gavin's idea better. For lots of reasons it would be useful if the protocol allows pulling just block headers. It solves not only this weak attack (which shouldn't be a priority to fix) but also makes the protocol more robust. In general nodes are relatively "naive" in dealing with misbehaving nodes. Likely as time goes on the method of picking peers will need to be enhanced. Essentially the node would keep track of all its current nodes plus all known but not connected nodes. Nodes which provide bad data, continually spam already known data, have high latency, relay tx significantly slower than peers, etc could be scored down and once they fall below a threshold the node would send them an error message, and ignore them for some period of time. The node could then attempt to connect to a new known but not yet used node. The code currently does a little of this but it could be expanded to make the protocol more hardened. Nodes could also employ digital signatures which would aid in building a "web of trust". For example if I trust MtGox and blockchain.info I could mark their "node public keys" as trusted. They would be scored higher, the protocol could be expanded so when I query a trusted node for other nodes it not only gives me a list but also their scores. The whole "if I trust you then I can trust people you trust too" concept. |
|
|
|
Well two things: 1) Microsoft provides MD5 hashes for all their ISOs. While I don't condone piracy it is possible to use cryptography to verify that any ISO (obtained from anywhere) is bit for bit identical to the official release. http://support.microsoft.com/kb/8412902) If you are serious form a company and apply to Microsoft Bizspark program. All the software you could possibly need for three years (including perpetual licenses and buyout option). |
|
|
|
What will it matter if 'merica is gone in ten years?
Why would you pay to pirate software? Does that even make sense to you? Legally there is no difference between paying for a fraudulently license or just pirating the software for free. |
|
|
|
|
Yeah I see the wording was just kinda weird. Also I would point out that ASICs have an interesting cost structure. A very high upfront cost (NRE) and a very low unit cost. The non-NRE per unit of the ASICs offered likely is 30% or less of the current retail price. This means that when sales slow (because market becomes saturated and ROIC% plummets) BFL and other ASIC providers can slash prices. If difficulty skyrockets to say 100 mil a Single at 108 BTC doesn't look so attractive but a Single selling for 50 BTC suddenly looks much better. It can be only 50 BTC because the price of USD:BTC has doubled but it also can be only 50 BTC because BFL cut the price in half.
|
|
|
|
|
The price doesn't need to go anywhere. It is very possible that some miners have naive expectations and so much hashing power will be sold that it pushes prices out to a 33% annual ROI (3 year break even). As the market becomes saturated some miners may become disillusions and simply sell their rigs for a loss.
Price drives difficulty but difficult doesn't drive price.
|
|
|
|
Ahhh I see. Thanks for the response, I agree with your numbers if the network speed increases 10x. Those numbers are indeed pretty dim. However, I do not think that it will be as bad as the numbers make it seem.
Based on what I've read, I assume like you there will be around a 10x increase in network speed by January. But, I am of the opinion that the BTC per USD exchange rate will increase in between now and then, making it a little more profitable than that. Counting on future price increases is kinda silly. There is another way to profit from future price increases. Simply own bitcoins. Still the point is that if network capacity can increased 10x at current prices future prices are unlikely to provide you much long term support. Once NRE is paid for ASICs have massive per unit profits. Those margins will eventually come in and that means much lower prices. So say USD:BTC doubles! Sweet back into the big money. Except BFL et all can simply cut their prices 50% in 2013 and sell another 400TH/s of mining gear (bringing hashing power to ~600TH/s) that causes difficulty to triple again to ~90 million. Mining is a fixed sum game. Now in "GPU land" there was possibility for miners to "protect their margins. Electricity was a larger portion of lifecycle cost and thus if you mined in a low electrical environment you could gain an advantage. Efficiency (MH/J) also varied significantly depending on components and skill. Anything from sub 1 MH/J all the way to up 5MH/J. If you combine a highly efficient set of rigs with a low electrical cost environment you could really improve your relative standing. Lastly running a major farm takes skill and dedication. It isn't plug it in and throw a switch. I only got up to 15GH/s and trust me it is a "hand on" operation. Everything gets more complicated as you get bigger. Electrical supply, cooling, replacement parts, networking, etc. ASICs are essentially plug and play. TL/DR summary: there is less difference in relative efficiency of ASIC miners thus the race to the bottom in terms of yield is going to be accelerated. Note I am not saying don't buy an ASIC, just think about all the ramifications. Mining isn't a get rich operation and the days of 3000%+ APR aren't ever coming back. In time I think most well run large mining ops will earn about 7% to 15% ROIC (thats annually ) which is inline with other commodity producers. |
|
|
|
If the satoshi client discarded unused keys, then I would not have all the old unused keys inside the new encrypted wallet. My experiment had 108 old keys (I think I have 8 transactions). The new encrypted wallet has 208 keys, 108 from the old wallet including used and unused keys, and 100 more new keys.
I used bitcoin version 0.7 (the one just released) for Windows, and pywallet to export the keys from both the old unencrypted wallet, and the new encrypted wallet.
The difference between the two is I just encrypted the wallet, then I made a backup of the encrypted wallet.
Or maybe it's just my wallet since I created it when it was version 0.5 or so at the time (March 2012). Maybe the behavior for new wallets is different than for old wallets created with an old client? But I remember upgrading my wallet to a newer format (maybe it was version 0.6)
Weird. Maybe CIYAM is right. To avoid losing funds in the event a key was used in a non-standard way (say from a keydump) it probably doesn't delete them just marks them so they will never be used in future tx by the client. I didn't notice another part of your question. You can make the keypool smaller if you wish. 100 is the default (IMHO should be larger given the trivial amount of space) but you can set it to any value even 0. With keypool=0 you have no keypool the only keys in the wallet will be existing keys and new keys (when needed) will be "created on the fly". NOOB WARNING (not you dabs but anyone who happens to read this): with a keypool of 0 you would need an updated backup after every tx involving a new key ("new address button", or spend w/ change) to avoid the risk of irrecoverable loss of funds. Still all of this is somewhat academic. Deterministic wallets are the future. The ability to backup and/or print an encrypted deterministic seed and thus avoid a whole category of potential data loss scenarios provides huge value in making bitcoin "easier to use" while providing no real risk/downside. |
|
|
|
Actually, I prefer that the default keypool be made smaller. But that's just me, I don't have 100 transactions, and it is convenient for me to just take care of a dozen keys.
In my experiment, which anyone can duplicate, the newly encrypted wallet contains all the old keys AND 100 more new keys. The old keys are not useless, but the new keys will not yet have been backed up.
It's possible that the client just picked a key at random to send the change and it just so happens that it was not one of the old keys.
Not exactly it is important to understand there is a difference between keys in the "active/used" wallet and keys in the keypool. The keys (i.e. used keys) in the wallet transfer over. Obviously they would have to or you would lose all coins associated with those keys. The entire keypool is erased and new keys generated. The Satoshi client always uses the next key in the keypool for change. It is never up to chance. Also a larger keypool doesn't increase your administrative burden. If you are doing manual extraction/key work on a wallet the keypool represents "future" keys. 100 or 10,000 it doesn't really matter. If you only have a dozen active keys you simply need those keys. TL/DR Used/active keys =/= keypool. The satoshi client always uses the "next" key from the keypool for change and new addresses. |
|
|
|
If you guys don't do it than the rest of the slots become FREE for who ever wants them paid for by yours truly.
Um no once again. You are limited to one bid on one slot. Any unsold slots are simply unsold. If 40 slots sell then each slots 1/40th of the total impressions. If 48 slots sell then each slots is 1/48th the total impressions. If all 52 sell then each slots is 1/52 the total impressions. So no the rest don't become free, the rest don't get bought by you. Those were the terms specified by theymos and I doubt he is going to break his word mid auction just because you feel the bids are too low. |
|
|
|
|
Yeah your rate may vary but here is my info as an example.
Electrical rate (total charge to the wall) $0.07 per kWh
Natural Gas Rate (total charge to the wall) $0.83 per ccf
1 cubic foot of natural gas has 1020 BTU.
nat gas is usually metered by the 100 cubic feet (ccf) so thats 102,000 BTU
1 kwh is 3412 BTU
So cost for 1 million BTU (arbitrary but I hate working with tiny numbers)
Natural Gas: $8.42 (1,000,000 / 102,000 * $0.83)
Electricity: $20.52 (1,000,000 /3412 * $0.07)
Now electrical resitance heating will always be 100% efficient (it simply can't be anything else). A good heat pump (as long as you outside air doesn't get below 20F or so) can be 200% to 300% efficient but that doesn't apply to mining.
At best a furnace* is going to be 97% efficient but most are in the 80% range. Still at $8.43 / $20.52 = 41% even a malfunctioning furnace operating at 50% efficiency is going to be cheaper. Nat gas is just crazy cheap in the US. We keep finding more and more of it. Hell they might start bringing back natural gas fired heat pumps again.
* Since there seems to be confusion by furnace I mean a device which burns combustible material (i.e. natural gas, propane, fuel oil, wood, garbage, human waste, etc). Electric heat would be either resistance (100% efficiency) or heat pump (COP of >1 = >100% "efficiency"). At least in the US using the term furnace to refer to electric heat would be uncommon.
|
|
|
|
me too.
Listen when this auction is over - whatever slots that are remaining out of the 52 - I will pay for them - matching the lowest offered price - and maybe we can just give them out to donators, or vip members or to people who want to advertise something but cant afford them. I don't know you can figure out who they go to.
But I want to support the forum so I am willing to personally match the lowest offered price in this auction for however many slots are left and you can allocate them however you want. I am sure you will give them to good causes.
That wasn't the terms specified by theymos. If less than 52 slots are sold then the sold slots simply have a larger share. If you are concerned about the profitability of the forum you could always make another donation. |
|
|
|
|
Show Posts
