Talk:Protocol rules - Revision history

Airbreather: /* Clarification of what is rejected during block verification */

2014-03-11T00:50:58Z

Clarification of what is rejected during block verification

← Older revision		Revision as of 00:50, 11 March 2014
Line 24:		Line 24:

	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.		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)

Rghugh: /* Clarification of what is rejected during block verification */ new section

2012-08-19T22:45:32Z

Clarification of what is rejected during block verification: new section

← Older revision		Revision as of 22:45, 19 August 2012
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.

Rebroad at 13:33, 8 April 2012

2012-04-08T13:33:44Z

← Older revision		Revision as of 13:33, 8 April 2012
Line 17:		Line 17:

	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.		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!! --[[User:Rebroad\|Rebroad]] 13:33, 8 April 2012 (GMT)

TierNolan: Created page with "= Proposed Recommended Rule Changes = == Transaction override == === Change === {| class="wikitable" |- | Before|| Tx || 9 || Reject if any other tx in the pool uses the same ..."

2011-06-26T12:53:56Z

Created page with "= Proposed Recommended Rule Changes = == Transaction override == === Change === {| class="wikitable" |- | Before|| Tx || 9 || Reject if any other tx in the pool uses the same ..."

New page

= Proposed Recommended Rule Changes =

== Transaction override ==

=== Change ===

{| class="wikitable"
|-
| 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.