I'll be installing the Windows client tonight. Should I post in this or the other if I run into issues?
Submit issues at the issue tracker on github if you run into issues: https://github.com/bitcoin/bitcoin/issues |
|
|
|
The only way grocery stores could get on the network would be to have some sort of "MYBITCOIN"-like intermediary that does all the transaction processing, most of which would have to happen off the block chain.
Right... so then the question is "will the MYBITCOIN-like intermediary be able to verify transactions quickly without opening themselves up to systematic fraud." Without requiring users to pre-deposit funds with them, because users ain't gonna do that. Here's another possible simple rule for miners that might work (but, as Hal said, requires Deep Thought): "When I see a new block with transactions that I didn't see broadcast previously, mark those transactions as suspicious. If I see double-spends of those transactions, stop building on that block-- assume it is cheating. Switch to the previous block (or alternate block if there's a block race going on)." Miners won't try to rip off a grocery store for $50 worth of groceries if doing so makes their $50+ bitcoin reward for finding a block disappear. This rule would also give miners a strong incentive to detect and refuse to include EITHER side of a double-spend in their blocks (if they get both spends while they're working on the block). |
|
|
|
|
Your second client hasn't downloaded all the blocks yet (according to the screen snapshot).
When it has, it will be able to verify that the send transaction is valid, and will update your balance there.
|
|
|
|
To cheat you, when he generates a block, he doesn't broadcast it. Instead, he runs down to your store...
I think the real danger is that a large mining operator would create a side business selling space in their blocks for these types of intentional double-spends. When they generate a block they could send a text message to a bunch of people saying "try to spend NOW". I wonder if there's some way to discourage that kind of anti-social behavior; could the network detect that was being done and "shun" that miner's blocks? |
|
|
|
|
Here's what happens when you press the Get Some button on the Faucet and it sends you coins:
+ A Google App Engine task is scheduled to actually do the send.
+ The send tasks are (currently) scheduled to run at most once per minute, so huge spikes in demand for coins from the faucet are smoothed out.
The nice thing about App Engine tasks is that they're persistent little buggers-- they'll keep going until they succeed. If the send fails for some reason (I need to restart bitcoind for some reason, or the connection between the Google and my bitcoind server is down), App Engine will reschedule the task to try again after an hour.
So, you were probably just very unlucky and the send failed twice in a row, OR you on the tail end of a couple hundred people all asking for coins at about the same time (the faucet will service a maximum of 120 requests in two hours).
|
|
|
|
|
Easiest way would be to put it in the bitcoin.conf file.
Create $HOME/Library/Application Support/Bitcoin/bitcoin.conf and put:
connect=IP ADDRESS
... in it. Any of the command-line options (except -datadir and -conf) can be put in the bitcoin.conf file.
|
|
|
|
|
I'm halfway through creating releases-- I had a 0.3.20 candidate Windows release that didn't pass sanity testing (rendering issues that it looks like are fixed with a wxWidgets upgrade).
If all goes well, 0.3.20 for linux and pc will be up and available tomorrow, 0.3.20 for the mac "real soon now".
If not... it will take longer.
|
|
|
|
|
It is possible to generate transactions that "fan out" to an arbitrary number of recipients.
They're non-standard transactions right now, so they won't be relayed or included in blocks. But you should probably assume that they will be possible in the future (and a miner could, of course, include them in their own blocks now).
|
|
|
|
I agree with 1. Indeed I'm not sure bitcoin could be used simultenaously by billions of users.
Really? You don't think if bitcoin gets really successful and there are hundreds of millions of dollars poured into engineering efforts for it (and if it is wildly successful, big companies WILL invest huge amounts of money on it), that any scaling problems won't get solved? I bet I could find people predicting a few years ago that Facebook would never be able to scale to billions of users (it was written in PHP for pete's sake!). |
|
|
|
Therefore, No. There will always be some circumstances in which your right to conduct only voluntary and consensual relationships should not be respected by all. In a pride of lions, the top male decides. In our society, at present, there are laws which decide, but in a stateless society... damned if I know who decides. I have a big problem with libertarianism and conflict resolution. Help me to understand guys.
I think you're confusing libertarian with minarchist or anarcho-capitalist. Libertarians generally agree that police and a legal system to resolve disputes are a proper role for government. |
|
|
|
|
If you really want to sway people, you need to find areas of agreement and blissfully ignore things about which you strongly disagree.
There is a lot to agree with in that FAQ, in my humble opinion.
Oh, and you have to learn to ignore people who just won't listen to reason, or who are starting with different assumptions about how the world works than you.
|
|
|
|
|
The Faucet has several abuse prevention features in place. I'm not going to say what they are because then the 'bad guys' would have a road map for what to do to try to get around them.
They're not 100% foolproof, but they're pretty good.
The steady stream of transactions from the Faucet the last few days IS because of the increased interest due to the security now podcast and slashdot mention.
|
|
|
|
For example, "free" is a magical number.
Anything under a penny per transaction is as good as free, when the nearest competitor is PayPal. No, that's the point: 0 is a magic number in our heads. "1/50'th the cost of Paypal" will get, say, 5% of the people to switch. "Free" will get 50% to switch. (numbers pulled out of my ass, of course, but you get the idea) |
|
|
|
Verifying an ECDSA signature takes about 3 ms. Let's say the typical transaction has 2 inputs. Each transaction is verified twice, once alone and once in a block. That's 12 ms per node, times 10000 nodes...
Thanks Hal! If I had a cluster of bitcoin transaction processing nodes (or a big mining farm), I'd connect them with memcache and store transaction hashes/verified flag pairs, so signatures were verified once. Or maybe just have one machine filter transaction/block traffic and only pass along valid transactions/blocks, and not have the rest of the machines even bother checking signatures. It will be tougher for individual nodes. If they're not mining, they could just check signatures ONLY on somebody-sent-to-them transactions. If they are mining... well, it seems to me single-node miners will become increasingly rare as bitcoin scales up. Hardware farms or miners using a mining pool seem like the way of the future. |
|
|
|
That's a limited and scarce resource. The right approach to pricing a scarce resource is to let the price of it float on the market rather than trying to figure out its component costs and then simply pegging the price to that. Otherwise you're imposing price controls and can end up with shortages.
I agree. However, at this point "we" have to decide what the default rules are, and what is decided now will influence what people think is "fair" two years from now (when, hopefully, bitcoin is in the process of becoming wildly successful). Also, I've read a couple of popular behavioral economics books (e.g. Predictably Irrational), and I think there might be some irrationality that could make bitcoin more successful. For example, "free" is a magical number. If we can make most bitcoin transactions "free" to the typical user, then that's a huge selling point. There ARE hidden costs; the reason I want to do the back-of-the-envelope is to figure out how big those hidden costs are now and how big they're likely to get in the future. It isn't rational, but most people would rather have "free transactions", even if they end up paying 10 cents more in electricity costs every month whether or not they actually make any transactions. (I may move this to the Economics topic depending on where the discussion goes) |
|
|
|
|
I figure each bitcoin transaction is currently costing about $US 0.0003 (three-hundredths of a cent)
Here's the back-of-the-envelope calculation I used to get to that number:
Transaction size: ~300 bytes.
Disk space cost: 0.05 $US per gigabyte (about $100 for a 2TB hard drive these days)
Bandwidth cost: 0.02 $US per gigabyte
CPU cost: 0 (bad assumption-- anybody want to try to come up with a better estimate?)
Size of bitcoin network: ~10,000 nodes
Each transaction is currently sent across the network twice (once on its own, and once when it becomes part of a block). It is stored on disk once. So disk+bandwidth cost for one machine is:
(0.05+0.02+0.02)*(300/1000000000)
... times 10,000 nodes gives $0.00027 per transaction.
Please check my work-- I usually screw up and add or drop an extra zero when doing these types of calculations.
|
|
|
|
A client that connects up, subscribes, and then gets updates as they happen might be an easier start.
Connects via another port? Or would you teach bitcoin's minimal http implementation to keep the connection open? (and service multiple connections at once) I've got a use case (google App Engine) where a persistent connection to bitcoin isn't possible (App Engine apps can fetch URLs, and can act as 'web hooks', but can't just open a socket and listen). |
|
|
|
We should just put a setting for the user to decide what the minimum amount a transaction should have in order not to be considered as spam, and included in mined blocks.
Okey doke. And the default value should be.... ? |
|
|
|
|
Show Posts
