|
I am deleting all animated image posts that I can find.
|
|
|
|
|
1) Well, bitcoin already has an API for transactions, and a test system (testnet) to verify that your software works without losing money.
It would be nice if mtgox/mybitcoin had a merchant API on testnet, to verify that works without dealing with real money.
2) Transactions are not timestamped, but blocks are. IOW, the transaction is timestamped when it is verified by the network, wrapped inside a block. You may combine that with historical exchange prices.
My CPA advises me to note the BTC/USD exchange rate at the time of a BTC-only transaction, as well as noting all BTC/USD conversions of course.
|
|
|
|
I like this idea though what is the extended server info (xslush) for since it can't be supported by the client directly? Perhaps defining the base config well enough such that server specifics aren't necessary.
"xslush" is an example of a configuration that is site-specific, and not standard. Anything with the "x" prefix, at the top level, is fair game for pool servers to define whatever they want, while the other items are those standardized by the community of mining clients. Also, we need a way for the configs to refresh. Either a refresh : seconds option in said config which causes the client to send a HEAD request for the config to see if it has changed or some notification where a server can push the new config out to clients via say an x-config-refresh header.
Yep... |
|
|
|
Currently, pool server extensions such as long-polling provide static configuration information -- the long-polling URL -- via a special HTTP header. This is sub-optimal, because the long-polling URL is unlikely to change, yet many pool servers utilize the simple approach and send the same LP URL to each mining client, over and over again, wasting bandwidth. A server list, used in mining client fail-over (something I have been pushing for), would be another example of static configuration information communicated from pool server to client. Therefore, I began updating cpuminer to download $POOL_SERVER/config.json. This will look something like { "name" : "slush",
"description" : "slush's super-big pool",
"longpoll" : "/LP",
"ntime" : true,
"server_list" : [ { "url" : "http://srv1.net" }, { "url":"http://srv2.net" } ]
"xslush" : {
"my server-specific option #1" : "my value",
"my server-specific option #2" : "my value"
}
}
This should give pool servers a lot more flexibility in defining optional features and metadata, without needing to transmit that information redundantly in every single 'getwork' HTTP header. |
|
|
|
Currently, pool server extensions such as long-polling provide static configuration information -- the long-polling URL -- via a special HTTP header. This is sub-optimal, because the long-polling URL is unlikely to change, yet many pool servers utilize the simple approach and send the same LP URL to each mining client, over and over again, wasting bandwidth. A server list, used in mining client fail-over (something I have been pushing for), would be another example of static configuration information communicated from pool server to client. Therefore, I began updating cpuminer to download $POOL_SERVER/config.json. This will look something like { "name" : "slush",
"description" : "slush's super-big pool",
"longpoll" : "/LP",
"ntime" : true,
"server_list" : [ { "url" : "http://srv1.net" }, { "url":"http://srv2.net" } ]
"xslush" : {
"my server-specific option #1" : "my value",
"my server-specific option #2" : "my value"
}
}
This should give pool servers a lot more flexibility in defining optional features and metadata, without needing to transmit that information redundantly in every single 'getwork' HTTP header. |
|
|
|
As you can see from my participation in that thread, as well as previous ownership and operation of The Bitcoin Store, I'm well aware of FinCEN regulations. I even linked to that FinCEN administrative ruling months ago. That does not preclude nor prevent mtgox from KYC'ing a high-dollar deposit, especially considering that the new owner and servers are both non-US. |
|
|
|
Just one hangup ... Doesn't mtgox have a $1000/day withdrawal limit? I don't see how you could get that many coins out of mtgox in 2-4 months.
IMO if a user is willing to provide full KYC info to mtgox, mtgox should permit removal of that limit. |
|
|
|
Dedicated server pay-as-you-go quotes from xf2.org: - 120 BTC / month:
AMD X2 3400+ Dual-Core, 2x 1.8 GHz, 2x320GB SATA II, 4GB RAM, 100 Mbps shared unmetered - 150 BTC / month:
AMD X2 3400+ Dual-Core, 2x 1.8 GHz, 2x500GB SATA II, 6GB RAM, 100 Mbps shared unmetered
Software setup and management assistance available for a one-time 50 BTC setup fee. If you just need an OS installed, and can handle the rest of the setup and server management, the setup fee may be waived. Discounts available if you pre-pay for a year, instead of month-to-month. Email info@exmulti.com if interested. A free xf2.org account, normally 2 BTC/month, is included with every dedicated server. |
|
|
|
You are using a too-recent version of jansson. Either downgrade to 1.x, or add a '0' for the new flags parameter in 2.0.
Hi jgarzik sorry its my 1st time compiling, how do I include the 0 flag in the cygwin shell? make -o gives the same error 1. You must (a) edit the source code to add a flags parameter to json_loads() function call, or (b) you must downgrade your jansson library to 1.x. |
|
|
|
Thank you for everyone who registered on the site and wanted to participate. I guess in the end our TOS and identification requirements stopped people from completing the registration completely. I sent out about 40 post cards with about a dozen verifying their address and the next hundred or so people didn't even get post cards mailed out to them with their PIN's. I had a total of three people upload their documents out of all the registered people. Just not going to be the correct ratio we need to make things sustainable.
I was wondering what happened, when I logged into the site just the other day, and was not able to enter my postcard code. Yeah, it is really tough to bootstrap. For me personally, I can still sell bitcoins pretty much cost-free, which makes life difficult for any for-profit exchanger... Some information we have received from the Department of the Treasury that may help others or existing exchangers expand their presence in the United States. We asked for a ruling on Bitcoin, and bitcoin is determined to be "Stored Value" and FinCen regulations do not apply if $1000 per day per person is exchanged. Here is a specific ruling on Stored Value that applied to our situation: http://www.fincen.gov/statutes_regs/guidance/html/fin-2009-r001.htmlRedeemers of traveler’s checks, money orders or stored value who redeem more than $1,000 in traveler’s checks, money orders or stored value for any one customer on any day. This is fantastic. I was pretty sure that FinCEN ruling applied to bitcoin, but it is very good to have official confirmation of that. There are some proposed legislation bills in cue to change regulations and Know Your Customer guidelines on stored value instruments. Our goal was to comply with these additional regulations in an attempt to make our bank more comfortable with our business model. The postcard with a PIN was to verify the address of the account holder to prevent someone from say Nigeria using stolen ACH credentials to make unauthorized transactions on someones account.
Do you have a pointer to more detail on this? Thanks, and sorry to hear this is closing. I never saw much about BitcoinUSA on the forums after the initial announcement, but was nonetheless following it with great interest. |
|
|
|
Dedicated server pay-as-you-go quotes from xf2.org: - 120 BTC / month:
AMD X2 3400+ Dual-Core, 2x 1.8 GHz, 2x320GB SATA II, 4GB RAM, 100 Mbps shared unmetered - 150 BTC / month:
AMD X2 3400+ Dual-Core, 2x 1.8 GHz, 2x500GB SATA II, 6GB RAM, 100 Mbps shared unmetered
Discounts available if you pre-pay for a year, instead of month-to-month. Email info@exmulti.com if interested. I'll check stock and see if any older, cheaper servers are available. |
|
|
|
i get this error on osx (using either makefiles). util.c: In function ‘json_rpc_call’:
util.c:132: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast
util.c:132: error: too few arguments to function ‘json_loads’
You are using a too-recent version of jansson. Either downgrade to 1.x, or add a '0' for the new flags parameter in 2.0. |
|
|
|
|
Work on the build process exists at git://github.com/jgarzik/bitcoin.git branch 'autotools'
|
|
|
|
GMT is always +0:00, so why not hardcode that instead of using %z or %Z?
Yep, that should work just fine. |
|
|
|
|
For the record, after my wiki edits were reverted, I wash my hands of the matter. I do not participate in edit wars.
|
|
|
|
If you really have a shitload of money hire a person who knows a lot about BTC trading and has good reputation, I guess he'll be able to arrange trade much better than an outsider would do.
I wouldn't say you need a shitload of money to do that. |
|
|
|
Hello fellow users,
Let's assume I want to buy 200k-400k BTC in the next few months. This represents the number of Bitcoins generated by the global network in 1-2 months, and also about 1-2 months of average volume at MtGox (which indicates most miners resell everything). How do I buy by minimizing disruption of the market?
1/ MtGox's volume info includes the dark pool. Based on the known volume (~7k BTC/day) it is not large enough to avoid a price eruption.
MtGox has seen some 100k+ days. One method is simply buying slowly from MtGox over the next few months. 400k / 90 days == 4.4k per day, something the market can absorb IMO. But even if you double the volume, there is not going to be a huge disruption. Yes there is a tipping point, but I wouldn't necessarily judge MtGox by the current slow period. 2/ There is not enough liquidity from my viewpoint on any other markets, including the OTC market.
Agreed, though you might try some of the manual exchangers such as nanoimogold or aurumexchange. They probably have a stock (where "stock" is a few thousand bitcoins). 3/ I could invest the money in a mining farm, but I would probably need to hire someone as it seems time-consuming.
vladimir, mrb and BitcoinRigs offer something vaguely similar: You pay for Ghash/sec, and they give you zero-variance BTC payouts based on the purchased hash rate + current bitcoin network difficulty. But this is quite expensive, and you'll reach a point of diminishing returns rather quickly, much more quickly than your goal. The bitcoins are definitely out there to be had, as the price increases. MtGox makes life easy and should accomplish your goal over time, but I bet you can find a fair amount by canvassing various community exchangers. |
|
|
|
Feature request: "sendmany" for CoinCard. [Tycho]'s use of coincard's paypal API is pretty neat, and I was thinking of doing something similar. However, if I have a queue of paypal payments to make, it would be much more useful to send a single, large BTC transaction to coincard, and specify multiple (address, amount) pairs for paypal recipients. Bonus points if this can be done entirely via JSON  |
|
|
|
|
Escrow.com's fee for transactions over $25,000 is 0.89%.
Clearcoin's fee for large transactions is 1%.
With the BTC buyer using escrow.com and the BTC seller using clearcoin, I bet something could be arranged.
|
|
|
|
|
Show Posts
