summaryrefslogtreecommitdiff
path: root/71/0996a9ae4f5d8c349f57114a240c0151e065f0
blob: 8cbd0a35cb064ac452192b4bbeaa529891cb1c01 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3DC05F9C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jan 2018 07:28:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com
	[62.13.148.110])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84AE2134
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 24 Jan 2018 07:28:40 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
	by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0O7ScUS036766;
	Wed, 24 Jan 2018 07:28:38 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w0O7SaGu044406
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); 
	Wed, 24 Jan 2018 07:28:37 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id F33BC4010A;
	Wed, 24 Jan 2018 07:28:35 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id 0AAAF209B1; Wed, 24 Jan 2018 02:28:35 -0500 (EST)
Date: Wed, 24 Jan 2018 02:28:35 -0500
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <greg@xiph.org>
Message-ID: <20180124072835.GB12767@savin.petertodd.org>
References: <M8yPGuNmrXfNNwrYDDLpTVb__BhGysVW060Cq_tMc-AC6F7pKd1Vvb4wWbpmhhEvfoQ7fn-EcgfxRwJSVkFAZ5x57hg9XxpdZlDPi2IBJZg=@protonmail.com>
	<20180122200023.GA1055@savin.petertodd.org>
	<CAAS2fgSJ=2GaX-fNRyZhwD=g6=v524hnD-dCqJicC-ak+La4PA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT"
Content-Disposition: inline
In-Reply-To: <CAAS2fgSJ=2GaX-fNRyZhwD=g6=v524hnD-dCqJicC-ak+La4PA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 3176774b-00d8-11e8-8106-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAYUElQaAgsB Am4bW1NeUlV7WmQ7 bghPaBtcak9QXgdq
	T0pMXVMcUwUXBn9Q cVseVh12dwMIeX92 Z0MsXXFcWkN9cRRg
	Qk4AHXAHZDJodWge UEZFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
	FAgyOXU9MCtqYBhP SwcWJFkOQEENVhsx XR8DGzpnXUcEX3xp
	clQ8J1oVDE8NM0I0 cDMA
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jan 2018 07:28:41 -0000


--+pHx0qQiF2pBVqBT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 23, 2018 at 09:31:00PM +0000, Gregory Maxwell wrote:
> 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.
>=20
> 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.
>=20
> 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).
>=20
> Achow101 and Murch have code to implement an efficient algorithm for
> finding these solutions for Bitcoin core which will hopefully get in
> soon.

Oh, Bitcoin Core doesn't already do that? I though that was what the (rather
complex) knapsack code was supposed to be doing.

In any case, you're assuming that there actually are a large number of outp=
uts.
That's not likely to be the case in most "consumer-like" use-cases where the
number of deposits into the wallet is relatively low compared to the number=
 of
withdrawls as coins are spent in smaller amounts; that's the pattern most o=
f my
Bitcoin usage follows, particularly as I keep the amount of funds in my hot
wallets low.

Having said that, Rhavar's usage patterns could easily be different; I'd be
completely wrong in the case of a payment service for instance where a large
number of deposits are aggregated into a smaller number of payments; that
use-case happens to be a particularly interesting one for using tx replacem=
ent
to add outputs, so my criticism was definitely premature.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--+pHx0qQiF2pBVqBT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaaDWfAAoJECSBQD2l8JH7UUwIAKNFzcTR1CV+3sRuIbJJSMOv
UFUPblJVbbkOcr/Qz0q3QYKf9J3TjtMrrKP+2KI+Weh1ZHGfPM05ZQJZP7PbfuAQ
BDTcenglQK3bx164NReAOwt08rFXjZZ6JFSIcxaQfmEGV82tXu6tpT9czsG1QW3p
s6NCu/99YkJpBQe23DsMa0G0HXrhHpNVOXWWqCUJ1WhV7WrxFxlmSkTc+PvPB6nF
MVqch/PVWq8auc+cbCU96j7ldBndBNGKw/Yvo0EpeTm8oYJ07kYWNLtHYqw7hHu9
Z1lJFslxWuFaWYDaT006kPFq2wYuGL4wzqkr8RzQLic4d+WjF1OCVBuAZxjTZ+Q=
=hv1t
-----END PGP SIGNATURE-----

--+pHx0qQiF2pBVqBT--