1721
|
Bitcoin / Development & Technical Discussion / Re: Network-wide cost of a transaction
|
on: February 11, 2011, 03:39:31 PM
|
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.
|
|
|
1722
|
Bitcoin / Development & Technical Discussion / Re: Network-wide cost of a transaction
|
on: February 11, 2011, 03:10:27 PM
|
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)
|
|
|
1723
|
Bitcoin / Development & Technical Discussion / Network-wide cost of a transaction
|
on: February 10, 2011, 10:55:36 PM
|
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.
|
|
|
1724
|
Bitcoin / Development & Technical Discussion / Re: [RFC] monitor JSON-RPC api (push instead of poll)
|
on: February 10, 2011, 10:24:58 PM
|
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).
|
|
|
1726
|
Bitcoin / Development & Technical Discussion / Re: More divisibility required - move the decimal point
|
on: February 10, 2011, 05:13:55 PM
|
WAY too many issues being mixed up here... I'm sorry I ever framed this as "moving the decimal point"
I think the next release of Bitcoin should:
+ Show full-precision bitcoins in the GUI. If you have 1.5 BTC, it will display as it does now ("1.50"). If you have 1.50001 BTC, it will display the extra precision.
+ Allow you to send full-precision from the GUI and from JSON. If you have 1.500001 BTC, you will see you have that many and can send that many.
+ Incorporate luke-jr's patch to avoid losing "dust change", when possible. (e.g. if you have received transactions of 1.5000001 and 20 BTC, and then send 1.5, Bitcoin shouldn't choose just the 1.5000001 input transaction).
Those issues are being driven by pooled mining-- a lot of people are getting sub-cent bitcoins from their pooled mining shares.
Then there's the issue of "what is a micro-transaction for which you should be forced to pay a fee." Currently, it is any transaction with an output less than 0.01 BTC.
And the issue of "what is the minimum fee" (also currently 0.01 BTC).
Ideally, transaction fees should reflect real-world costs... although just making them hidden costs that are spread between everybody running bitcoin might work perfectly well. Still, I'd like to get a rough idea of the real-world cost of a transaction.
It is too early to be worried about "paying 0.001 bitcoins for a pair of socks".
|
|
|
1731
|
Bitcoin / Development & Technical Discussion / Re: Crap, I reformatted, did I lose my BTC?
|
on: February 08, 2011, 06:23:52 PM
|
I reformatted... I backed up my bitcoin directory... but when I restored it on the fresh OS my wallet was not intact...
Are you missing your wallet.dat file or is it damaged? If it is missing, then grondilu's advice is the best anybody can do. If it is damaged, then it might be possible to extract the private keys from it. This type of thing is why off-site backups are a really good idea...
|
|
|
1732
|
Bitcoin / Bitcoin Discussion / Re: When Will Satoshi return?
|
on: February 08, 2011, 06:17:49 PM
|
Uh, the official client is being actively developed on github...
Yup. Patches welcome, although before accepting any more patches "we" need to build the 0.3.20 release. Assuming my cold doesn't get a lot worse, I'll be trying to make that happen tomorrow...
|
|
|
1733
|
Bitcoin / Project Development / Re: Main page is a disaster
|
on: February 08, 2011, 04:21:14 PM
|
Wiki for the trade page is a fantastic idea.
And I like the idea of a re-organized, simplified home page. Who should the home page target? I think there are few potential audiences; successful web sites design their home pages to one or more specific types of visitors. For bitcoin, I think visitors are likely to be:
1. Geeks who are interested in "how is bitcoin supposed to work."
2. Geeks who are interested in "how can I use bitcoin for a project I'm thinking of working on."
3. Non-geeks who are interested in "what the heck is bitcoin and why should I care."
There are also several audiences I don't think bitcoin.org should target (for example, people hoping that bitcoin is a way to get rich quick). Am I missing anybody?
I've been busy putting together a 5-minute talk for audience number 3; I think I can re-purpose some of what I wrote for the website.
|
|
|
1735
|
Economy / Trading Discussion / Re: What if you sold usb bitcoin drives on ebay ?
|
on: February 07, 2011, 05:03:46 PM
|
I do wonder though, why would anyone buy it? I can't picture myself in the mindset of being someone who has never heard of Bitcoin and thinking - WOW - I want this.
I think it would be great for newbies who hear about bitcoin and decide they want to try it. USB stick is better than a CD because you could include a recent copy of Bitcoin (with most of the block chain), already configured, for Windows and Mac. So the user plugs in the USB drive, double-clicks the bitcoin app, and they're up and running. The seller would need to establish a reputation for no-viruses/trojans, no already-spent coins in the wallet on the stick, etc etc etc.... ... all the stuff that newbies are probably to clueless to worry about anyway. The value is both the "starter" bitcoins in the wallet AND the convenience of not having to download/install/configure bitcoin. If PayPal asked, I'd say that I'm selling bitcoin software on USB sticks, and that the bitcoins in the wallet are just there because you can't use the software without having a few bitcoins to start....
|
|
|
1736
|
Bitcoin / Project Development / Re: challenging hackers to promote bitcoin
|
on: February 05, 2011, 11:03:58 PM
|
In this thread I said: Bitcoin's p2p network is subject to various kinds of denial of service attacks.
There, I said it.
Bitcoin is still vulnerable to DOS attacks. I'm not sure anybody knows how to prevent DOS attacks on a p2p network that allows untrusted/unverified peers to join (but I'd very much like a networking expert to tell me I'm wrong, and would like it even more if they volunteered to fix it....). Asking hackers to prove that they can DOS the bitcoin network wouldn't prove anything, it would just slow down transactions for however long they decided to keep up the attack. Giving bounties for uncovering vulnerabilities besides a network-denial-of-service attack is a good idea (demonstrated on the -testnet, preferably).
|
|
|
1738
|
Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid
|
on: February 05, 2011, 05:13:24 PM
|
It doesn't 'feel right' to me.
Seems like the ideal API would be:
"Hey bitcoin, I want to keep track of all transactions for account FOO (or all accounts) that have [minconf] confirmations. Please POST them to [url]."
or
"Hey bitcoin, I want to keep track of all transactions for account FOO (or all accounts) that have [minconf] confirmations. I'll be polling you to see if there are any new ones every once in a while, I'll pass you [unique_token] so you know it is me."
... at least for the simple case. You'd get back two lists of transactions: new transactions with [minconf] that you haven't been told about before (maybe empty in the polling case), and a list of transactions you were told about before that now have less than [minconf] confirmations because of a block chain re-org (always empty if [minconf] is big enough).
For the "I really want to shoot myself in the foot and deal with block-chain reorgs myself" you can call getblock and/or monitorblock to get all the gory details about which transactions are in which blocks.
|
|
|
1739
|
Bitcoin / Development & Technical Discussion / Re: Will the block chain size ever become too large?
|
on: February 05, 2011, 04:31:40 PM
|
We've talked about these kinds of scaling issues in the past, and we've got a ways to go until they become an issue.
I still strongly believe that we shouldn't worry about them until they actually start to become a problem.
Long before we get to 300 million transactions per day there will be big companies spending lots of engineering dollars on their own highly optimized versions of bitcoin.
I bet there will be alternative, secure-and-trusted, very-high-speed network connections between major bitcoin transaction processors. Maybe it will just be bitcoin transactions flying across the existing Visa/MasterCard/etc networks (I have no idea what their transaction clearing/processing networks look like or how they work).
Instead of worrying about "what will we do when we are wildly successful" we should be worrying about "what should we do RIGHT NOW so we become wildly successful."
|
|
|
|