[wallet] Adjust MIN_CHANGE #6696

1. 
   MarcoFalke commented at 3:28 pm on September 18, 2015: member

   According to recent exchange rates avoiding change of some value between 1 and 10 USD is no longer reasonable: E.g. a bunch of people tipped me .35 USD. Whenever I want to send those tips, the transaction includes 7 of them just to send back to me.

   • fixes #6522
   • fixes #1643
2. laanwj added the label Wallet on Sep 21, 2015
3. MarcoFalke force-pushed on Nov 4, 2015
4. MarcoFalke force-pushed on Nov 4, 2015
5. MarcoFalke renamed this:
   [wallet] Adjust nMinChange
   [wallet] Adjust MIN_CHANGE
   on Nov 4, 2015
6. 
   fanquake commented at 8:40 am on November 11, 2015: member

   The test failure is on the Windows build, and unrelated

   0WARNING: The following packages cannot be authenticated!
   1  liblcms2-2 liblcms2-2 wine1.7-amd64 wine1.7-i386 wine1.7
   2E: There are problems and -y was used without --force-yes
   3The command "sudo apt-get install --no-install-recommends --no-upgrade -qq nsis gcc-mingw-w64-x86-64 g++-mingw-w64-x86-64 binutils-mingw-w64-x86-64 mingw-w64-dev wine1.7 bc" failed. Retrying, 3 of 3.
   

7. MarcoFalke force-pushed on Nov 12, 2015
8. 
   morcos commented at 6:35 pm on December 10, 2015: member

   hmm, i’d suggest that perhaps MIN_CHANGE could depend on the input amounts? otherwise it seems like this might be too drastic a change.
9. 
   MarcoFalke commented at 11:24 am on December 16, 2015: member

   The tests assume that the minimum change is static, so they’d need to be adjusted as well if the minimum change now depends on the target value.
10. 
    jonasschnelli commented at 12:27 pm on January 20, 2016: contributor

    The current MIN_CHANGE is 1000000 bits (0.01 BTC) and I agree that this is relatively high. This change would reduce the static MIN_CHANGE to 1000 bits (0.00001) which is to low IMO and might result in dust/uneconomic inputs.

    Also I’m not sure if coupling it with DEFAULT_TRANSACTION_MINFEE (or other fee relevant vars) is the right thing, because it’s unknown when the change output will be used as input (1-2 years)?

    I tend to keep the value high to prevent from creating dusty outputs (assume fees are rising). But maybe I’m looking at it from the wrong perspective. So correct me if i’m wrong. Tend to NACK.

11. 
    MarcoFalke commented at 12:57 pm on January 20, 2016: member

    I created this pull to see what other opinions exist.

    Basically, changing the defaults to work around bugs is not the right way. Instead the wallet code should select coins more intelligent to prevent large transactions and also prevent combining inputs from many different addresses.

12. 
    MarcoFalke commented at 12:59 pm on January 20, 2016: member

    A one-line adjustment for 0.12 with something like CENT/10 could make sense in the short term, though.

    I plan to address the wallet code changes until 0.13 or 0.14.

13. 
    jonasschnelli commented at 1:03 pm on January 20, 2016: contributor

    […] A one-line adjustment for 0.12 with something like CENT/10

    Agree. But not sure about 0.12. Rc1 is already out and we might want to keep the existing MIN_CHANGE behavior in 0.12.

14. [wallet] Adjust MIN_CHANGE to 0.001 BTC fae5ea4a9a
15. MarcoFalke force-pushed on Jan 20, 2016
16. 
    MarcoFalke commented at 8:10 pm on January 20, 2016: member

    I will think about this and open a new pull next week.
17. MarcoFalke closed this on Jan 20, 2016

    ---

18. MarcoFalke deleted the branch on Jan 20, 2016
19. DrahtBot locked this on Sep 8, 2021

Contributors
MarcoFalke fanquake morcos jonasschnelli

Labels
Wallet