On Transaction Fees, And The Fallacy of Market-Based Solutions

Of all the parts of the Ethereum protocol, aside from the mining function the fee structure is perhaps the least set in stone. The current values, with one crypto operation taking 20 base fees, a new transaction taking 100 base fees, etc, are little more than semi-educated guesses, and harder data on exactly how much computational power a database read, an arithmetic operation and a hash actually take will certainly give us much better estimates on what exactly the ratios between the different computational fees should be. The other part of the question, that of exactly how much the base fee should be, is even more difficult to figure out; we have still not decided whether we want to target a certain block size, a certain USD-denominated level, or some combination of these factors, and it is very difficulty to say whether a base fee of $0.00001 or a base fee of $0.001 would be more appropriate. Ultimately, what is becoming more and more clear to us is that some kind of flexible fee system, that allows consensus-based human intervention after the fact, would be best for the project.

When many people coming from Bitcoin see this problem, however, they wonder why we are having such a hard time with this issue when Bitcoin already has a ready-made solution: make the fees voluntary and market-based. In the Bitcoin protocol, there are no mandatory transaction fees; even an extremely large and computationally arduous transaction can get in with a zero fee, and it is up to the miners to determine what fees they require. The lower a transaction’s fee, the longer it takes for the transaction to find a miner that will let it in, and those who want faster confirmations can pay more. At some point, an equilibrium should be reached. Problem solved. So why not here?

The reality, is, however, is that in Bitcoin the transaction fee problem is very far from “solved”. The system as described above already has a serious vulnerability: miners have to pay no fees, so a miner can choke the entire network with an extremely large block. In fact, this problem is so serious that Satoshi close to fix it with the ugliest possible path: set a maximum block size limit of 1 MB, or 7 transactions per second. Now, without the immensely hard-fought and politically laden debate that necessarily accompanies any “hard-forking” protocol change, Bitcoin simply cannot organically adapt to handle anything more than the 7 tx/sec limit that Satoshi originally placed.

And that’s Bitcoin. In Ethereum, the issue is even more problematic due to Turing-completeness. In Bitcoin, one can construct a mathematical proof that a transaction N bytes long will not take more than k*N time to verify for some constant k. In Ethereum, one can construct a transaction in less than 150 bytes that, absent fees, will run forever:

[ TO, VALUE, [ PUSH, 0, JMP ], v, r, s ]

In case you do not understand that, it’s the equivalent of 10: DO_NOTHING, 20: GOTO 10; an infinite loop. And as soon as a miner publishes a block that includes that transaction, the entire network will freeze. In fact, thanks to the well-known impossibility of the halting problem, it is not even possible to construct a filter to weed out infinite-looping scripts.

Thus, computational attacks on Ethereum are trivial, and even more restrictions must be placed in order to ensure that Ethereum remains a workable platform. But wait, you might say, why not just take the 1 MB limit, and convert it into a 1 million x base fee limit? One can even make the system more future-proof by replacing a hard cap with a floating cap of 100 times the moving average of the last 10000 blocks. At this point, we need to get deeper into the economics and try to understand what “market-based fees” are all about.

Crypto, Meet Pigou

In general terms, an idealized market, or at least one specific subset of a market, can be defined as follows. There exist a set of sellers, S[1] ... S[n], who are interested in selling a particular resource, and where seller S[i] incurs a cost c[i] from giving up that resource. We can say c[1] < c[2] < ... < c[n] for simplicity. Similarly, there exist some buyers, B[1] ... B[n], who are interested in gaining a particular resource and incur a gain g[i], where g[1] > g[2] > ... > g[n]. Then, an order matching process happens as follows. First, one locates the last k where g[k] > c[k]. Then, one picks a price between those two values, say at p = (g[k] + c[k])/2, and S[i] and B[i] make a trade, where S[i] gives the resource to B[i] and B[i] pays p to S[i]. All parties benefit, and the benefit is the maximum possible; if S[k+1] and B[k+1] also made a transaction, c[k+1] > v[k+1], so the transaction would actually have negative net value to society. Fortunately, it is in everybody’s interest to make sure that they do not participate in unfavorable trades.

