Topic: Network-wide cost of a transaction (Read 4538 times)

Good point, verifying transactions close to the originating node means stopping spam earlier, but adding to the load of those nodes. I think we have to distinguish between spam (invalid transactions) or valid transactions increasing in size.

Actually this reminds me my idea of using a hypercube, transactions are always forwarded to the nodes that check the inputs, should the network ever run out of computation power we just add a new degree locally and have successfully halved the computation power needed (by adding an additional bit to the prefix matched), reduced the network load to 1/4th (half the nodes fully connected 1/2n => 1/4n^2), all that for adding an additional hop to the final destination

But you don't have to backup the blocks. Just your wallet. And for wallet.dat size it does not matter how many transactions got attached to the blocks.

When calculating the dollar amount of the storage, you would want to take back-ups into account. My data is backed up locally, backed up via Carbonite, and probably on DropBox.

This means that if I was running a bitcoin node, you would need to count my back up drive, the drop box (which would be the most expensive part), and the bandwidth involved in moving the copy to Dropbox and backup to Carbonite.

I just read back some of the old threads. It seems Gavin has already got the DoS problem figured out and I just hadn't encountered the solutions in the source code (or they aren't implemented yet).

One thing I'm not sure about is the interaction of all Gavins ideas. Having nodes not check signatures on coins that aren't sent to them frees up a lot of CPU time across the network and means you could relay thousands of transactions per second on good hardware instead of just 100-200. Ordering transactions by priority and refusing to relay low priority transactions when a node starts running out of capacity means "real" transactions would probably not suffer.

But if you aren't verifying signatures then that means I can send transactions into the network that aren't valid (the signature is random garbage) but reference old coins I don't own, thus artificially boosting my priority. Other nodes will happily relay my high priority but invalid transactions through the network leading to huge amounts of spam travelling around. It just replaces CPU exhaustion with RAM and network exhaustion.

Anyway, I think I'm still confused about the different types of fees so maybe not really helping this thread. They are used both as an anti-spam system and to encourage miners in later years when fewer coins are minted per block. I'm not sure what we're trying to calculate the cost of a transaction for ... I guess it's actually the latter case.

OK, let's say for the sake of the discussion that those figures are correct.

On that basis, the most favorable design decision would be to set the default fee to zero, but make it very easy for users to change the default so that people can push "real" transactions past the spam when attackers unleash a flood of transactions.

Totally agree that we want fees to be zero for as long as possible (or forever).

What I had in mind is that when network load is not reaching capacity, transactions would be free. If nodes start struggling to keep up, they'd begin charging fees to make things expensive for spammers/attackers. Once load lowered again, fees would drop back to zero. If nodes were upgraded and got extra capacity, the fees for that node would drop to zero again.

This assumes a world in the only purpose of fees is as an anti-DoS measure. If/when fees become the primary economic incentive to mine, well, hopefully at that point mining will be cheap and competitive enough that fees would still be extremely low on a per-tx basis (tiny fees for lots of transactions can add up to a thin margin on top of expenses).

I think there are really two problems here:

1) what should the fees be (continuing to be zero would be best)

and

2) if they do need to be raised at some point, eg to handle a transient DoS attack, how do you communicate that to real users so they know how much of a fee to include?

Also, how do you do that in a fast way such that an attacker can't take out the network quickly. Block based consensus feels intuitively too slow. Imagine how disruptive a 20 minute outage of VISA or MasterCard would be. I actually never heard of such a thing, probably these companies put a lot of effort into reliability and I know they are way overprovisioned to withstand temporary load spikes .... and they don't have the issue of accepting transactions from just anyone.

I'm not sure what the answers are though. Will ponder some more this weekend.

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)

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.

Anything under a penny per transaction is as good as free, when the nearest competitor is PayPal.

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)

ECDSA is intensive. See here:

http://www.cryptopp.com/benchmarks.html

3 ms sounds like a long time, on what hardware is that?

These calculations make me uncomfortable because they assume nodes scale up infinitely given small dollar amounts. Really, for CPU time you should be counting the cost of the CPU core as well.

What's more, there are hard scalability limits to how big a single node can get. Most of those 10,000 nodes will be running on single or dual core machines. A few people might run them on 8 or 16 core machines, but even very large cloud computing operations rarely go much higher than this. So using Hals number of 12ms per transaction we can do ~80 transaction/sec/core (a bit more than the 50 I estimated) so, optimistically, 160 tps for the entire network because every node has to be able to keep up.

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 think you should count only marginal CPU usage. If someone runs the bitcoin program, the computer is running regardless there are transactions or not. I have no idea what additional power usage is drawn by such a short calculation but much lower than 300W. I would guess 50W or less since the CPU will likely be in a low clock powersaving mode. It makes it less than $0.0002

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 for 120 cpu-seconds, aka 2 cpu-minutes or 1/30 cpu-hour. I'm going to say a computer draws 300W @ $0.10/kWh for electricity, for $0.03 per cpu-hour. YMMV. That makes $0.001 for cpu costs, a tenth of a cent, which appears to dominate.

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.