Your wallet generates a new address every time you receive a payment.
Also, almost every time you send a payment. |
|
|
|
|
Wait, are you telling me that my bank doesn't keep the funds for my accounts in three different shoeboxes in the vault?
|
|
|
|
MX records are not necessary for mail delivery. They are only needed in complex domains, or when backup servers are desired. |
|
|
|
Well...it really depends on what exchange you use and how they process orders...you didn't say which exchange.
My exchange engine I'm building won't allow you to place a sell order lower than the current buy order or vice versa. Instead, my engine directs you to perform an instant trade instead of a market order.
Don't take this the wrong way, but this is the way you'd design an exchange if you see gambling or amusement as the primary purpose. If you see those as a sideshow around the primary purpose of buying and selling BTC, you'll do everything as limit orders. |
|
|
|
Now I'm at Total time logged in: 4 days, 7 hours and 45 minutes. Most of the time that I spend on the forum isn't even logged (when I'm in the other room lurking on my iPhone). Noob.  10 days, 15 hours and 48 minutes. |
|
|
|
|
My main email address has been out there in the public eye for close to a dozen years now. It has been posted on forums, websites, mailing lists, and even, God help me, USENET.
The throwaway address that leaked out of mtgox gets VASTLY more spam.
|
|
|
|
|
Something is preventing it from accepting incoming connections. Probably firewall or NAT.
|
|
|
|
|
This is actually a matter of exchange policy. Almost all exchanges go with the price on the older of the two orders in the match, but you need to check with the exchange to be sure if the exact behavior matters to you.
You should never tell an exchange that you are willing to accept a price that you aren't actually willing to accept.
|
|
|
|
|
Your client hasn't processed the block chain yet. We are currently on 139,025.
|
|
|
|
I guess they just couldn't let us have our record breaker  . correct me if im wrong here... but wont this record keep going up as a function of the difficulty? edit: I still have not found a block at btcguild. I have 2.98Million shares accepted here... Yes, it will. The current difficulty is the expected average number of shares needed to find a block. But a round taking 10 times the expected shares is very unusual. |
|
|
|
I can think of at least 3 solutions. Solution 1, the unique server IDAssume that the nonce can be up to 19 digits long (64 bit int). Subtract 10 digits for the current unix timestamp. Figure out the maximum number of machines you'll ever have, take X=ceiling(log 10(#)). Now, take 9 and subtract X. Whatever you get is the number of digits to take from the front of the microseconds clock when making the nonce. So, if you expect not more than 10,000 machines, X will be 4. So in your mtgox code, you use $req['nonce'] = $mt[1].substr($mt[0], 2, 6).$unique_id_for_this_machine;
Relay all of your requests through another box that calculates the nonce and signature. Solution 2, start overSeriously. What sort of distributed system needs access to an exchange? |
|
|
|
|
The client with 8 peers is not getting incoming connections. Check to see if that ISP is doing NAT, or your firewall settings, or the maxconnections value in bitcoin.conf.
|
|
|
|
You can immerse any computer component into a water tank - just make sure the water has been purified to remove the conductive minerals.
Huh? Any references to back this up? It is pretty well known that water itself isn't a conductor. http://en.wikipedia.org/wiki/Electrical_resistivity_and_conductivityThe table gives a rho value of 180,000 ohms per meter for deionized water. But deionized water doesn't like to stay deionized. You'd be better off using Flourinert. |
|
|
|
Look i know we seem impolite, but we have heard this again and again and again and again from almost day 1. It gets bothersome after the 100th time and after the 1000th time we get a little short tempered. When something new is brought to the table we debate and come to our own conclusions, you have brought nothing new to the table, your just rehashing a point we have all heard 10 times today alone. We sound like an echo chamber simply because we have already debated this with the guy before you and the guy before him and so on and so forth. I apologize on behalf of this form but i really cant blame them for being like this after dealing with the exact same questions brought up every 10 minutes each time the author believing that he was the first one to see this terrible problem, and reiterating that we are en echo chamber simply because we reached a consensus the first time someone asked this question.
+1 |
|
|
|
|
If you expect a lot of services to show up and offer these, you are going to need to find a way to negotiate which providers are acceptable to a merchant.
|
|
|
|
People make wrong assumptions based on stupidly small and biased samples. You are a good example of this. You don't know all stereotypes, in fact it's likely you only know a small fraction of stereotypes and that fraction is biased by geography and self-selection and generally poor education in statistics and/or logic (i.e. not understanding that even if most avid shoe shoppers are women does not imply that most women are avid shoe shoppers). From this you have generalized that this says something about all stereotypes. Not only that but I'd wager you probably don't know many of the true values (i.e. How many Americans really are X).
This one paragraph wins. It is so full of stereotypes about people that believe in stereotypes that I imagine you must have been smirking in irony as you typed it. |
|
|
|
Yes, I have read the white paper, and yes, I understand it. The point being argued, at least that I was arguing, is against this notion that 51% is some magical number. The kind of attacks that 51% enables are also possible with less than 51%, is what I am saying. I agree with you that the chances of success are very low; but they're also very low at 51%, and only slightly lower at 40%. At 51% hashing power you have to 'get lucky' to generate blocks so rapidly that you have a chance to muck with the block chain, and at 40% you also have to get lucky, just a bit luckier.
51% is a magic number. For an offline attack, 51% is the point where if you start right now, you can be sure that you will be some number of blocks ahead in the future, if you wait long enough. Really 50% + 1 is the magic number, but we round to 51%. Additionally, I am not sure how miners handle pending transactions that they've already seen in a block. Do they drop all transactions from their 'pending transactions' queue whenever they see a block with that transaction in it, on the assumption that they will never want to try to put the transaction into a block again since in the 99.999% of the cases where blocks are valid, they really will never want to try to put that transaction in a block again. If they do, then one fork in the block chain propogated to a significant number of miners has a good chance of either severely delaying transactions (because they are now only in the pending queues of the remaining miners who *didn't* see the forked, ultimately-doomed, blocks), or dropping the transaction entirely (if the forked block was seen by all miners who then dropped the transaction from their queue). Of course clients can (and I guess, should) send replacement transactions with a new sequence number at periodic intervals if their transaction doesn't show up in a block, although I don't know if the current client does that or what the most efficient and sustainable rate for clients to be doing this is.
Yes, miners delete pending transactions if they are seen in a new block coming in from the network. But when there is a reorganization, all transactions that were in the invalid blocks and not also in the newly valid blocks are automatically put back into the queue, after validating them using the transactions from the new blocks. |
|
|
|
How is Paxum different from Dwolla? I read the terms and FAQ (also thought Dwolla looked fine last week) but aren't they suseptable to teh same attack? TradeHill can hope Paxum doesn't push their losses upon the merchant, but otherwise, what's the difference? For the record, I pushed Dwolla funds to Mt. Gox this morning with no trouble. Someone obviously figured out how to game it.
That poses a lot of questions I don’t have answers for. If someone steals the bananas you buy at the store. What do you do?
Someone obviously figured out how to game Dwolla.
That poses a lot of questions I should have answers for, but don't. If someone steals from Dwolla and then launders the gains through an irreversible system, what does Dwolla do?
A rep from Paxum is here on the forums. He says they have rigorous verification processes that make fraud very unlikely. So, they don't have losses that they need to pawn off on their customers. Dwolla was pretty much just on the honor system, apparently. Which is odd. I got a phone call from Dwolla when I set up my account, just to verify my info. I still haven't added any banking info to my dwolla account. |
|
|
|
I predict that a client for casual users that stores as little of the chain as possible will be in widespread use at least one full year before the size of the block chain database file grows to the size that would take up 1% of the average (mean) hard drive size of typical home PCs.
Forget home PCs for a second. For bitcoin to go mainstream, we need to be able to pay from our cell phones. Modern (even near future) download speeds can't handle the blockchain size. The logical end of the reduced block chain idea is a device that keeps none of it locally, possibly not even the headers. There are dozens, maybe hundreds, of threads here with ideas on how to do that. Oh, and I can move 8 gigs into my ancient Palm Treo in about 2 seconds using the SD protocol. Modern phones should be able to do even better. |
|
|
|
*cough* In the last block, the effective hash rate was 2.354TH/s, the fastest miner had an estimated hashrate of 34214.55 MH/s, the slowest groups of miners out of 2957 miners for that block seems to be CPU miners with 3.38MH/s  You are confusing miner, the human with an account on BTC Guild, with miner, the hardware/software combination that does the work. In pool terminology, the second sort of miner is sometimes called a worker. But you have to be careful there too. There is no requirement that a miner (human) has to use a different worker entry for each of their miners (devices). There is no device capable of mining at 34 gigahashes per second. That is clearly an aggregation of many, many devices. So, you still have no idea of the distribution of hashing speed by devices. And your hypothesis only makes sense when applied to devices, not people or aggregations. |
|
|
|
|
Show Posts