The question is, is this kind of market the right model for Bitcoin transactions? To answer this question, let us try to put all of the players into roles. The resource is the service of transaction processing, and the people benefitting from the resource, the transaction senders, are also the buyers paying transaction fees. So far, so good. The sellers are obvious the miners. But who is incurring the costs? Here, things get tricky. For each individual transaction that a miner includes, the costs are borne not just by that miner, but by every single node in the entire network. The cost per transaction is tiny; a miner can process a transaction and include it in a block for less than $0.00001 worth of electricity and data storage. The reason why transaction fees need to be high is because that $0.00001 is being paid by thousands of nodes all around the world.

It gets worse. Suppose that the net cost to the network of processing a transaction is close to $0.05. In theory, even if the costs are not borne by exactly the same people who set the prices, as long as the transaction fee is close to $0.05 the system would still be in balance. But what is the equilibrium transaction fee going to be? Right now, fees are around $0.09 simply because miners are too lazy to switch. But then, in the future, what happens once fees become a larger share of a miner’s revenue and miners have a large incentive to try to maximize their take? The obvious answer is, for a solo miner the equilibrium transaction fee is $0.00001. If a transaction with a fee of $0.00002 comes in, and the miner adds it, the miner will have earned a profit of $0.00001, and the remaining $0.04999 worth of costs will be paid by the rest of the network together – a cryptographic tragedy of the commons.

Now, suppose that the mining ecosystem is more oligarchic, with one pool controlling 25% of all mining power. What are the incentives then? Here, it gets more tricky. The mining pool can actually choose to set its minimum fee higher, perhaps at $0.001. This may seem like the pool is forgoing profit opportunities between $0.00001 and $0.00099, but what is also happening is that many of the transaction senders who were adding between $0.00001 and $0.00099 before now have the incentive to increase their fees to make sure this pool confirms their transactions – otherwise, they would need to wait an average of 3.3 minutes longer. Thus, the fewer miners there are, the higher fees go – even thought a reduced number of miners actually means a lower network cost of processing all transactions.

From the above discussion, what should become painfully clear is that transaction processing simply is not a market, and therefore trying to apply market-like mechanisms to it is an exercise in random guessing at best, and a scalability disaster at worst. So what are the alternatives? The economically ideal solution is one that has often been brought up in the context of global warming, perhaps the largest geopolitical tragedy of the commons scenario in the modern world: Pigovian taxes.

Price Setting without A Market

The way a Pigovian tax works is simple. Through some mechanism, the total net cost of consuming a certain quantity of a common resource (eg. network computation, air purity) is calculated. Then, everyone who consumes that resource is required to pay that cost for every unit of the resource that they consume (or for every unit of pollution that they emit). The challenge in Pigovian taxation, however, is twofold. First, who gets the revenue? Second, and more importantly, there is no way to opt out of pollution, and thus no way for the market to extract people’s preferences about how much they would need to gain in order to suffer a given dose of pollution; thus, how do we set the price?

In general, there are three ways of solving this problem:

  1. Philosopher kings set the price, and disappear as the price is set in stone forever.
  2. Philosopher kings maintain active control over the price.
  3. Some kind of democratic mechanism

There is also a fourth way, some kind of market mechanism which randomly doles out extra pollution to certain groups and attempts to measure the extent to which people (or network nodes in the context of a crytocurrency) are willing to go to avoid that pollution; this approach is interesting but heavily underexplored, and I will not attempt to examine it at this point in time.

Our initial strategy was (1). Ripple’s strategy is (2). Now, we are increasingly looking to (3). But how would (3) be implemented? Fortunately, cryptocurrency is all about democratic consensus, and every cryptocurrency already has at least two forms of consensus baked in: proof of work and proof of stake. I will show two very simple protocols for doing this right now:

Proof of work Protocol

  1. If you mine a block, you have the right to set a value in the “extra data field”, which can be anywhere from 0-32 bytes (this is already in the protocol)
  2. If the first byte of this data is 0, nothing happens
  3. If the first byte of this data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536)
  4. If the first byte of this data is 255, we set block.basefee = block.basefee - floor(block.basefee / 65536)

