MIME-Version: 1.0
Sender: gmaxwell@gmail.com
In-Reply-To: <20180122200023.GA1055@savin.petertodd.org>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
	<20180122200023.GA1055@savin.petertodd.org>
From: Gregory Maxwell <greg@xiph.org>
Date: Tue, 23 Jan 2018 21:31:00 +0000
Message-ID: <CAAS2fgSJ=2GaX-fNRyZhwD=g6=v524hnD-dCqJicC-ak+La4PA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
Precedence: list

On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Most transactions don't have change?! Under what circumstance? For most
> use-cases the reverse is true: almost all all transactions have change, because
> it's rare for the inputs to exactly math the requested payment.

It's quite easy to get no change with a not-dumb algorithm selecting
coins if you have a decent number of outputs well under the value
you're paying.

The number of ways n choose m combines grows exponentially, and you
only need to get close enough over the right value so that you're
paying excess fees equal or less than the cost of the change (which
should include the current cost output itself as well as estimated
cost of the future signature to spend it).

Achow101 and Murch have code to implement an efficient algorithm for
finding these solutions for Bitcoin core which will hopefully get in
soon.