Talk:Protocol rules

Proposed Recommended Rule Changes

Transaction override

Change

Before	Tx	9	Reject if any other tx in the pool uses the same transaction output as one used by this tx.
After	Tx	9	Reject if any other tx in the pool uses the same transaction output as one used by this tx, and has a greater or equal transaction fee

Rationale

When the default client sends a transaction without a sufficient transaction fee to complete, the coin ends up in limbo. The default client won't allow spending of any of the input coins, but the network won't forward the coin to any neighbours. This means that miners never add the coin to the chain.

This change would allow the client to re-send the transaction with an increased fee. Clients which already saw the old transaction will still forward the new transaction, since it has a higher fee. The client could even prompt the user about any transaction which has been pending for more than an hour or 2.

I think this proposal makes a lot of sense. Also, if someone did try to double-spend in a way that could be mined, but not gossiped on the network, then this would be bad.. I'd far rather have the double-spend attempt gossiped, so that my wallet can see it and put a big question mark against the transaction!! --Rebroad 13:33, 8 April 2012 (GMT)

Clarification of what is rejected during block verification

With the sentences like "For each input, if we are using the nth output of the earlier transaction, but it has fewer than n+1 outputs, reject", it's not clear what's being rejected: the input, the transaction, or the block. Please could this be stated explicitly in each case.

I thought it was pretty clear when I read this. From a step entitled "x verification", there are two possible results (ignoring side effects): "x is accepted" or "x is rejected". Therefore "reject" in such a step means to immediately follow the "x is rejected" branch. Short answer: the block is rejected. Airbreather (talk) 00:50, 11 March 2014 (GMT)