Quote from: Tachikoma on December 17, 2013, 07:17:20 PM

We could indeed fall back to peek and decode however right now the spec says:

Quote

Has all output values equal & above the 'dust' threshold (currently 0.00005430 BTC). An additional output is permitted for the remainder of the input (the 'change' address).

I have a feeling that allowing p&d on unequal output values might increase the risk of a change address being assigned as recipient address by accident.

I really want to catch human error whenever possible and support as many formats as possible but on the other hand when an error was clearly made it rather have it be invalidated then sent to the wrong address.

Can anybody think of a reason that could sway the argument one way or an other?

Good point, I've been focusing too much on the section below that (where p&d is described). JR (I assume) changed the wording when merging the appendix and made it:

Quote

Ideally, all outputs should be the same (except the change).

The term 'ideally' implies that it's not enforced. My appendix as submitted didn't have the word 'ideally' in it so I thought I'd forgotten something somewhere and JR had added the term to show that it wasn't an enforceable requirement.

It's all starting to blur together Wink

have we had a conversation already about allowing/disallowing based on whether output amounts are the same?

Thanks!