First, it is fill or kill (FOK), this is how this type of order is called on financial markets.
Yes it would be good to have and yes it can not be introduced because of Bitcoin's lack of final settlement.
I wrote about why final settlement would be a good idea too here:
https://bitcointalksearch.org/topic/introduce-reorg-limit-for-guaranteed-settlement-and-attack-resilience-962064
Topic: What about fill or kill transactions? (Read 2218 times)
I think a minimum and maximum block height are worthwhile additions for a transaction record.
The suggested maximum block - "Absolutely do not include this transaction in a block later than N" - is an excellent way to set up a transaction so that you know when it has, definitely, FAILED to be included in the block chain and you can do other stuff with the inputs.
The suggested maximum block - "Absolutely do not include this transaction in a block later than N" - is an excellent way to set up a transaction so that you know when it has, definitely, FAILED to be included in the block chain and you can do other stuff with the inputs.
Gmaxwell already pointed out why this is a bad idea.
Say you have a transaction which can only be included between before block 300,000 and it manages to get included in block 299,999.
By the time the chain hits 300,006, it will be considered a confirmed transactions. Other transactions can spend its outputs and also the outputs from those transactions can be spent. This means that lots of transactions can end up depending on that one transaction.
If there is a re-org that replaces block 299,999 with another block that doesn't include the transaction, then the transaction cannot be included in 300,000, so it must be discarded. This cancels all transactions that depend on that transaction and also all transactions that depend on those and so on.
Normally, if a re-org changes a block, you can normally just include the transaction in the next block.
Double spends are different. The point is that even with completely honest users, a maximum block height rule means that transaction (and all decedent transactions) can end up being invalidated.
Quote
But I'm not going to spearhead any attempt to hard fork in order to get these things added.
It wouldn't necessarily be a hard-fork, depending on how it is implemented. You are converting transactions which are "spend anytime" to "spend before height h". Forks which make the rules more strict are soft-forks.
I think a minimum and maximum block height are worthwhile additions for a transaction record.
The suggested maximum block - "Absolutely do not include this transaction in a block later than N" - is an excellent way to set up a transaction so that you know when it has, definitely, FAILED to be included in the block chain and you can do other stuff with the inputs.
It would be very valuable (as would a corresponding minimum block - "Absolutely do not include this transaction in a block before N") - to make a certain number of nonstandard transactions ( protocols and exchanges) a hell of a lot simpler and faster (and easier to understand and explain) if we had it.
But I'm not going to spearhead any attempt to hard fork in order to get these things added.
The suggested maximum block - "Absolutely do not include this transaction in a block later than N" - is an excellent way to set up a transaction so that you know when it has, definitely, FAILED to be included in the block chain and you can do other stuff with the inputs.
It would be very valuable (as would a corresponding minimum block - "Absolutely do not include this transaction in a block before N") - to make a certain number of nonstandard transactions ( protocols and exchanges) a hell of a lot simpler and faster (and easier to understand and explain) if we had it.
But I'm not going to spearhead any attempt to hard fork in order to get these things added.
how about the pete replace by fee but only allow it for adding more fees to the same TX. ?
Like outputs must be the same, except for the change.
Like outputs must be the same, except for the change.
There is no way to know which output is the change. It is just another output. You could add a new input, raise the fee and a new output (second change). That is a secure way to implement replacement by fee. The idea was that a kill or fill could eliminate that complexity.
how about the pete replace by fee but only allow it for adding more fees to the same TX. ?
Like outputs must be the same, except for the change.
Like outputs must be the same, except for the change.
An invariant we've tried to avoid breaking is reorg safety.
Right now, if you receive a coin and all the participants in that coin are honest (and we fix/ignore malleability), no* reorg will make the coin become invalid. (*)This is broken for recent coinbase created coins, but 'fixed' by making them undependable for 100 blocks; so at least all coins you see confirmed are equivalent in their reorg safety for reorgs up to 100 blocks.
Absent this you can get fun problems where a reorg can break an exponentially widening cone of transactions by accident or malice (on the part of someone who wasn't a participant). To avoid it you might want to refuse to accept a coin which has had an unsafe event in its recent history, but absent the network informing you of this (e.g. by not allowing confirmation in the case of coinbase spends) you have to do potentially exponential work to check for these events, and checking-- of course-- makes the coins less fungible.
FOK can already be handled by successfully conflicting with another spend... and you already wanted to get a transaction confirmed in any case, if you didn't care you wouldn't mind that it hasn't gone through yet. In that case only a parties to the unconfirmed transaction can kill, and I think thats generally better than letting miners (or chance) handle it.
But at the same time, some useful things are incompatible with reorg safety (e.g. using the blockchain as a random beacon in transactions) and I can't say with confidence that the improved fungibility of strong reorg safety justifies not having those properties.... it's just something to think carefully about. May well be that some kind of coinbase-like or state flagging (e.g. you can spend an immature unsafe coin, but your spend has to propagate a time till mature counter which is the max of the inputs counters) approach may be an adequate balance for these concerns.
Right now, if you receive a coin and all the participants in that coin are honest (and we fix/ignore malleability), no* reorg will make the coin become invalid. (*)This is broken for recent coinbase created coins, but 'fixed' by making them undependable for 100 blocks; so at least all coins you see confirmed are equivalent in their reorg safety for reorgs up to 100 blocks.
Absent this you can get fun problems where a reorg can break an exponentially widening cone of transactions by accident or malice (on the part of someone who wasn't a participant). To avoid it you might want to refuse to accept a coin which has had an unsafe event in its recent history, but absent the network informing you of this (e.g. by not allowing confirmation in the case of coinbase spends) you have to do potentially exponential work to check for these events, and checking-- of course-- makes the coins less fungible.
FOK can already be handled by successfully conflicting with another spend... and you already wanted to get a transaction confirmed in any case, if you didn't care you wouldn't mind that it hasn't gone through yet. In that case only a parties to the unconfirmed transaction can kill, and I think thats generally better than letting miners (or chance) handle it.
But at the same time, some useful things are incompatible with reorg safety (e.g. using the blockchain as a random beacon in transactions) and I can't say with confidence that the improved fungibility of strong reorg safety justifies not having those properties.... it's just something to think carefully about. May well be that some kind of coinbase-like or state flagging (e.g. you can spend an immature unsafe coin, but your spend has to propagate a time till mature counter which is the max of the inputs counters) approach may be an adequate balance for these concerns.
Interesting concept.
I'll have to give it some thought tonight and see if any concerns come to mind.
I'll have to give it some thought tonight and see if any concerns come to mind.
In the stock trading world, fill or kill is trade type which indicates the order should either execute immediately or be deleted. Could something like this be used in a blockchain based system to prevent "stuck" transactions?
The problem:
Due to outdated priority rules, user misunderstanding, or wallet bugs users can create transactions which are very unlikely to confirm or even be relayed through most nodes. However most wallets have no good method to cancel. Cancelling txns is complex. A simple cancel button would creating confusion and unexpected results. The wallet software could remove the txn locally but it can't force other nodes to remove their copies. This means the txn could be 'confirmed' long after it is 'canceled'. Waiting is also not a good solution and can be confusing to users. The time before a txn is removed from a node's memory pool is not static and the txn may be removed from some but not all nodes. Many clients will continue to rebroadcast unconfirmed txns which 'reset' the clock. Users also have no way of knowing if copies of the txn remain. This means the network appears to have 'inconsistent' behavior. Something more robust is needed to provide deterministic behavior.
The solution:
What about including a max block height flag? This could be setup very similar to nlocktime except that it would designate the last block the txn can be confirmed in, instead of the first one. Once the kof height has been created the txn would no longer be valid for inclusion in a block. To simplify dealing with reorgs it would be a good idea for nodes to keep the txn in the memory pool but not considered for inclusion in a block until the current block height is a small number of blocks ahead of the kof height and then delete the txn. The user would have a high level of confidence that after the kof height the txn could be resubmitted to the network with a more appropriate fee. The user's client would change the status of the txn to canceled once the kof height has been passed and increase the 'available balance' which would be consistent with user expectations and help to hide the network behavior in a deterministic manner.
Any potential attack vectors or complications?
The problem:
Due to outdated priority rules, user misunderstanding, or wallet bugs users can create transactions which are very unlikely to confirm or even be relayed through most nodes. However most wallets have no good method to cancel. Cancelling txns is complex. A simple cancel button would creating confusion and unexpected results. The wallet software could remove the txn locally but it can't force other nodes to remove their copies. This means the txn could be 'confirmed' long after it is 'canceled'. Waiting is also not a good solution and can be confusing to users. The time before a txn is removed from a node's memory pool is not static and the txn may be removed from some but not all nodes. Many clients will continue to rebroadcast unconfirmed txns which 'reset' the clock. Users also have no way of knowing if copies of the txn remain. This means the network appears to have 'inconsistent' behavior. Something more robust is needed to provide deterministic behavior.
The solution:
What about including a max block height flag? This could be setup very similar to nlocktime except that it would designate the last block the txn can be confirmed in, instead of the first one. Once the kof height has been created the txn would no longer be valid for inclusion in a block. To simplify dealing with reorgs it would be a good idea for nodes to keep the txn in the memory pool but not considered for inclusion in a block until the current block height is a small number of blocks ahead of the kof height and then delete the txn. The user would have a high level of confidence that after the kof height the txn could be resubmitted to the network with a more appropriate fee. The user's client would change the status of the txn to canceled once the kof height has been passed and increase the 'available balance' which would be consistent with user expectations and help to hide the network behavior in a deterministic manner.
Any potential attack vectors or complications?
Jump to: