Need OP_BLOCKNUMBER to allow "time" limited transactions
At the moment, if you make a payment to someone but they’ve wiped their wallet then the coins are irretrievably lost. Similarly, if the network is flooded with 0.01 fee transactions and you make an urgent payment but forget to include a higher fee then you can’t reissue that payment backed by the same coins but with a fee.
If you could cause the current block number to be pushed on the stack and do some maths with it then you could implement a payment that must be spent by the recipient before a certain block number is reached or else the script would allow it to be spent again by the sender for example.
I suspect that this would be a very popular transaction mechanic.
ByteCoin
That would be useful, but it’s probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.
That would be useful, but it’s probably best to keep scripts stateless. Since different nodes might have different ideas about what the current blockcount is, a situation could develop where half the network considers a transaction valid and half considers it invalid. This is not good for the network.
Hmm.. If clients disagree about what the current block count is then they already disagree about whether certain transactions are valid or not and therefore the problem you mention exists already without my proposal. Please go into more detail about why this is not good for the network.
ByteCoin
After investigating some more, I found that nLockTime requires in-memory transaction replacement to be re-activated for it to be useful.
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (!IsNewerThan(*ptxOld))
return false;
for (int i = 0; i < vin.size(); i++)
{
COutPoint outpoint = vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx != ptxOld)
return false;
}
break;We can’t safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn’t be fair to later owners of the coins who weren’t involved in the time limited transaction.
nTimeLock does the reverse. It’s an open transaction that can be replaced with new versions until the deadline. It can’t be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn’t enabled or used yet, but the support is there so it could be implemented later.
nTimeLock does the reverse. It’s an open transaction that can be replaced with new versions until the deadline. It can’t be recorded until it locks. The highest version when the deadline hits gets recorded. It could be used, for example, to write an escrow transaction that will automatically permanently lock and go through unless it is revoked before the deadline. The feature isn’t enabled or used yet, but the support is there so it could be implemented later.
Does using nTimeLock also tie up some of the sender’s coins until the lock expires? I imagine that it would have to, and that would solve the escrow problem immediately, allowing the sender to effectively write the Bitcoin version of a backdated check. Even better, seeing the locked transaction on the network would allow the merchant to know that the sender actually does have the funds to buy the product, and if the coins are tied up until the lock expires, that the sender will probably still have those same funds. The possibility of a fraudster sending a locked transaction to buy something online, and then revoking the transaction after the product has been shipped, still exists. But it can add confidence in a transaction without requiring a third party escrow. Would the revocation of transactions leave a record inside or outside the blockchain? If it did, a scan of the blockchain might be able to highlight increased risks of a revoked transaction if a fraudster had already done the scam once to someone else with the same set of coins. Doing this would temporarily ‘taint’ the coins used in the revoked transaction, until they were used in several valid transactions.
We can’t safely do OP_BLOCKNUMBER. In the event of a block chain reorg after a segmentation, transactions need to be able to get into the chain in a later block. The OP_BLOCKNUMBER transaction and all its dependants would become invalid. This wouldn’t be fair to later owners of the coins who weren’t involved in the time limited transaction.
OP_BLOCKNUMBER does not introduce any new vulnurabilities compared to the existing system as segmentation can be exploited to defraud people at the moment. This is accomplished as follows:
An opportunistic attacker has clients running in multiple locations around the world. The attacker’s clients have the same wallets and connect to different subsets of peers, probably perferring local ones and definitely keeping in touch with local mining peers. The clients communicate with each other at intervals to check whether the network has segmented and exchange the list of peers that they are talking to. If communication is lost to one or more of the attacker’s clients (they go offline) then the remaining clients attempt to communicate with all the offline client’s peers. If they all succeed then it’s likely that that attacker’s client has just crashed or lost its internet connection. If however that client goes offline and a number of the peers are uncontactable then it’s possible that the network has segmented. The attacker’s clients determine whether they are on the network portion with the majority of the mining power or the minority. They also guess whether the other inaccessible portion of the network has enough mining power to generate blocks over the time it is imagined to be isolated. If the conditions are favourable then the attack proceeds as follows: The attacker’s clients on the majority of the network send coins from the wallet to new addresses in plausible innocent looking transactions. The attacker’s clients on the minority of the network use the same coins in the same wallet to buy whatever goods they can find for sale on the subnetwork. When the network joins up again, it’s highly likely that the majority part of the network has generated more blocks and all the transactions in blocks on the minority part of the chain re-enter the transaction pool. The attacker’s transactions on the shorter chain are discarded as the coins have already been spent on the longer chain. Fraud complete!
So you can see that OP_BLOCKNUMBER does not introduce any new risks and that the real prevention of segmentation-based fraud must rely on some sort of detection of the loss of mining power.
ByteCoin