Proof of stake Protocol

  1. After each block, calculate h = sha256(block.parenthash + address) * block.address_balance(address) for each address
  2. If h > 2^256 / difficulty, where difficulty is a set constant, that address can sign either 1, 0 or 255 and create a signed object of the form [ val, v, r, s ]
  3. The miner can then include that object in the block header, giving the miner and the stakeholder some miniscule reward.
  4. If the data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536)
  5. If the data is 255, we set block.basefee = block.basefee - floor(block.basefee / 65536)

The two protocols are functionally close to identical; the only difference is that in the proof of work protocol miners decide on the basefee and in the proof of stake protocol ether holders do. The question is, do miners and ether holders have their incentives aligned to set the fee fairly? If transaction fees go to miners, then miners clearly do not. However, if transaction fees are burned, and thus their value goes to all ether holder proportionately through reduced inflation, then perhaps they do. Miners and ether holders both want to see the value of their ether go up, so they want to set a fee that makes the network more useful, both in terms of not making it prohibitively expensive to make transactions and in terms of not setting a high computational load. Thus, in theory, assuming rational actors, we will have fees that are at least somewhat reasonable.

Is there a reason to go one way or the other in terms of miners versus ether holders? Perhaps there is. Miners have the incentive to see the value of ether go as high as possible in the short term, but perhaps not so much in the long term, since a prolonged rise eventually brings competition which cancels out the miners’ increased profit. Thus, miners might end up adopting a looser policy that imposes higher costs (eg. data storage) on miners far down the line. Ether holders, on the other hand, seem to have a longer term interest. On the other hand, miners are somewhat “locked in” to mining ether specifically, especially if semi-specialized or specialized hardware gets involved; ether holders, on the other hand, can easily hop from one market to the other. Furthermore, miners are less anonymous than ether holders. Thus, the issue is not clear cut; if transaction fees are burned one can go either way.


