Talk:Protocol rules: Difference between revisions
No edit summary |
Airbreather (talk | contribs) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 20: | Line 20: | ||
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!! --[[User:Rebroad|Rebroad]] 13:33, 8 April 2012 (GMT) | 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!! --[[User:Rebroad|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. [[User:Airbreather|Airbreather]] ([[User talk:Airbreather|talk]]) 00:50, 11 March 2014 (GMT) | |||
Latest revision as of 00:50, 11 March 2014
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)