Bitcoin Forum
May 09, 2016, 01:09:09 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 »
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).
1725  Bitcoin / Development & Technical Discussion / Re: More divisibility required - move the decimal point on: February 10, 2011, 05:26:23 PM
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.... ?
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".
1727  Bitcoin / Development & Technical Discussion / Re: More divisibility required - move the decimal point on: February 10, 2011, 02:44:16 PM
I wonder how much a bitcoin transaction actually costs, in terms of bandwidth and disk space on everybody's machines.

If nobody beats me to it, I'll try to do a back-of-the-envelope calculation later today.
1728  Bitcoin / Development & Technical Discussion / Re: RFC for feature : force rescan of blockchain against an arbitrary wallet on: February 09, 2011, 04:13:38 PM
The -rescan argument in 0.3.20 does this.

1729  Bitcoin / Development & Technical Discussion / Re: Sppliting/merging wallets on: February 09, 2011, 04:11:22 PM
(We probably need a public bug tracking/feature request system.)

The public bug tracking/feature request system is at:
 https://github.com/bitcoin/bitcoin/issues

Vote up issues/bugs that are important to you there.
1730  Bitcoin / Development & Technical Discussion / Re: Help Wanted (for pay): Implement "offline account" capabilities on: February 09, 2011, 04:35:30 AM
-rescan will be in 0.3.20.

It takes about a minute right now on my machine (but that will get longer and longer as there are more and more transactions in the block chain).
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.
1734  Bitcoin / Development & Technical Discussion / Re: 21million BTC is just over 51 bits of precision... on: February 07, 2011, 08:40:11 PM
Why floating point is being considered at all is a mystery to me.

Huh?  Nobody is suggesting that any math be done with floating-point coins.

But even if we were, your first example gives the correct result to the 8-places-of-precision that Bitcoin deals with:
 (round 0.032200000000000006  to 8 places and you get 0.03220000)
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:
Quote
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).

1737  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 05, 2011, 10:38:50 PM
I'm running version 0.3.19 and I cannot find neither getblock nor monitorblock.  Are these new methods coming for 0.3.20?  Well, if getblock does what I think it does (ie, return all information available about a given block number, including block hash and transactions) then it would of course be an alternative way to implement the "shoot-myself-in-the-foot" client.  Everybody can be happy, yay!

They're not in 0.3.20; maybe 0.3.21.
  https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived
... is the not-yet-ready-for-prime-time branch they're on.
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."
1740  Other / Off-topic / Re: interesting concept, might be suitable for bitcoin merchant on: February 05, 2011, 03:35:45 PM
Spend 80cents to lower the price of something 50cents (and give you the privilege to look at the price)?

Sounds like a terrible idea to me.

So it'll probably be a huge success (I'm constantly amazed at the stupid things people do with their money).
Pages: « 1 ... 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 [87] 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!