41 comments

  1. In control theory, one needs to have a goal for the target output of the system. With transaction fees, it’s not clear to me what the goal is. Is it a rising ETH value? A stable ETH value? Is there some metric that can be used to clearly state what the goal is that we want to obtain by changing the transaction fees?

    Also, there has been at least some talk about building PoW around Folding@Home or other tasks which have explicit benefit. I don’t pretend to be an expert, but it seems to me that such a thing would impact the economics of the basefee. See this link: http://www.reddit.com/r/ethereum/comments/1vh94e/dagger_updates/ceszf7t?context=3

  2. Pingback: On Transaction Fees, And The Fallacy of Market-Based Solutions | Bitcoin Buzz Feeds

    • I agree, it’s a very hard problem. The closest thing there is to a truly praxeologically compatible way to figure out the tax would be to apply my hypothesized fourth solution and deliberately apply extra pollution to certain groups and measure in monetary terms the effort people are willing to put in in order to avoid the pollution. Linear regression analyses are another option. However, aside from that kind of direct observation approach the strategy of relying on a democracy of thousands of calculators all of whom are in theory incentivized to pick an optimal price, while deeply flawed, might be the best we have. That’s why I merely claim that “in theory, assuming rational actors, we will have fees that are at least somewhat reasonable”, and not anything close to economic optimality.

      • Thank you, Vitalik. Linear regression would be interesting (outliers excluded). Alternatively to the avoidance strategy, one can look at a positive marginal utility of the last quantum of consumption. One key may be liquidity. As a cryptocurrency gains monetary velocity (more users, more transactions), incentives may change.

        We are at a stage where decentralization is dependent on a centralized power grid, which keeps costs relatively high. A high price may incentivize miners, but so may lower production costs. We need a ‘sublayer’ of decentralized power nodes.

        Ethereum poses many philosophical challenges as well. We are dealing with an orthogonally-bound universe (finite automata) on the one hand, and human actors in its meta-universe who do not always choose in a rational way.

  3. IMHO, the fee setting question is a distraction with currencies. Yes, I grant that the spam / hashcash debate is pretty fierce, but there are reasons why that happens, and that doesn’t as easily cross across to the money world.

    OTOH, the paying for shovels and pans is essential to the market. One answer that seems to be evidenced in the 25 year history of digital currencies is /loss leader/ and this is more correlated with success than say fees, which are more correlated with distraction and failure.

    As an example of the distraction, I think a far bigger problem is the Latency issue, explained here:
    http://financialcryptography.com/mt/archives/001473.html
    http://iang.org/papers/BitcoinLatency.pdf
    Unless any rewrite of the contract model within Bitcoin also addresses the latency, the use for the instruments is going to suffer headaches in serious trading scenarios.

  4. Pingback: Bitcoin, Ethereum and Pigou: the economics of transaction fees | cryptonomics

  5. Central planning always fails. Price controls always fail. If you want the system to survive you need to allow for a market where supply meets demand and prices float. You cannot measure costs and generate prices because exchanges are not based on measurable costs but on subjective valuations only, which is why poor people will sometimes buy luxury goods and be very happy with their purchase, and we do not have the right to judge how people use their resources, or to conclude that there is a “negative net value to society”. This type of Robo-Socialism will be short lived, like all other forms of central planning.

  6. I agree that you need a form of taxation and redistribution in case of a public good. Especially to incentivize usage of the good instead of hording or overuse.
    However, the whole assumption that Ethereum is a public good is a fallacy in itself. In fact, if you don’t view it in isolation but as one competitor amongst many alternatives to solve the problem of trusted relationships, arbitration and forging and enforcing contracts, it is not a public good. It then merely is a capital good with decreasing marginal costs, where the initial investment to build this capital is considerable and variable costs are due to contract calculation and mining/crypto security. Even marginal costs don’t arguably decrease forever with expanded usage, since other solutions like protoshares or Ripple could substitute it with more specialized use cases and being a little bit pessimistic about the network rent. That means Ethereum won’t be a monopoly either.

    Lets consider a real world example. In case of a cross border export contract, there are at least three parties involved. The buyer, the seller, intermediary banks and some arbitrator. The bank’s duty is to mitigate currency, transaction and (partly) economic risks. E.g. it issues L/C against escrow and sells interest swaps. The arbitrator is used in case of dispute. Lets say, all together these risk adjusted costs amount to 5% of the net sum. Now, the a sustainable incentive (not based on hype or political ideology) for the firms to enter a contract via DAx instead of the way described above are lower costs, as well as factoring in the risk.

    So if to view Ethereum within a larger ecosystem of services providing transaction safety, the whole necessity of taxing within contract computation is wrong. Rather, it would be a smart idea to let contract users provide for as many calculations as they consume, therefore keeping malicious overusage at bay. That means there shall be two goods. One for the traditional mining and keeping the blockchain secure (the reward being issued as inflation/coing burning). The other for using calculations. Any overbalance of calculations which, could be done by the some persons who are mining, can be sold to contract users. F.i. the real world clients. In the end the ETH holders will get their share by renting out coins whereupon contracts are run. Contract writers will get their profit as a service to contract users, whereby they are pressured to compete for the lowest possible calculations. The miners will profit by either acquiring some capital (the coins) and/or selling the necessary contract calculations. The clients will then decide if and how to use the ecosystem.

    For the sake of future practicability of Ethereum I strongly suggest to consider that move. Building a taxing system out of wrong assumptions will surely lead to ill born adoption, meaning evasion tactics, malicious behavior and hence no competitiveness to other systems.

    • Every single node on the network needs to do every calculation. That’s why contract computation is a public good (or more precisely, common good), and not a resource which can be sold.

      • “Every single node on the network needs to do every calculation. ”
        Ah I see, my bad. So to have perpetual consensus one must start with a consensus in that each participant is willing to do everyone else’s contract computations. This way, the governing approach you are upon makes sense… But what to think outside the box and imagine clusters of different Ethereum blockchains where each serves a manageable subspace of possibilities. E.g. one blockchain for currency derivatives, one for crowdfunding, one for freelancer markets and so on. Thus, a consensus can be more easily reached since the variety of contracts necessary in each subspace is managable by democracy. Or even a separate bid/ask market per contract. Furthermore, it would tackle the problem of multiple competing Ethereums, which will occur anyhow, in a proactive way. Would you then loose interoperability? And if yes, could it be solved if each subspace has one compulsory contract built-in which allows interfacing/intertrading with contracts from other subspaces?

      • Isn’t it enough to have the computation done by a majority of the network? Then the other nodes would have to accept the blocks from the majority of the network – so they would be forced to do the contract calculation (a “penalty” for setting fees to high). Setting mining fees too low means the miner does not receive a return on his investment in hardware, electricity, space rental, etc… So I see the push and pull of the market forces balancing prices… unless I’m missing something?

      • Just to clarify my previous statement of Feb 5th, 16pm here. I was not stipulating the creation of predefined categories baked into by developers. Rather the several subspaces will be discovered by nifty entrepreneurs trying to make sense out of the new possibilities. Therefore the whole ecosystem can grow organically. In fact, categorization as proposed before is a common tool for humans to decrease complexity. And it is about the same we have to deal with here. If every apple on earth needed each own description we would suffocate from transaction costs. On the other hand, it is usually sufficient to just deal in apples of some kinds and then weight.
        The question of interoperability between complexity reducing subspaces, despite living on different blockchains, is still open then. And it is a very crucial one, since if it is of little costs (or at least deterministic costs) it can provide the coveted lock-in effect to the Ethereum project in contrast to solutions from other projects.

  7. If slasher becomes the adopted algorithm, then why not let miners vote for their desired transaction fees in the proof-of-work blocks, then give them an advantage in their proof-of-stake mining inversely proportional to their voted fees? This way, those voting for lower fees would have better chances of mining a block, so proof-of-stake blocks would tend to set lower fees for future transactions. No matter how low, those fees should be enough to cover the costs of proof-of-stake mining, assuming each proof-of-stake miner would not willingly vote for fees below those needed to cover those costs.

    • To clarify my comment above, we could adapt the Slasher algorithm in this way:

      1. Fees would come from proof-of-stake blocks but would be voted for in each proof-of-work block.
      2. Miners voting for lower fees in their proof-of-work blocks would have a higher probability of mining a proof-of-stake block.
      3. Mined proof-of-stake blocks would select the fees voted for in the proof-of-work blocks providing their signing privileges.

      This would create two opposite incentives for miners when voting for fees:

      1. Higher fees would increase their profit when mining a proof-of-stake block that included those fees.
      2. Lower fees would increase their chances of mining a proof-of-stake block.

      So transaction fees should remain within a reasonable interval.

      • Under your system, profit = a * x + b * (1/x)

        P’ = a – b / x^2

        P’ = 0 at x = sqrt(b / a)

        Thus, the equilibrium depends on the square root of the ratio between two constants. This is actually an example of exactly what I am arguing against. A lot of people seem to think that as long as there is some kind of push and pull between two opposing forces, and there is an equilibrium, then all is well. In reality, however, that is false; even if there is an equilibrium, that absolutely does not mean that the equilibrium has any connection whatsoever to what is actually economically optimal in reality.

      • What if decreasing transaction fees increased profitability (via mining probability) faster than increasing transaction fees? This way, those fees would tend to a minimum, which seems to me as economically optimal.

      • There is a flaw in my original proposal: miners with no long-term commitment would have an incentive to vote on arbitrarily lower fees merely to increase their mining probability while still enjoying the current, higher fees.

      • Lets say that I am on the jury to sign a new block, and I want a fee to go up.
        The other 50 jury members have already voted for the fee to go down.
        If I vote for the fee to go up, then I am sacrificing my reward.
        So I will vote with the majority, even if it is not what I want.

  8. “For each individual transaction that a miner includes, the costs are borne not just by that miner, but by every single node in the entire network.”

    Although this is true for proof-of-work, in proof-of-stake, each miner depends only on his own work and stake. So the mismatch between who sells mining services and who pays for their costs in Bitcoin’s fee model does not derive from the model itself, but rather from its having been applied to proof-of-work.

    Here is a proposal for applying Bitcoin’s fee model to proof-of-stake:

    1. Each proof-of-stake miner determines the minimum fee for each block he mines:

    1.1. The block does not include transactions with lower fees than that minimum.

    1.2. The chances of mining a block vary according to these two rules (in addition to stake):

    1.2.1. They are directly proportional to the number of transactions in each block.

    1.2.2. They are inversely proportional to the delay between the blocks of each miner.

    2. Each one making transactions determines the paid fees for those transactions.

    This way:

    1. Each miner has an incentive to lower minimum fees as this increases the number of transactions in his blocks, then his profit.

    2. A miner trying to “choke the entire network with an extremely large block” will eventually face fewer chances of mining a block as the delay between his blocks increases.

    3. Each one making transactions has an incentive to increase paid fees as this increases the number of miners willing to accept his transactions.

    • Using the delay between blocks creates other problems. A better solution is using the average transaction value instead:

      1. Each proof-of-stake miner determines the minimum fee for each block he mines:

      1.1. The block does not include transactions with lower fees than that minimum.

      1.2. The chances of mining a block vary according to these two rules (in addition to stake):

      1.2.1. They are directly proportional to the number of transactions in that block.

      1.2.2. They are directly proportional to the average transaction value in that block.

      2. Each one making transactions determines the paid fees for those transactions.

      Increasing the chances of mining a block in direct proportion to the average transaction value in that block combats the cause of too large blocks, which is too many transactions.

  9. As the cost for the network have to be payed by the (full) nodes (miners included, but they get their incentive anyway), why not use them as fee receivers?
    Then you have a simple market model again. Tx producers and full nodes who are processing that tx (as well as providing storage space).
    I assume if Ethereum gets big, running a full node will cause considerable costs, so we need an incentive/payment for running a full node. I guess many users (mobile) will not have the resource to contribute to the network infrastructure and security as full node.
    In BTC we see that few people are running the heavy qt client and many are using web wallets or SVP clients. So the question is how many full nodes does the network need to be considered secure and what are the tx/contract producers are willing to pay.
    Maybe a pure free market does not lead to a good result here, as tx/contract producers could accept a semi-centralized structure (like we have in BTC with mining concentration) for the benefit of low costs? The higher the fee the more people are motivated to use their resources to support the network and the more secure it is.
    So maybe a mix can be applied. A minimum fee which is enough incentive that enough nodes are partizipating, and above that a free market process to find the balance.
    Maybe the threshold could be defined by a percentage of full nodes to the overall nodes using Ethereum. To find the right percentage is another task…

  10. “The question is, do miners and ether holders have their incentives aligned to set the fee fairly? If transaction fees go to miners, then miners clearly do not. However, if transaction fees are burned, and thus their value goes to all ether holder proportionately through reduced inflation, then perhaps they do.”

    Burning a currency benefits all its holders equally, so it cannot provide revenue in the burned currency. For example, if what I buy today costs me half of what it did yesterday, but what I sell today also costs people half of what it did yesterday, then I am just as rich as I was yesterday. Merely burning a currency can only provide an incentive to mine that currency once it increases its value in other currencies, and as long as its miners can exchange it for those other currencies.

    • I gave much thought to this problem in the last few days and concluded that indeed, it has no market-based solution. The ultimate reason is that a market requires buyers and sellers while mining cannot become decentralized and still have sellers. Total decentralization turns mining into a public service, and sellers must be private: with only buyers left, transaction fees tend to zero.

      Fortunately, I also found a protocol-based solution to the problem, which goes a step further from Peercoin:

      1. The reward for chaining proof-of-stake blocks comes from newly minted currency, like in Peercoin—which mints 1% new coins a year.

      2. Based on information from the block chain, an algorithm constantly adjusts destructive fees just to offset the newly minted coins.

      This way we have both a stable money supply and self-adjusted fees. The newly minted coins transfer value to block miners—from those who skip minting—partially via inflation while destructive fees constantly offset that inflation, leaving a value transfer equivalent to formal payments.

      Yet such a value transfer is impossible with formal payments: instead of going directly to miners, its destructive fees go to the whole network as deflation, and only then to miners according to their contribution to the same inflation offset by those deflationary fees.

  11. There’s a nice answer to this, and it doesn’t involve philosopher kings nor does it involve democratic mechanisms, but as I’m guessing you’ve figured, peer-to-peer and some market tendencies play in. However, that is not the end of the analysis of course, consider some ring puzzle (non-force) example paths to decoupling and on another conceptual level, cells. You mention price setting without a market. For now I am not addressing certain questions associated with proof of stake matter, but consider how we define things like a transaction, a market, biology, and so forth. These are interesting questions that need further contemplation. Imagine for a moment you are an Amoeba Proteus. You are being approached by an Euplotes Octocarinatus. It has a nice avoidance technique, so you manage to coexist with it. On the other hand, here comes a Euplotes Aediculatus. It bumps into things quite a lot and you end up perceiving it as a threat. You absorb it slowly and develop a phagolysosome. It dies and becomes your food. Probably, none of these entities knows or cares about concepts like “markets,” or “biology,” or “food,” or “ecology,” or any of that. But they have puzzles to solve, and stuff to absorb, and they have to coexist as best they can, too. Things to think about.

    Cheers.

  12. Pingback: Chapter 6: Fundraising Landscape | Great Wall of Numbers

  13. Hi,

    I’m really glad the time is being taken to give crypto a robust economic analysis, and that that analysis is being applied to the design of the protocols. I too believe I am missing something in your construction of the commons tragedy. What I’ve understood so far is you are trying to develop a mechanism by which users make up for the social cost of transacting on the network, because not doing so would somehow negatively impact the behavior of those providing the shared resource. I’m not quite seeing how though, because is not the bulk reward of mining derived from the block reward, as opposed to the transaction fees? Even if this were not so, if miners simply set Tx fees equal to computational cost, and other players who cannot take the resulting computational load simply exit, where is the social loss? I’m not understanding the difference between the computational cost to the miner (you said the miner pays no fees, could you explain this more clearly? At face value that seems like an incorrect claim) and that of the network as the whole. Could each node have a different computational cost for verifying a given transaction, hence the difficulty in calculating/learning the social cost? If you could please go more deeply into exactly why the social loss of market-based transaction fees is relevant to the health of the network, it would be greatly appreciated. I am writing a report on this today and would gladly use your help.

    Thanks,
    Brian

  14. Hi,

    I’m really glad the time is being taken to give crypto a robust economic analysis, and that that analysis is being applied to the design of the protocols. I too believe I am missing something in your construction of the commons tragedy. What I’ve understood so far is you are trying to develop a mechanism by which users make up for the social cost of transacting on the network, because not doing so would somehow negatively impact the behavior of those providing the shared resource. I’m not quite seeing how though, because is not the bulk reward of mining derived from the block reward, as opposed to the transaction fees? Even if this were not so, if miners simply set Tx fees equal to computational cost, and other players who cannot take the resulting computational load simply exit, where is the social loss? I’m not understanding the difference between the computational cost to the miner (you said the miner pays no fees, could you explain this more clearly? At face value that seems like an incorrect claim) and that of the network as the whole. Could each node have a different computational cost for verifying a given transaction, hence the difficulty in calculating/learning the social cost? If you could please go more deeply into exactly why the social loss of market-based transaction fees is relevant to the health of the network, it would be greatly appreciated. I am writing a report on this today and would gladly use your help.

    Thanks,
    Gone

    • I guess as a concurrent confusion, what is the difference between the computation required to confirm a transaction or block of transactions and that required to verify it? In my mind confirmation relates to the proof-of-work algorithm which timestamps transactions while verification relates to a mathematical check that each transaction in a block could have actually happened in the sequence that it did. Am I describing the same computation done reduntantly by the miner and the network, or separate computations, one done by the miner and one done by each node in the network? In order to understand how computational costs should optimally be distributed I need to know what those computations actually are, which I believe I am missing

  15. “For each individual transaction that a miner includes, the costs are borne not just by that miner, but by every single node in the entire network.”

    This is false: miners do not contribute to each other’s effort. On the contrary, they just increase each other’s difficulty. Therefore, each mining operation needs not incur any costs other than its own. This is precisely why the fairness of a mining pool depends on giving each one of its members the same reduction in both cost and reward.

  16. Hi – Thanks in advance as I’m sure my question may be a Long-Term application of Ethereum: As the transaction fee “Devil in the Details” are being worked out, can someone elaborate just a bit on the contrasts between a “legal contract” Ethereum use case vs. a “Corporate Value-Chain Process” Ethereum use case. Leveraging Ethereum to replace intensive corporate processes with thousands of “transactions” may need to be studied (vs. the “legal contract” use case) [or is the thought that ANY transaction will cost the same as ANY other transaction, regardless] – Thank You

  17. “…so the transaction would actually have negative net value to society.”

    Other than your flawed theory on how market prices are determined (i.e. Böhm-Bawerk’s Marginal Pairs) society as a whole is actually richer since economics isn’t a zero-sum game. What would make society poorer would be for an external entity to prevent the mutually-beneficial trade from occurring below some price floor that some bureaucrat deemed is ‘harmful to society’.

    “Second, and more importantly, there is no way to opt out of pollution, and thus no way for the market to extract people’s preferences about how much they would need to gain in order to suffer a given dose of pollution; thus, how do we set the price?”

    Putting aside the whole pollution red-herring what you have here is X amount of people in possession of a consumable resource and Y amount of people whom wish to consume it.

    You have a means to measure the consumption of said resource (cpu cycles, disk space &etc…), a bunch of people (and non-people) who wish to gain a measurable benefit (aka, profit) from consuming them and a bunch of people who wish to gain a measurable benefit from providing them.

    Not really seeing how a market based solution isn’t possible since I thought the whole point of this thing was to enable people to create contracts that can do ‘complex’ things like set up an escrow account that collects fees and pays them out to participating nodes based on some metric like ‘if fees > minimum_payment: [pay(node, transaction_fee/len(nodelist)) for node in nodelist if contributed(node, workunit)]‘.

  18. It is not the most important thing, but the first paragraph in the ‘Crypto, Meet Pigou’ section could benefit from some editing. For example, there’s a v that surely was intended to be a g, and in the order matching part, are you intending for i to range over the interval 1..k?

  19. Corporations should act to increase the value of it’s shares.
    We need to create a pool of voters who’s incentives are aligned to increase
    the value of the shares.

    Why not create bonds, which are non-transferable and worth a sum of ether.
    For exmple: I could turn 10,000 ether into a 1-week bond. At the end of the
    week, the bond would turn back into ether which I can spend.

    Then, assuming we use slasher, select POS voters from the bond holders.
    So if you own 1% of the bonds, then you have 1% chance of being selected.

    This would greatly stabalize the price of ether, because there would be so
    many people with money locked in bonds who are unable to rapidly trade.

    This requires a low inflation rate, otherwise the bonds would be a
    terrible investment. So it needs to be slasher and not POW.

    We only have the ability to vote on numbers, and we can only vote
    to increase or decrease, but this is actually very powerful.

    Every function can be written as a polynomial of constants. If you
    know the first 4 or 5 constants, then you know almost everything
    about the function.
    We could vote on the 4 or 5 constants, and the community could
    custom-build a function that is embedded in a currency.

    At different times bond holders could either be paid for their service,
    or they could have to pay a fee for the priviledge of having a bond.

    Ethereum has every fee be a hard-coded multiple of the base fee, but this is
    not necessary. The system could actively update each fee independent.
    Abilities like this could solve unforeseen problems.

    I am working on a DAC which will be a clone of reddit, and a distributed
    marketplace. It will have a POS voting system over 10 or 20 constants.
    https://github.com/zack-bitcoin/NewsCoin

    I am trying to decide whether or not to use the bond method I describe above.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s