Use Omni fees to prioritize transactions within a Bitcoin block.

[msgilligan]

Currently the logical order of Omni transactions within a Bitcoin block is determined by the Bitcoin miner who creates the valid block. The proposed enhancement is to use Omni fees to prioritize transactions within the Bitcoin block. This could be for all transactions or maybe just certain transactions (e.g. DEX transactions)

Advantages:

• Fees are optional - not required or needed for low priority transactions.
• It's a natural usage of Omni for something that Bitcoin doesn't provide.
• Fees will likely only be paid when DEX volume and value are high.

Disadvantages:

• Is a consensus change and would require implementation and activation
• Could potentially cause issues with Simple Send transactions (but you're always at risk of another transaction being prioritized ahead by a BTC miner)

[patrickdugan]

Oh this is much clearer now and I see it's not mutually exclusive with what we have now. This harkens back to an idea I had for an HFT-proofed decentralized clearing network back in 2014, where fees would settle the minute time differentials rather than more privelidged co-location deals.

I think like the burning of OMNI via revocation, this is something that could squeeze kerosene onto OMNI valuation at a later date. This one is less controversial than revocation as well.

[zathras-crypto]

Definitely some interesting ideas :)

Re burning Omni tokens for fees, I'm all for increasing the value of Omni but not at the expense of scalability. Burning Omni linearly in line with trading volume (eg via fees) means that our trading platform gets progressively more expensive to use with time and adoption (as there are less and less tokens available in circulation for fees the more trading that happens). A platform that gets progressively more expensive with use isn't one that's going to maintain an ongoing userbase imo. Note, this is irreversible (once burned, those tokens are gone).

In the short term sure I can see how reducing the total number of tokens could make each Omni token more valuable, but thinking longer term - I'm a bit concerned.

I liked the idea of shaving fees off the traded property, because we're transacting in the same property removing any concerns about the availability of tokens for fees. I worry about a new phase of requiring an address to be seeded with fees (this time in Omni), a problem we've only just solved on the BTC side. I realize auto-trading some of the traded property for Omni to cover fees has been proposed, but there is no guarantee that auto-trade can be filled, and without some kind of protections it's exploitable (eg when 99.99% of your trade amount is auto-traded to cover Omni fees because of a lack of liquidty on the other side of that token market).

In a nutshell I guess what I'm saying is if we want to burn Omni, we need to tread very carefully. Ideally we'd see some modelling of volumes against fees so we can see exactly how things would play out over time with various ranges of volumes.

Re allowing transactions to be ordered higher by paying a fee in Omni

Concern again regarding the Omni fee, depending on what happens with it. If burning I have the same feelings as above, but if STO'ing (distributing fees back to Omni holders proportionally) then the tokens stay in circulation so my objections there are moot.

Technically it could be done, we currently iterate a block processing the transactions in order - but it is feasible to iterate the block instead placing transactions in a collection, sorting the collection via fee then blockposition, then iterating the collection and processing the transactions in collection order. We'd need to see where else we rely on block positioning (such as RPC calls) but basically it can be done.

The question of whether to do this I'm not too sure. Allowing manipulation of the order of transactions in a block opens attack vectors. The most simplest of which would be:

• I have 100 Omni
• I simple send these 100 Omni to you - you see the incoming transaction (on OmniCore or 'Chest or whatever) and provide your service/product (whatever that may be)
• I simple send these same 100 Omni back to myself, but with an Omni fee

Currently, in almost all real-world scenarios, my send to you would be mined first (and thus ordered first) since blocks are constructed in the order transactions are received by a node (this is not guaranteed, but is common). With the new model, since sending back to yourself would be prioritized higher you have effectively pulled off a double spend.

We strongly discourage people from acting on unconfirmed transactions precisely because the order is not known until the block confirms, but we have to be realistic and recognize people do act on unconfirmed transactions despite our assertions to the contrary (evidenced by the fact it was basically the most requested feature for Omni Core and 'Chest). So again, I think we need to be really careful about how we proceed - transaction order is fundamental to consensus so allowing it's manipulation via fees is a risky path that needs some serious benefit to be worth it (just imo).

Please don't think that's just negativity - I'm just trying to think things through... I like ideas, keep 'em coming :)

Thanks Z

[dexX7]

The proposed enhancement is to use Omni fees to prioritize transactions within the Bitcoin block.

Well, why not just use higher bitcoin fees? Although I have no data to show it, I'd assume miners prioritize transactions in a block based on fees, so adding more fees has likely a similar effect.

Furthermore, the use case isn't clear to me: if the only intention is to order transactions sent from the same source, then it would also be possible to chain the transactions (i.e. spend the change from transaction n in transaction n+1). If the goal is to prioritize transactions over others, e.g. to frontrun and fill trades before someone else does, then it's another story though. :)

[zathras-crypto]

Well, why not just use higher bitcoin fees?

I get the impression it's to provide an additional "need" for Omni.

Although I have no data to show it, I'd assume miners prioritize transactions in a block based on fees, so adding more fees has likely a similar effect.

I'm not so sure this is the case - miners do prioritize which transactions make it into blocks based on fees I agree, but their order within the block I do not believe is influenced by transaction fee. If we're interested in a data set here we could use Omni Core to gather this data for the last n blocks - just shout if you want me to head down this path :)

Furthermore, the use case isn't clear to me

Being "first in" on a favourable trade as far as I understood the brief conversation we had on it at the meeting.

Hope you're feeling a bit better dude :)