Transaction POW

I think we can do a lot better than blocks. Here is my first attempt. I believe that the advantages are significant, the downsides are small, and my initial analysis of it did not find anything critically wrong. (risky words)

Post Mortem: This stuff is vulnerable, and bad. New stuff available, may also be vulnerable.

General Idea

Put the POW on the transactions. Ditch blocks entirely. Transactions get headers, can point to multiple parents (creating a DAG), get timestamps.

Yes, it's a hard fork.

Advantages

Not all DAG schemes are created equal. The one I'm about to propose:

+ Miners with poor network connections are not disadvantaged

+ Selfish mining is less effective (*pending full analysis - take with grain of salt)

+ Mining pool pressure significantly reduced - 1000s of payouts per 10 minutes

+ Controversial transactions are easier to mine (only need to POW 1 txn, not whole block)

Advantages Cont.

Not all DAG schemes are created equal. The one I'm about to propose:

+ Throughput can be increased

+ Orphan rates significantly reduced

+ Putting POW on your own transactions potentially reasonable - in today's environment, a $1000 ASIC could do the POW for a txn in ~45 minutes. If throughput is increased, could be as low as 10 minutes, $100 ASIC could maybe confirm a txn inside of a day

My primary goal is to further decentralize mining

Creating a braid

Given a bunch of transactions that point to each other, we need a canonical ordering. Each transaction gets a score, which is the sum difficulty of all the transactions in the dag below it. This score is known before the POW is completed, and cannot be changed by a reorg.

Creating a braid

When merging to tips of a chain, the transactions that have the most work are given preference. In the event of a tie, the ID of the merging transaction is used as a random number to pick the winner.

Reorgs

A reorg occurs if the canonical ordering is changed after some new transactions are introduced. Reorgs can only be as deep as the number of new transactions - to have a reorg 4 transactions deep, you need at least 4 un-merged transactions.

Reorg Complexity

Reorging, building the graph, and calculating the amount of work on the graph is all linear complexity in space and computation.

(error in pic, 'H' is pushed last)

(note - 'G' won the random ordering when picking G vs D)

Summary So Far

Given a bunch of transactions with weights and parents, we can form a canonical ordering. Reorgs are computationally manageable, and a reorg of depth X can only be triggered by merging a chaintip that has equal or more weight than the current tip - merging a lighter chaintip will never cause a reorg

Incentive Goals

+ Most profitable action is always to mine on the highest known chaintip

+ Most profitable action is always to merge other chaintips

+ 'Merged' transactions get the same reward despite not 'winning' the race.

Ratelimiting

+ Transaction difficulty set by validation cost.

+ Validation cost could be size, or some other metric/equation

+ Upsides: can have many cheap txns, or just a few expensive txns

+ Downsides: 1 heavy txn can reorg smaller txns, can have high luck which enables attacks. A maximum VC must be set.

Difficulty Retargeting

+ Open question. Ideally, it's a smooth function. Various altcoins have different methods, some are really bad. Some are probably improvements.

Difficulty Motion

+ If the difficulty changes every txn, and generally increases, txns that get ordered later may not have enough POW

+ POW requirement is decided by txn parents, not txn canonical order.

+ If a txn does a merge which moves a parent 'late', the txn must have extra work to compensate for the parent's shortcomings

Difficulty Motion

+ Multiple txns may point to the same 'merged' txn, which means those txns will be doubling up on the extra required work.

+ Oh well, it's safer to have too much work than too little, and does incentive coordination so that doubling up doesn't happen

Difficulty Motion

+ Difficulty for a txn can therefore be determined by how its graph looks before it is ever confirmed. The difficulty assumes that it will come immediately after its highest parent, and if it is dragging merged transactions into later spots than they were targeted it, it must do extra work on them.

Inflation

+ There is always inflation, which helps pay for mining.

+ Inflation per txn is decided by the POW requirement. Txns with more POW requirement get more inflation. This includes increased requirement from high validation costs, and from including parents which increase the difficulty

Inflation

+ To incentivize a clean graph, inflation is reduced for 'dirty' graphs.

+ A dirty graph has lots of merges, a clean graph has few merges

+ Clean graph has inflation as high as 5%, dirty graph has inflation as low as 3% (or pick your favorite numbers)

+ Everyone incentivized towards a clean graph

Why Incentivize Clean Graphs via Inflation?

+ Inflation effects everyone equally. Miners with poor network connections are going to cause dirtier graphs. This hurts them, because it means reduced inflation. But it hurts everyone equally, meaning that poorly networked miners are not disadvantaged in relative terms

Summary So Far

+ Canonical graphs w/sane reorg complexity

+ Difficulty determined by validation cost

+ Inflation given to txn based on difficulty

+ If there are lots of merges, long term inflation falls. If there are few merges, long term inflation increases.

Fees

+ Transactions can have fees. Not that pay to the miner mining the txn (that happens by manipulating 1 or more ouptuts), but to pay the miners confirming the transaction

+ Fee is distributed over the first X (potentially spread over 1 week) confirmations in the canonical ordering, decreasing linearly

Fees

+ Fee can pay children to cover any needed extra work (difficulty should not adjust *that* fast, not too much fee should be needed)

+ Fee decreases linearly so that there's no motivation for a child to not confirm the latest txn in a merged tip (favoring instead the fee from X transactions ago - confirming a txn on the tip will give the fee from X transactions ago to the tip, not the transaction with the work)

Bigger Picture

+ Potentially hundreds of txns unconfirmed

+ Miners each mining on only 1

+ Reduced risk of racing - most of the hashpower is probably grinding on some other txn

+ B/c race risk is reduced, slow network connections are less detrimental

Bigger Picture

+ Merging chaintips incentivized by fees

+ Merging chaintips incentivized by giving your transaction more work, therefore more priority, therefore less risk of being the smaller chaintip in a merge, therefore less risk of adding work requirement to child

+ Poorly networked miners are disadvantaged here, but it's not a big disadvantage

Bigger Picture

+ Selfish mining tries to increase the orphan rate of the network faster than of the self

+ Ability to merge chaintips means orphan attempts likely to be unsuccessful

+ High in-flight parallelism reduces orphan rates for everyone, reducing the impact of being poorly networked.

+ I've been unable to think of why selfish mining might work here. I am wary though.

Bigger Picture

+ Getting 1 confirmation should be much faster, especially if fees are higher. POW found many times per second, instead of every 10 minutes.

+ Chance of being reorg'd is very low once POW is found - chances increase as time without additional confirmations increase.

Bigger Picture

+ Out-of-band payments to big miners can speed up important transactions. A big miner might be able to get confirmations on a txn inside of 5 seconds. This is a centralization pressure.

+ Market for this probably not too big. Confirmation times for being in the mempool probably fast enough if miners probabilistically prefer high-fee txns

That's Basically It

+ Idea not fully specified, though specified enough that any glaring issues are hopefully easy to catch

+ Further refinement will happen if nobody finds some terrible flaw

+ Barring some terrible flaw, I think this is a huge improvement