We briefly discussed granularity at the last meeting but I think it does warrant a bit more discussion. The question comes down to whether we only care about providing priority for large megabyte-sized streams (like video and file-sharing) or if it's worth it to accompany individual cells (HTTPS requests) with payments.
Schemes like BOLT and DAM (from the related works) are only "micro" compared to something like Bitcoin. Each transaction still requires somewhat heavyweight crypto and multiple kilobyte-sized messages.
To pay on a cell-by-cell basis for web browsing, we would probably have to adapt either Peppercoin-style probabilistic payments or Payword-style hash chains. How big are these payments? Lets say we use payword hash chains with SHA-2. One way to measure its economic security is to calculate the opportunity cost of breaking our scheme vs just mining Bitcoins instead.
According to https://blockchain.info/charts/
Hash rate of Bitcoin network: ~ 3.0e18 hashes/s
Bitcoin revenue / day: ~$3,000,000
Market value of one hash: $1.15e-17
Now let's say that our scheme implements a rule where our hash chain is built from preimages that are truncated to 64 bits. Then the opportunity cost of cheating is $1.15e-17 * 2^64 = $214 dollars. That means a 64 bit string can safely encode any payment up to $214, which is far more than we need.
However, SHA-2 would probably be the worst possible hash function to use for these purposes because it is so profitable for Bitcoin. If we go a step down and choose, for instance, the hash function used by Litecoin, then a similar calculation yields an opportunity cost of about $0.003 USD to break a 32 bit message. This seems just on the edge of possibility for our uses.
TL;DR
Considering that it seems feasible to send small payments with as little as 32-64 bits, would it be useful at all to encode payments at the cell-by-cell scale for web browsing, or should we focus our efforts purely on megabyte scale traffic?
We briefly discussed granularity at the last meeting but I think it does warrant a bit more discussion. The question comes down to whether we only care about providing priority for large megabyte-sized streams (like video and file-sharing) or if it's worth it to accompany individual cells (HTTPS requests) with payments.
Schemes like BOLT and DAM (from the related works) are only "micro" compared to something like Bitcoin. Each transaction still requires somewhat heavyweight crypto and multiple kilobyte-sized messages.
To pay on a cell-by-cell basis for web browsing, we would probably have to adapt either Peppercoin-style probabilistic payments or Payword-style hash chains. How big are these payments? Lets say we use payword hash chains with SHA-2. One way to measure its economic security is to calculate the opportunity cost of breaking our scheme vs just mining Bitcoins instead.
According to https://blockchain.info/charts/
Hash rate of Bitcoin network: ~ 3.0e18 hashes/s
Bitcoin revenue / day: ~$3,000,000
Market value of one hash: $1.15e-17
Now let's say that our scheme implements a rule where our hash chain is built from preimages that are truncated to 64 bits. Then the opportunity cost of cheating is $1.15e-17 * 2^64 = $214 dollars. That means a 64 bit string can safely encode any payment up to $214, which is far more than we need.
However, SHA-2 would probably be the worst possible hash function to use for these purposes because it is so profitable for Bitcoin. If we go a step down and choose, for instance, the hash function used by Litecoin, then a similar calculation yields an opportunity cost of about $0.003 USD to break a 32 bit message. This seems just on the edge of possibility for our uses.
TL;DR
Considering that it seems feasible to send small payments with as little as 32-64 bits, would it be useful at all to encode payments at the cell-by-cell scale for web browsing, or should we focus our efforts purely on megabyte scale traffic?