A number of users in the community have expressed frustrations with the current max order expiration of 8064 blocks (2 months). The purpose of this post is to discuss interest in increasing the max order expiration and if so, what should the max allowed be?
1.) Could increasing the max_expiration have any negative effects on the CP system (more orders to check for matches each block, etc)?
2.) What should the max_expiration be increased to? (48,384 blocks = 1 year)
Unless I’m mistaken the core protocol’ limit is 65535 blocks (about 455 days).
The 8064 limit is likely a wallet soft cap.
At least the orders table does have some expirations set at 65535 in 2014. There are also a few at 30000 blocks from 2017.
The max value makes sense because the expiration value takes up two bytes in the op_return message (256^2 = 65536).
To answer your questions:
I don’t know much about DB design but I guess CP checks the orders_expiration table at every block for matching block_index. All orders, current and past, are in this table. So I guess it won’t matter if there are more open orders?
How about allowing orders never to expire? Add an optional one byte to the end of the order op_return message. If value=1, never expire. Benefit; no need to add such orders to the order_expirations table.
In a wider sense, I believe no expiry could be the wallet default. Often times you own some illiquid token you hope to sell for X btc (or xcp) one day. I myself have wanted to buy some vintage gems but there are no open orders. How cool wouldn’t it be if there had still been sell orders around from 2014?
I am in favor of a longer max expiration to orders and 1 year seems appropriate.
From some of Bob’s and Duncan’s discussion the telegram. I could be also in favor of the possibility to have an xcp fee to have longer lasting orders than one year if possible. Assuming this does not ‘bloat’ the network in some way.