Re: 300 BTC Coding Contest: Distributed Exchange (MasterCoin Developer Thread)
We could indeed fall back to peek and decode however right now the spec says:
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?
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
have we had a conversation already about allowing/disallowing based on whether output amounts are the same?Thanks!
