1 2017-07-05T00:01:22  *** PaulCapestany has quit IRC
  2 2017-07-05T00:02:46  *** PaulCapestany has joined #bitcoin-core-dev
  3 2017-07-05T00:04:59  *** btcdrak has joined #bitcoin-core-dev
  4 2017-07-05T00:07:30  *** PaulCapestany has quit IRC
  5 2017-07-05T00:09:33  *** PaulCapestany has joined #bitcoin-core-dev
  6 2017-07-05T00:09:57  *** chjj has quit IRC
  7 2017-07-05T00:14:28  *** PaulCapestany has quit IRC
  8 2017-07-05T00:20:20  *** PaulCapestany has joined #bitcoin-core-dev
  9 2017-07-05T00:24:04  *** PaulCapestany has quit IRC
 10 2017-07-05T00:26:19  *** PaulCapestany has joined #bitcoin-core-dev
 11 2017-07-05T00:33:27  *** chjj has joined #bitcoin-core-dev
 12 2017-07-05T00:34:04  *** Cheeseo has quit IRC
 13 2017-07-05T00:39:24  *** btcdrak has quit IRC
 14 2017-07-05T00:40:23  *** btcdrak has joined #bitcoin-core-dev
 15 2017-07-05T00:51:51  *** Aaronvan_ has joined #bitcoin-core-dev
 16 2017-07-05T00:54:40  *** AaronvanW has quit IRC
 17 2017-07-05T01:06:03  *** Aaronvan_ has quit IRC
 18 2017-07-05T01:06:39  *** AaronvanW has joined #bitcoin-core-dev
 19 2017-07-05T01:07:47  *** dabura667 has joined #bitcoin-core-dev
 20 2017-07-05T01:10:09  *** unholymachine has joined #bitcoin-core-dev
 21 2017-07-05T01:10:52  *** AaronvanW has quit IRC
 22 2017-07-05T01:32:11  *** fengling_ is now known as fengling
 23 2017-07-05T02:33:05  <bitcoin-git> [bitcoin] luke-jr opened pull request #10745: Be consistent in using "opt_into_rbf" parameter for Opt-In RBF (master...opt_in_rbf-param) https://github.com/bitcoin/bitcoin/pull/10745
 24 2017-07-05T02:45:19  *** ivan_ has joined #bitcoin-core-dev
 25 2017-07-05T02:55:24  *** RubenSomsen has joined #bitcoin-core-dev
 26 2017-07-05T02:56:49  *** RubenSomsen has quit IRC
 27 2017-07-05T02:57:10  *** RubenSomsen has joined #bitcoin-core-dev
 28 2017-07-05T03:06:05  *** ivan_ is now known as ivan
 29 2017-07-05T03:10:17  *** echonaut has quit IRC
 30 2017-07-05T03:10:30  *** echonaut has joined #bitcoin-core-dev
 31 2017-07-05T03:23:44  *** Murch has joined #bitcoin-core-dev
 32 2017-07-05T03:28:25  *** Murch has quit IRC
 33 2017-07-05T04:03:04  *** justan0theruser has joined #bitcoin-core-dev
 34 2017-07-05T04:06:08  *** justanotheruser has quit IRC
 35 2017-07-05T04:08:20  *** AaronvanW has joined #bitcoin-core-dev
 36 2017-07-05T04:11:47  *** atroxes has quit IRC
 37 2017-07-05T04:12:25  *** draadpiraat[m] has quit IRC
 38 2017-07-05T04:12:46  *** AaronvanW has quit IRC
 39 2017-07-05T04:12:56  *** atroxes has joined #bitcoin-core-dev
 40 2017-07-05T04:13:40  *** draadpiraat[m] has joined #bitcoin-core-dev
 41 2017-07-05T04:14:48  *** coredump_ has joined #bitcoin-core-dev
 42 2017-07-05T04:18:27  *** goofie has quit IRC
 43 2017-07-05T04:20:22  *** cysm has quit IRC
 44 2017-07-05T04:24:01  *** justan0theruser has quit IRC
 45 2017-07-05T04:24:19  *** justanotheruser has joined #bitcoin-core-dev
 46 2017-07-05T04:34:13  *** cysm has joined #bitcoin-core-dev
 47 2017-07-05T06:09:57  *** AaronvanW has joined #bitcoin-core-dev
 48 2017-07-05T06:14:05  *** AaronvanW has quit IRC
 49 2017-07-05T06:25:11  *** afk11 has quit IRC
 50 2017-07-05T06:25:56  *** afk11 has joined #bitcoin-core-dev
 51 2017-07-05T06:34:43  *** Ylbam has joined #bitcoin-core-dev
 52 2017-07-05T06:38:02  *** arowser has quit IRC
 53 2017-07-05T06:44:09  *** arowser has joined #bitcoin-core-dev
 54 2017-07-05T06:47:15  *** RubenSomsen has quit IRC
 55 2017-07-05T07:02:26  *** goatpig has joined #bitcoin-core-dev
 56 2017-07-05T07:37:23  *** coredump_ has quit IRC
 57 2017-07-05T07:40:24  *** laurentmt has joined #bitcoin-core-dev
 58 2017-07-05T07:46:04  *** laurentmt has quit IRC
 59 2017-07-05T08:10:40  *** AaronvanW has joined #bitcoin-core-dev
 60 2017-07-05T08:15:08  *** AaronvanW has quit IRC
 61 2017-07-05T08:15:25  *** schnerchi has quit IRC
 62 2017-07-05T08:21:39  *** timothy has joined #bitcoin-core-dev
 63 2017-07-05T08:24:22  *** schnerchi has joined #bitcoin-core-dev
 64 2017-07-05T08:25:16  *** Deadhand has quit IRC
 65 2017-07-05T08:29:05  *** Deadhand has joined #bitcoin-core-dev
 66 2017-07-05T08:54:56  *** riemann has joined #bitcoin-core-dev
 67 2017-07-05T08:58:13  *** Ylbam has quit IRC
 68 2017-07-05T09:11:59  *** AaronvanW has joined #bitcoin-core-dev
 69 2017-07-05T09:23:25  *** Aaronvan_ has joined #bitcoin-core-dev
 70 2017-07-05T09:26:23  *** AaronvanW has quit IRC
 71 2017-07-05T09:30:54  *** Guyver2 has joined #bitcoin-core-dev
 72 2017-07-05T10:00:44  *** SopaXorzTaker has joined #bitcoin-core-dev
 73 2017-07-05T10:25:31  *** JackH has joined #bitcoin-core-dev
 74 2017-07-05T10:26:53  *** Aaronvan_ has quit IRC
 75 2017-07-05T10:28:05  *** AaronvanW has joined #bitcoin-core-dev
 76 2017-07-05T10:35:44  *** vicenteH has joined #bitcoin-core-dev
 77 2017-07-05T11:23:38  <bitcoin-git> [bitcoin] jnewbery opened pull request #10747: [rpc] fix verbose argument for getblock in bitcoin-cli (master...fix_getblock_verbose_argument) https://github.com/bitcoin/bitcoin/pull/10747
 78 2017-07-05T12:03:36  *** dabura667 has quit IRC
 79 2017-07-05T12:05:11  *** belcher_ has joined #bitcoin-core-dev
 80 2017-07-05T12:39:07  *** AaronvanW_ has joined #bitcoin-core-dev
 81 2017-07-05T12:45:59  *** talmai has joined #bitcoin-core-dev
 82 2017-07-05T13:07:24  *** Guyver2_ has joined #bitcoin-core-dev
 83 2017-07-05T13:09:48  *** Guyver2 has quit IRC
 84 2017-07-05T13:09:57  *** Guyver2_ is now known as Guyver2
 85 2017-07-05T13:16:40  *** Dyaheon has quit IRC
 86 2017-07-05T13:17:58  *** Dyaheon has joined #bitcoin-core-dev
 87 2017-07-05T13:24:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 88 2017-07-05T13:27:37  <bitcoin-git> [bitcoin] jnewbery opened pull request #10748: [config] Help text cleanup (master...helptextcleanup) https://github.com/bitcoin/bitcoin/pull/10748
 89 2017-07-05T13:34:43  *** Chris_Stewart_5 has quit IRC
 90 2017-07-05T13:43:22  *** BartokIT has joined #bitcoin-core-dev
 91 2017-07-05T13:47:22  *** Guyver2_ has joined #bitcoin-core-dev
 92 2017-07-05T13:49:53  *** BartokIT has quit IRC
 93 2017-07-05T13:50:38  *** Guyver2 has quit IRC
 94 2017-07-05T13:50:45  *** Guyver2_ is now known as Guyver2
 95 2017-07-05T14:07:37  *** Dejah has joined #bitcoin-core-dev
 96 2017-07-05T14:11:57  *** Dejah has quit IRC
 97 2017-07-05T14:15:56  *** talmai has quit IRC
 98 2017-07-05T14:15:59  *** Margarita2 has joined #bitcoin-core-dev
 99 2017-07-05T14:19:13  *** Aaronvan_ has joined #bitcoin-core-dev
100 2017-07-05T14:20:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
101 2017-07-05T14:22:25  *** AaronvanW has quit IRC
102 2017-07-05T14:23:20  *** echonaut has quit IRC
103 2017-07-05T14:23:37  *** echonaut has joined #bitcoin-core-dev
104 2017-07-05T14:26:13  *** Guyver2 has quit IRC
105 2017-07-05T14:27:08  *** Guyver2 has joined #bitcoin-core-dev
106 2017-07-05T14:30:35  *** JackH has quit IRC
107 2017-07-05T14:34:02  *** musalbas has quit IRC
108 2017-07-05T14:36:09  *** musalbas has joined #bitcoin-core-dev
109 2017-07-05T14:40:48  *** Chris_Stewart_5 has quit IRC
110 2017-07-05T14:52:10  <bitcoin-git> [bitcoin] practicalswift opened pull request #10749: Use compile-time constants instead of unnamed enumerations (remove "enum hack") (master...enum-hack) https://github.com/bitcoin/bitcoin/pull/10749
111 2017-07-05T14:56:59  *** riemann has quit IRC
112 2017-07-05T15:17:04  *** Guest86952 has quit IRC
113 2017-07-05T15:17:26  *** tripleslash has joined #bitcoin-core-dev
114 2017-07-05T15:22:05  *** Dyaheon has quit IRC
115 2017-07-05T15:22:41  *** Dyaheon has joined #bitcoin-core-dev
116 2017-07-05T15:31:59  <bitcoin-git> [bitcoin] instagibbs closed pull request #10333: [wallet] fee fixes: always create change, adjust value, and p… (master...fixfeefinal) https://github.com/bitcoin/bitcoin/pull/10333
117 2017-07-05T15:46:07  *** Yogaqueef has joined #bitcoin-core-dev
118 2017-07-05T15:46:16  *** Yogaqueef has quit IRC
119 2017-07-05T16:15:39  *** isis has left #bitcoin-core-dev
120 2017-07-05T16:36:38  *** Ylbam has joined #bitcoin-core-dev
121 2017-07-05T16:38:38  *** chjj has quit IRC
122 2017-07-05T16:46:23  *** tiagotrs has joined #bitcoin-core-dev
123 2017-07-05T16:51:34  *** RoyceX has quit IRC
124 2017-07-05T16:51:36  *** Cheeseo has joined #bitcoin-core-dev
125 2017-07-05T16:54:15  *** Aaronvan_ has quit IRC
126 2017-07-05T17:12:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
127 2017-07-05T17:26:28  *** Dyaheon has quit IRC
128 2017-07-05T17:28:16  *** Dyaheon has joined #bitcoin-core-dev
129 2017-07-05T17:31:04  *** ovovo has joined #bitcoin-core-dev
130 2017-07-05T17:33:45  *** vicenteH has quit IRC
131 2017-07-05T17:34:27  *** owowo has quit IRC
132 2017-07-05T17:34:55  *** timothy has quit IRC
133 2017-07-05T17:38:09  <earlz> Is there a know minimum gcc version for compiling Bitcoin Core?
134 2017-07-05T17:42:59  *** Murch has joined #bitcoin-core-dev
135 2017-07-05T17:43:11  *** chjj has joined #bitcoin-core-dev
136 2017-07-05T17:46:21  *** Giszmo has quit IRC
137 2017-07-05T17:51:21  <sipa> 4.8
138 2017-07-05T17:55:57  *** RubenSomsen has joined #bitcoin-core-dev
139 2017-07-05T18:04:51  *** talmai has joined #bitcoin-core-dev
140 2017-07-05T18:11:51  *** Margarita2 has quit IRC
141 2017-07-05T18:14:34  *** Lilly2 has joined #bitcoin-core-dev
142 2017-07-05T18:27:50  *** Guyver2_ has joined #bitcoin-core-dev
143 2017-07-05T18:29:52  *** riemann has joined #bitcoin-core-dev
144 2017-07-05T18:31:13  *** Guyver2 has quit IRC
145 2017-07-05T18:31:13  *** Guyver2_ is now known as Guyver2
146 2017-07-05T18:38:08  *** SopaXorzTaker has quit IRC
147 2017-07-05T18:39:23  *** Murch has quit IRC
148 2017-07-05T18:43:05  <bitcoin-git> [bitcoin] instagibbs opened pull request #10750: [wallet] Change bumpfee totalFee option to feeRate option (master...bumpfeerate) https://github.com/bitcoin/bitcoin/pull/10750
149 2017-07-05T18:43:13  *** Chris_Stewart_5 has quit IRC
150 2017-07-05T18:54:00  *** tmddzk has joined #bitcoin-core-dev
151 2017-07-05T18:55:23  *** ovovo is now known as owowo
152 2017-07-05T18:57:50  *** ajd__ has quit IRC
153 2017-07-05T19:02:59  *** Yogaqueef has joined #bitcoin-core-dev
154 2017-07-05T19:08:43  *** schmidty has joined #bitcoin-core-dev
155 2017-07-05T19:11:29  <morcos> instagibbs: Just wanted to jot down some of the thoughts on future improvements to bumpfee
156 2017-07-05T19:11:54  <morcos> So right now bumpfee doesn't let you bump a tx which has any of its outputs spent by other mempool txs (i.e. has any descendants)
157 2017-07-05T19:12:02  <morcos> I think there are several reasons for this
158 2017-07-05T19:12:39  <morcos> One you might unintentionally pay way more in fee than you were expecting b/c you're paying for a lot of descendants
159 2017-07-05T19:12:52  <instagibbs> yes, rhavar brought this up on the mailing list recently
160 2017-07-05T19:13:07  <instagibbs> someone does a mega-sweep on top, even low fee, and you can pay lots
161 2017-07-05T19:13:15  <morcos> Two is the tricky issue of you aren't sure which transaction is actually going to get confirmed, the original or the replacement
162 2017-07-05T19:14:30  <morcos> So if your replacement isn't doing something pretty smart, you may now end up in a confused state as to whether your descendant payees should be repaid and making sure they are repaid using conflicting in puts so you don't end up double paying them
163 2017-07-05T19:15:00  <morcos> We should probably write up a plan for the next step in improving bumpfee functionality
164 2017-07-05T19:15:24  *** talmai has quit IRC
165 2017-07-05T19:15:56  <morcos> I think the ability to bump a chain of txs where all the descendant txs are also yours ought to be feasible as a next step
166 2017-07-05T19:17:06  <morcos> Bumping a tx which someone else has spent seems riskier..  Perhaps if there are no new inputs added in the original chain and you have enough original change, then you could pay all their payees for them?
167 2017-07-05T19:17:14  <instagibbs> Are you saying the local logic cares that downstream someone double-counted payments?
168 2017-07-05T19:18:39  <morcos> Not exactly.. But I'm saying we don't want to design our wallet software such that in an ecosystem of people using it, they end up actually double paying other people b/c they aren't properly conflicting inputs on double spends
169 2017-07-05T19:19:06  <morcos> I think this also touches on why it's tricky to add new inputs on just the simple case of bumping your own tx
170 2017-07-05T19:19:14  <sipa> morcos, instagibbs: i wonder if an alternative to deal with rhavar's problem is to keep a counter in every tx "bytes_replaced", which accumulates any time a replacement happens through acceptance of a tx (both for rbf or eviction reasons)... and then you're required to pay that number times the relay margibal feerate
171 2017-07-05T19:19:25  <instagibbs> I'm not grokking tbh, I might need specific examples of what's wrong here
172 2017-07-05T19:19:51  <sipa> the requirement of strictly larger fee on replacement is not actually necessary to make the economics work out
173 2017-07-05T19:20:34  <morcos> sipa: hmmmm....  i'm not sure that's completely correct
174 2017-07-05T19:21:12  <sipa> the requirement is that 1) mining the new tx is economically better for miners and 2) the new tx pays for the relay of all previous txn it caused to be evicted
175 2017-07-05T19:21:20  <morcos> it seems to me there is a relationship between the min relay rate and the min rate which is accepted in a block, which is dictated by the size of the mempool and the decay of the mempool min fee
176 2017-07-05T19:21:45  <morcos> it is a slightly broken relationship to be sure
177 2017-07-05T19:22:37  <morcos> but i dont' think we have enough confidence that the min relay fee alone is sufficient to prevent spam that we should sort of allow "downgrading" the fees paid as long as your are still over the cumulative bytes times min relay
178 2017-07-05T19:22:42  <instagibbs> morcos, can you give me an example of problematic behavior which doesnt just boil down to "don't do unconfirmed chaining on top of bip125 transaction"?
179 2017-07-05T19:22:59  <instagibbs>  s/behavior/example
180 2017-07-05T19:23:18  *** abpa has joined #bitcoin-core-dev
181 2017-07-05T19:23:26  <morcos> sipa: certainly it's also not clear that would be in the best interest of miners
182 2017-07-05T19:24:55  <morcos> instagibbs: let me think for a min
183 2017-07-05T19:25:46  <sipa> morcos: i what way wouldn't it?
184 2017-07-05T19:28:46  <morcos> sipa: hmm..  i suppose only if blocks aren't full  (hopeful smiley face)
185 2017-07-05T19:29:20  <morcos> but no, not even exactly that
186 2017-07-05T19:29:42  <morcos> if the feerates in question are all above average, then miners have lost right?
187 2017-07-05T19:30:38  <morcos> you could replace 10200 bytes of something paying 100 sat/B with 200 bytes of something paying 201 sat/B in your example right?
188 2017-07-05T19:31:10  <morcos> if the feerate at the bottom of a block ever drops below 100 sat/B then miners lost out didn't they?
189 2017-07-05T19:32:27  *** Dyaheon has quit IRC
190 2017-07-05T19:32:40  *** rhavar has joined #bitcoin-core-dev
191 2017-07-05T19:32:59  <morcos> instagibbs: ok back to your questions.  i think i said two things, the second was that your previous idea of adding inputs to bumpfee might have issues
192 2017-07-05T19:33:09  <morcos> i think i agree that it should not have issues
193 2017-07-05T19:33:17  <instagibbs> it'se self-invalidating
194 2017-07-05T19:33:30  <morcos> although i think we'll need to carefully examine the code for handling conflicts and make sure we're not making any edge cases worse
195 2017-07-05T19:33:37  <morcos> but i agree we should be able to make it work
196 2017-07-05T19:33:44  <instagibbs> i think for descendants in mempool, the two easiest cases to think about: 1) all yours 2) none of yours
197 2017-07-05T19:34:23  *** Dyaheon has joined #bitcoin-core-dev
198 2017-07-05T19:34:25  <morcos> yes, so i think we can handle 1.
199 2017-07-05T19:34:43  <sipa> morcos: right, ok, i'm assuming a more rational market than currently exists, i guess
200 2017-07-05T19:34:57  <morcos> i think we can handle any cases that aren't 1 (including mix of yours and not yours) as long as no inputs that aren't yours are added
201 2017-07-05T19:35:51  <morcos> volatile != irrational does it?
202 2017-07-05T19:36:26  <morcos> instagibbs: but i agree we should separate those into two separate cases...  and handling all yours first seems easier
203 2017-07-05T19:37:01  <sipa> morcos: i'm assuming near infinite demand at various fee rate levels
204 2017-07-05T19:37:14  <sipa> reality is much more complicated, i agree
205 2017-07-05T19:37:22  <rhavar> There's minor privacy implications of doing that automatically, you clearly identify which descendants are yours
206 2017-07-05T19:37:26  <morcos> instagibbs: see this https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557 for background
207 2017-07-05T19:38:00  <morcos> rhavar: you mean of only having the ability to do it when all are yours?
208 2017-07-05T19:38:40  <rhavar> yeah
209 2017-07-05T19:39:27  *** Murch has joined #bitcoin-core-dev
210 2017-07-05T19:39:42  <rhavar> (although I'm just jumping in this conversation a bit late, as I got some pings on slack i was being mentioned). But you're talking about automatically resigning and resending invalidated descendants?
211 2017-07-05T19:39:47  <morcos> yeah, i mean we could do both steps, but you will still be able to differentiate b/c if any of the descendant txs added inputs, those will be identified as being your descendant txs
212 2017-07-05T19:39:58  <instagibbs> rhavar, no just simple bump case
213 2017-07-05T19:40:25  <rhavar> oh, never mind then
214 2017-07-05T19:40:30  <morcos> rhavar: well just replacing the whole chain with a single tx that pays all the necessary payees and conflicts all the txs which pull in new in-chain inputs
215 2017-07-05T19:40:48  <rhavar> That's not often a sane thing to do, as the fee rates will differ
216 2017-07-05T19:41:41  <morcos> instagibbs: i suppose if you look at it the way i just stated it, then it doesn't matter to break it in two cases... you just wont be able to do it if any of the non-you descendnats add inputs (assuming no mixed txs)
217 2017-07-05T19:42:12  <morcos> and now we have to start looking at stuff in a per wallet world
218 2017-07-05T19:42:18  <morcos> from you has to mean from this wallet
219 2017-07-05T19:43:03  <morcos> which raises an interesting point...  if you have wallets which overlap with other wallets, then you can run into problems conflicting only part of a tx
220 2017-07-05T19:43:14  <morcos> did people envision overlapping wallets?
221 2017-07-05T19:43:26  <BlueMatt> lol, morcos writes out "smiley face"
222 2017-07-05T19:43:36  *** CubicEarth has joined #bitcoin-core-dev
223 2017-07-05T19:43:58  <instagibbs> can you rephrase "just wont be able to do it if any of the non-you descendnats add inputs (assuming no mixed txs)" (so sorry, lots of terminology)
224 2017-07-05T19:44:31  <morcos> instagibbs: mixed tx = tx which spends some of your inputs and some of someone elses  (can't remember exactly what we call those)
225 2017-07-05T19:44:46  <instagibbs> ok that cannot be replaced because we don't know fees?
226 2017-07-05T19:44:59  *** chjj has quit IRC
227 2017-07-05T19:45:39  <morcos> instagibbs: that's not what i meant, but maybe i'm looking at it backwards
228 2017-07-05T19:45:53  <morcos> yeah i was looking at it backwards
229 2017-07-05T19:46:18  <morcos> what i was trying to avoid is making it so you accidentally have two pays to the same payee get confirmed that spend different inputs
230 2017-07-05T19:46:22  <instagibbs> that's a check feebumper does, fwiw :P
231 2017-07-05T19:46:40  <morcos> we do that in our own wallet by making sure we conflict at least one of the inputs between the two txs
232 2017-07-05T19:47:20  <morcos> so now i'm back to your original division and thinking we should distinguish between a chain of only our txs and a chain which includes someone elses child spends
233 2017-07-05T19:47:56  <morcos> it's just going to be a bit unexpected if they see their child spend evicted and they won't know their payee has been paid (if thats what we do by bumping the package)
234 2017-07-05T19:48:11  <rhavar> Is it really even worth while to support chains? :P
235 2017-07-05T19:48:19  <morcos> so lets just forget about that (at least for now) and only bump chains of ourself
236 2017-07-05T19:48:48  <morcos> support bumping them or support them?  unfortunately supporting them is a long lost cause, but i do think that is still valuable
237 2017-07-05T19:49:02  <morcos> supporting bumpng them makes a lot of sense b/c you can save money by consolidating
238 2017-07-05T19:49:33  <rhavar> support bumping them. There's a lot of edge cases, like the descendant having a lower fee rate
239 2017-07-05T19:49:41  <rhavar> which you might not want to consolidate
240 2017-07-05T19:50:20  * BlueMatt still votes for "you cant bump if there are not-yours descendants, without a force flag, which is mostly-unsupported"
241 2017-07-05T19:50:29  <BlueMatt> and if there are "your" descendants, we should probably only support bumping at the bottom of the chain
242 2017-07-05T19:50:56  <BlueMatt> should also probably support explicit cpfp, which handles some other cases, too
243 2017-07-05T19:51:20  <morcos> BlueMatt: the advantage of not bumping at the bottom is you can consolidate
244 2017-07-05T19:51:30  <morcos> you can always choose to bump at the bottom
245 2017-07-05T19:51:37  <BlueMatt> well ok, but that seems like a rather separate thing, no?
246 2017-07-05T19:51:51  <BlueMatt> auto-merging transactions sounds like very surprising behavior for "bumpfee"
247 2017-07-05T19:52:05  <morcos> but yeah having a smart algo that determines whether CPFP or bump or CPFP by bumping the bottom is the best choice would be nice
248 2017-07-05T19:52:06  <sipa> i wonder if we should just have a set of outputs that require being paid, and just have RPCs that change that set, where every change just results in a new RBF doing the whole thing
249 2017-07-05T19:52:38  <sipa> and stop seeing unconfirmed transactions as transactions
250 2017-07-05T19:52:40  <BlueMatt> that sounds like reasonable behavior...for users who only need limited privacy
251 2017-07-05T19:52:54  <BlueMatt> but it sounds like a separate set of RPCs?
252 2017-07-05T19:53:10  <morcos> i think that at the Bitcoin Core level it's always going to be a highly advanced application, and its better not to abstract away too much about how it actually works
253 2017-07-05T19:53:28  <morcos> Let higher level software build on top of it that type of functionality
254 2017-07-05T19:53:31  <sipa> BlueMatt: yeah, it'd need to be separate... and not compatible with any receiver that wants a txid ahead of time etc
255 2017-07-05T19:53:48  <sipa> what do you mean with limited privacy?
256 2017-07-05T19:53:52  <morcos> Of course if the wallet software was separate, we could just have both
257 2017-07-05T19:54:13  <sipa> morcos: right, perhaps this is more something for a new wallet rather than an add-on to the existing one
258 2017-07-05T19:54:22  <BlueMatt> sipa: well my biggest concern with auto-merging in bumpfee is that you have people who manually selected inputs or created raw txn and all of a sudden those txn change structure massively
259 2017-07-05T19:54:24  <sipa> it just seems so much easier to reason about
260 2017-07-05T19:54:32  <BlueMatt> potentially merging outputs that they wanted to keep "separate"
261 2017-07-05T19:54:52  <sipa> well this wouldn't support self-selecting inputs...
262 2017-07-05T19:55:02  <BlueMatt> it doesnt, but Core does
263 2017-07-05T19:55:11  <rhavar> If merging was desired, wouldn't it be better to have done that in the first place when sending the 2nd transaction?
264 2017-07-05T19:55:15  <BlueMatt> in the future maybe want to push people to multiwallet, but thats far away
265 2017-07-05T19:55:55  <sipa> yeah, my suggestion isn't really on topic in this discussion
266 2017-07-05T19:56:01  <morcos> BlueMatt: I think bumpfee could take a list of txs to merge, and then could by default merge descendants of those txs, but take an option to not include descendants.  In all cases, all txs must be from you.  That ought to be pretty intuitive and cover all possibilites.
267 2017-07-05T19:56:12  <sipa> but all the reasoning about CPFP and bumping and chains of transactions makes my head hurt
268 2017-07-05T19:56:28  <sipa> and i think there is a possible way of how things could have worked if not for legacy, that is much easier
269 2017-07-05T19:56:40  <BlueMatt> morcos: maybe we should rename it "dothings" if it grows to do all kinds of magic :p
270 2017-07-05T19:56:50  <morcos> if blocks were bigger and came every 10 secs instead of every 10 mins, we wouldn't really have these problems
271 2017-07-05T19:56:58  *** chjj has joined #bitcoin-core-dev
272 2017-07-05T19:57:05  <BlueMatt> lol
273 2017-07-05T19:57:11  <rhavar> I'm actually a huge fan of bumpfee taking a *list* of transactions to fee bump   (and consolidate them)   .. but i think all the descendant stuff is way too insanely annoying
274 2017-07-05T19:57:13  <BlueMatt> bitcoin also wouldnt function, but thats a separate issue
275 2017-07-05T19:57:17  <instagibbs> getting back to my original thing: absolute fee argument is brittle if we want to do anything dynamic with our replacements
276 2017-07-05T19:57:37  <morcos> instagibbs: dynamic?
277 2017-07-05T19:57:39  <instagibbs> maybe it can just get the fee wanted, but perhaps grab too many inputs in order to pay
278 2017-07-05T19:57:43  <instagibbs> adding inputs for example
279 2017-07-05T19:57:49  <rhavar> because if you're a high volume sender, you probably don't have a single transaction to bump ... but have a list of them
280 2017-07-05T19:58:02  <instagibbs> I was really hoping to avoid doing insane loops guessing how many outputs to select
281 2017-07-05T19:58:04  <BlueMatt> hmm, well maybe I take that back, maybe a list of txids is ok and not too huge
282 2017-07-05T19:58:20  <morcos> instagibbs: ah, i see
283 2017-07-05T19:58:24  <rhavar> the main difficulty i guess is that you'll have now multiple change addresses
284 2017-07-05T19:58:31  <rhavar> but that should be easy to prune
285 2017-07-05T19:58:54  <morcos> instagibbs: i would recommend just adding a new option which is payTxFeeRate
286 2017-07-05T19:58:59  *** vicenteH has joined #bitcoin-core-dev
287 2017-07-05T19:59:15  <morcos> I think if you wait until my PR's that use coin control get merged, it'll be trivial to add that to bumpfee
288 2017-07-05T19:59:24  <instagibbs> and disable anything nice when using totalFee? :P
289 2017-07-05T19:59:38  <morcos> No
290 2017-07-05T19:59:58  <morcos> Hmm
291 2017-07-05T20:00:04  <instagibbs> or just be ok grabbing too many inputs
292 2017-07-05T20:00:10  * BlueMatt -> airport
293 2017-07-05T20:00:11  <instagibbs> and shove the excess fee into a change output?
294 2017-07-05T20:00:28  <instagibbs> (thinking along lines of using effective value)
295 2017-07-05T20:00:34  <morcos> In what cases do we grab extra inputs?
296 2017-07-05T20:00:48  <morcos> Only when we have no change or it's not big enough?
297 2017-07-05T20:00:53  <morcos> s/do/will/
298 2017-07-05T20:01:08  <instagibbs> no change or not enough yeah
299 2017-07-05T20:01:23  <instagibbs> otherwise no reason to
300 2017-07-05T20:01:33  <BlueMatt> morcos: in any case, I kinda like the "multiple txn to bump and auto-merge" option now that I think of it...but still think we should just go with only supporting bottom chunks of chains by default, cause thats almost always what you want to do anyways (ie cpfp, effectively)
301 2017-07-05T20:01:59  <rhavar> and i don't think it has any fragile and annoying logic
302 2017-07-05T20:02:26  <morcos> BlueMatt: For starters you can do that by bumping the bottom tx yourself...   I think if you have a chain, you'll probably save more by consolidating
303 2017-07-05T20:02:33  *** str4d has joined #bitcoin-core-dev
304 2017-07-05T20:03:12  <morcos> instagibbs: Yeah I think that gets tricky.  It's actually going to get a bit tricky even without thinking about totalFee, I think.
305 2017-07-05T20:03:40  <BlueMatt> morcos: yes, agreed, but you can only support consoladating at the bottom of the chain
306 2017-07-05T20:04:02  <BlueMatt> if you want to consolodate mid-chain, things might break, and thats less of our issue
307 2017-07-05T20:04:10  <morcos> Why don't you just get it to work right only in the event that it is using automatic fee calculation or a txconfirmtarget was passed in
308 2017-07-05T20:04:31  <morcos> Supporting it in the totalFee case (if possible) can be later.
309 2017-07-05T20:04:45  <morcos> Adding a payTxFeeRate is orthogonal and as simple as above.
310 2017-07-05T20:05:46  <instagibbs> morcos, if we don't have that constraint, should be a fairly simple effective value selection, no?
311 2017-07-05T20:05:46  <instagibbs> well, we have to decide how much we want to grab, just has to be enough to pay for fee delta... if you get exact match no change, otherwise make change.
312 2017-07-05T20:06:14  <instagibbs> Fair enough, was just hoping it was a useless arg to have less code
313 2017-07-05T20:06:18  <morcos> instagibbs: don't have what constraint?  that it has to work with totalFee?
314 2017-07-05T20:07:26  <instagibbs> Yeah. Previously it's dead-easy because you just adjust the change.
315 2017-07-05T20:12:02  <rhavar> or if you don't mind rabbit-holes, the "create transaction" stuff could be extended with an array of set of transaction inputs in which at least 1 must be picked
316 2017-07-05T20:12:12  <rhavar> and then all that logic can be reused
317 2017-07-05T20:13:41  <rhavar> the part that gets messy is that you need to make sure your new transaction not only conflicts with the transaction you're fee bumping -- but all previous fee bumps too
318 2017-07-05T20:14:21  <rhavar> so you can avoid that by only adding new inputs  (at the cost of worse coin selection)
319 2017-07-05T20:14:59  <instagibbs> oh please, not that rabbit hole
320 2017-07-05T20:15:22  *** Murch has quit IRC
321 2017-07-05T20:15:29  <sipa> instagibbs: BnB isn't hard to give a constraint "only accept combinations which include at least one input of each of these previous transactions
322 2017-07-05T20:15:47  <instagibbs> right nothing in principle is wrong, just the versioning thing
323 2017-07-05T20:16:04  <instagibbs> it's obviously correct, just hard
324 2017-07-05T20:16:21  <morcos> instagibbs: yeah to that point, i'd argue we should concentrate on the BnB and effective value logic first
325 2017-07-05T20:16:36  <instagibbs> our functionary stack uses a version of that logic to not doublespend
326 2017-07-05T20:16:46  <morcos> adding inputs to bumpfee sounds nice but very non-critical and might as well only do it once on top of the new coin selection logic
327 2017-07-05T20:16:59  <instagibbs> morcos, agreed, I was building a speculative PR on top of achow's
328 2017-07-05T20:18:54  <instagibbs> I'm supporting BnB as trojan horse to get effective value in (kidding, sorta)
329 2017-07-05T20:20:39  <bitcoin-git> [bitcoin] instagibbs closed pull request #10750: [wallet] Change bumpfee totalFee option to feeRate option (master...bumpfeerate) https://github.com/bitcoin/bitcoin/pull/10750
330 2017-07-05T20:23:42  <gmaxwell> instagibbs: you keep complaining about EV but it doesn't seem like anyone is working to fix the bloat concern!
331 2017-07-05T20:24:04  <instagibbs> gmaxwell, hopefully it doesn't cause bloat for bumpfee!
332 2017-07-05T20:24:09  <instagibbs> :)
333 2017-07-05T20:25:38  <instagibbs> not trying to be flippant, you can just take negative EV outputs anyways
334 2017-07-05T20:25:56  *** Murch has joined #bitcoin-core-dev
335 2017-07-05T20:26:33  <gmaxwell> it's not clear to me that being willing to take negative ev outputs is sufficient to be as de-bloating as the current stuff, maybe it is.
336 2017-07-05T20:27:10  <gmaxwell> rhavar: the easiest thing to do is always conflict all the earlier inputs, then you don't have to worry about failing to conflict an earlier bump.  It's also better for privacy.
337 2017-07-05T20:28:00  <gmaxwell> BlueMatt: we can't really do the multiple txn bump and auto-merge without segwit, I think.  Handling malleability is too gnarly.
338 2017-07-05T20:29:30  <rhavar> it's not clearly better for privacy, if the new coin selection result avoided creating change (and thus the means to cluster your wallet further)
339 2017-07-05T20:30:38  <rhavar> hmm never mind, i'm stupid
340 2017-07-05T20:30:51  *** AaronvanW has joined #bitcoin-core-dev
341 2017-07-05T20:32:36  *** riemann has quit IRC
342 2017-07-05T20:33:31  <instagibbs> gmaxwell, would simulations suffice? What kind of data are people looking for?
343 2017-07-05T20:34:07  *** Murch has quit IRC
344 2017-07-05T20:34:41  *** RubenSomsen has quit IRC
345 2017-07-05T20:36:49  *** AaronvanW has quit IRC
346 2017-07-05T20:40:02  *** Murch has joined #bitcoin-core-dev
347 2017-07-05T20:49:57  *** talmai has joined #bitcoin-core-dev
348 2017-07-05T20:51:33  <gmaxwell> instagibbs: simulations would sufficice in my view.  Basically just a clear argument that the new procedure won't tend to select fewer inputs than the old one.
349 2017-07-05T21:02:46  <morcos> gmaxwell: I'm all for putting together a simulation. But at the end of the day, I think we're going to have to wing it a bit.  It's almost by definition going to put together fewer inputs.
350 2017-07-05T21:02:56  <morcos> We're doing stupid things now by spending uneconomical inputs
351 2017-07-05T21:03:16  <morcos> To fix that and prevent utxo bloat getting worse takes a more involved solution I think
352 2017-07-05T21:03:32  <morcos> Being smarter about what size outputs we create is one starting point
353 2017-07-05T21:03:48  <morcos> But the key is also being willing to purposefully pick multiple small outputs to consolidate sometimes
354 2017-07-05T21:04:02  <morcos> The tricky thing is when to do that
355 2017-07-05T21:04:05  *** str4d has quit IRC
356 2017-07-05T21:04:42  <morcos> But I think if we start on this right after 0.15, we ought to be able to get it all done.  BnB, effective value, better output creation and smart consolodiation
357 2017-07-05T21:05:18  <morcos> Whether we'll be 100% convinced its at least as good as before, I don't think thats going to be easy...  But as long as it's not a COMPLETE disaster, we can refine it over a couple of releases.
358 2017-07-05T21:05:35  <morcos> Simulations are just so hard when we don't have a good sense of what the user population looks like.
359 2017-07-05T21:06:01  <instagibbs> morcos, you can at least compare apples to apples, which might be useful
360 2017-07-05T21:06:19  <morcos> Depends on what an apple is I guess
361 2017-07-05T21:06:38  <morcos> but like i said, i'm all for tryingsimulations out
362 2017-07-05T21:06:48  *** abpa has quit IRC
363 2017-07-05T21:11:09  *** timothy has joined #bitcoin-core-dev
364 2017-07-05T21:14:52  *** Murch has quit IRC
365 2017-07-05T21:17:38  <gmaxwell> morcos: I don't think that is acceptable-- you don't even know what the magitude of the change is. And yes, but definition it will use fewer inputs: thats the problem.  It's not like we haven't made this kind of mistake before, and it had a tremendously negative and lasting effect.
366 2017-07-05T21:18:00  <morcos> gmaxwell: what do you propose as an alternative?
367 2017-07-05T21:18:53  <morcos> my argument is that TX A which consolidates the UTXO more but contains an input with negative effective value is not clearly superior to TX B which is identical but does not contain the negative effective value input
368 2017-07-05T21:19:07  <gmaxwell> There isn't an alernative. We need to simulate and make compensating changes and adjust things until we have good reason to believe there won't be a seriously bad effect.
369 2017-07-05T21:19:40  <morcos> Simulate how?
370 2017-07-05T21:19:54  <gmaxwell> I disagree, especially considering that we will make UTXO which immediately have negative effective value, that sequence alone basically guarentees runaway utxo growth (I just don't know the runaway constant)
371 2017-07-05T21:20:24  <morcos> gmaxwell: well the "especially .." is the part i think we need to address first
372 2017-07-05T21:21:42  <morcos> the problems i have with simulation is they tend to simulate over a single large wallet making and receiving a series of txs
373 2017-07-05T21:22:17  <morcos> I don't know if there is any reason to believe that this has the same net utxo affect as an ecosystem of wallets (many probably much smaller) all making/receiving txs to each other
374 2017-07-05T21:22:45  <gmaxwell> If it were addressed first I would worry somewhat less.  Similarly, if we had some mechenism to sweep up utxo even when they have low or slightly negative EV then there would be less cause for concern.  We know that pruning unnecessary inputs caused phenominal UTXO set inflation, avoiding low EV inputs seems to me like it would do the same.
375 2017-07-05T21:22:50  <morcos> without understanding some structure of how tx flows look, we're at risk of producing useless results
376 2017-07-05T21:23:05  <gmaxwell> morcos: well murch's simulation had traces of real payment in, payment out amounts.
377 2017-07-05T21:23:07  <bitcoin-git> [bitcoin] practicalswift opened pull request #10752: Use quoted form when including primitives/transaction.h (master...transaction-h) https://github.com/bitcoin/bitcoin/pull/10752
378 2017-07-05T21:23:15  *** talmai has quit IRC
379 2017-07-05T21:23:34  <morcos> did you read my whole spiel..  i thought we should do those other things as well
380 2017-07-05T21:23:34  <gmaxwell> morcos: I think it is still a big step forward to say that in at least one realistic situation the changes don't produce UTXO runaway.
381 2017-07-05T21:24:02  <morcos> but it's actually easier to build those other things properly on top of an effective value framework
382 2017-07-05T21:24:42  <rhavar> Has anyone suggested raising the "is dust" check to something more sane?
383 2017-07-05T21:24:48  <gmaxwell> I'm not saying they should be done, I'm saying that they must be done. And that we must have at least _some_ measurement that suggests that it won't go nuts. It doesn't have to be perfect.
384 2017-07-05T21:24:50  <instagibbs> rhavar, yep
385 2017-07-05T21:24:55  <rhavar> the current dust threshold is ludicrously low
386 2017-07-05T21:25:10  <instagibbs> rhavar, the BnB branch does just that, to minimize review surface, but generally raising it is a goal too
387 2017-07-05T21:25:18  *** talmai has joined #bitcoin-core-dev
388 2017-07-05T21:25:21  <sipa> rhavar: using effectively output value effectively does that
389 2017-07-05T21:25:25  <gmaxwell> I think rhavar is talking about something different instagibbs, sipa.
390 2017-07-05T21:25:29  <morcos> rhavar: yeah, changing dust levels is a bit annoying, but changing the levels at which we'll create dust is a no-brainer!
391 2017-07-05T21:25:31  <rhavar> i'm talking about is standard
392 2017-07-05T21:25:34  <gmaxwell> rhavar is talking about what the network allows people to do.
393 2017-07-05T21:25:37  <sipa> oh
394 2017-07-05T21:25:39  <instagibbs> oh, then no
395 2017-07-05T21:25:40  <rhavar> not the coin selection itself
396 2017-07-05T21:25:55  <gmaxwell> rhavar: I think we should get rid of it, unfortunately it's ineffective since some large miners bypass it.
397 2017-07-05T21:26:22  <sipa> no sane coin selection strategy should produce anything near the current dust threshold
398 2017-07-05T21:26:29  <rhavar> some miners do bypass it, but it's still quite effective as a network policy
399 2017-07-05T21:26:32  <morcos> gmaxwell: i agree to the extent that we shouldn't raise it, but getting rid of it seems risky.  it's at least somewhat of an impediment to other implementations creating stupidly small utxos
400 2017-07-05T21:26:46  <sipa> but there are quite a few not-so-sane coin selection algorithms out there...
401 2017-07-05T21:26:48  <rhavar> it stops a lot of fee attacks
402 2017-07-05T21:26:53  <gmaxwell> morcos: perhaps.
403 2017-07-05T21:27:11  <rhavar> I saw a service that recently (3 month ago?) got spammed with 3000 sat (?) outputs  and ended up needing to spend over a bitcoin to clean it up
404 2017-07-05T21:27:12  <gmaxwell> rhavar: I don't think it does, you can reliably get txn mined that violate it.
405 2017-07-05T21:27:29  <rhavar> if they could've spammed with 1 sat outputs, it would've been a lot more effective
406 2017-07-05T21:27:43  <rhavar> and at a certain point people wouldn't even bother trying to clean it up
407 2017-07-05T21:27:47  <rhavar> which leads to permanent bloat
408 2017-07-05T21:28:17  <rhavar> Unless you imagine a future where spending dust has  <=  0 weight :P
409 2017-07-05T21:28:17  <gmaxwell> Really the weighting in segwit is intended to be a better way of dealing with this stuff-- make the fees on creating those outputs that never get spent higher.
410 2017-07-05T21:28:41  <gmaxwell> Constant amounts of bloat don't concern me, bloat blowup does. :)
411 2017-07-05T21:29:44  <gmaxwell> I think on the order of 30% of hashpower doesn't enforce it, so I think really the only effect it has is that ignorant/lazy wallet authors get forced by relay policy to avoid creating dust, where otherwise they might not care.
412 2017-07-05T21:30:18  <rhavar> it's also reasonably effective at stopping spammers (who are trying to attack a specific wallet, not the network itself)
413 2017-07-05T21:30:22  *** Guyver2 has quit IRC
414 2017-07-05T21:30:26  <rhavar> they send to 1 peer who rejects it, so they use a higher amount
415 2017-07-05T21:30:34  <gmaxwell> rhavar: why? are they just too stupid to give their txn directly to antpool?
416 2017-07-05T21:30:41  <rhavar> probably
417 2017-07-05T21:30:45  <gmaxwell> (or whomever else is bypassing at the moment)
418 2017-07-05T21:31:01  <gmaxwell> fair but kind of a fragile justification.
419 2017-07-05T21:31:23  <rhavar> not sure how they even construct the spam, tbh. it's possible they just use a wallet (like core?) that rejects it immediately
420 2017-07-05T21:31:35  <rhavar> they probably aren't aware of that some miners don't enforce
421 2017-07-05T21:31:42  *** goatpig has quit IRC
422 2017-07-05T21:32:51  <rhavar> it's a pretty big attack vector though, i'm not sure a sane way to deal with it
423 2017-07-05T21:33:14  <rhavar> having wallets not spend uneconomical outputs might reduce the amounts of attacks though (as they know they can't harm someone by doing it)
424 2017-07-05T21:33:49  <rhavar> if i know you're using a wallet that spends the uneconomical dust, i'm a lot more likely to create it in the first place
425 2017-07-05T21:33:52  <gmaxwell> rhavar: segwit substantially deals with it, because it moves fees from spending outputs to creating them.  (not as much as I'd like, but there are constraints on how far you can go with that)
426 2017-07-05T21:34:10  <rhavar> yeah i'm aware =)
427 2017-07-05T21:34:17  <instagibbs> he wants infinite discount :P
428 2017-07-05T21:34:23  <gmaxwell> And having wallets be sensible about not spending insanely uneconomical dust would be good.
429 2017-07-05T21:34:53  <rhavar> instagibbs: nah, i want a constant negative weight for each byte you remove from the utxo    :P
430 2017-07-05T21:35:02  <gmaxwell> Yea, infinite discount has problems, alas... byte bloat goes up hyperbolically with the discount.   Signature costs are much less of a concern than utxo but only finitely so. :)
431 2017-07-05T21:35:15  <gmaxwell> negative weight is even more problematic than infinite discount.
432 2017-07-05T21:35:17  <gmaxwell> :(
433 2017-07-05T21:35:24  <sipa> just surcharge for outputs
434 2017-07-05T21:35:35  <rhavar> unless you join the dark size and embrace almost unbounded size blocks 8)
435 2017-07-05T21:35:51  <rhavar> (they'd still be bounded to the size of the utxo or something lolz)
436 2017-07-05T21:35:55  <gmaxwell> because then you can pad up outputs then produce a yottabyte block. which then in practice you end up with multiple constraints and intractable fee estimation.
437 2017-07-05T21:37:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
438 2017-07-05T21:37:49  *** Murch has joined #bitcoin-core-dev
439 2017-07-05T21:38:27  <rhavar> I wonder how harmful it really would be if someone mined a 1GB block that also removed 1GB from the utxo :P
440 2017-07-05T21:39:07  <sipa> short-term, terrible
441 2017-07-05T21:39:10  <sipa> long-term, great
442 2017-07-05T21:39:27  <rhavar> as it'd kind of be a "one off" style block, as it's obviously not sustainable
443 2017-07-05T21:40:10  <sipa> if we as a community feel that such a UTXO reduction is necessary, the proper way would be aim for a softfork that does that, not with a massive block
444 2017-07-05T21:40:34  <morcos> the biggest problem with too big a discount is that fees are still sometimes effectively nil, so you can preload the utxo now for "freeish"
445 2017-07-05T21:40:38  <rhavar> I just meant that if you came up with a weighting scheme that made it possible
446 2017-07-05T21:40:45  <sipa> rhavar: ah, i see
447 2017-07-05T21:40:51  <gmaxwell> rhavar: the problem is that the block would get orphaned because it would take forever to propagate. It would blow up all fast propagation methods (or to avoid blowing them up we'd have to uncap relay of txn, which would make the network DOS vulnerable).
448 2017-07-05T21:41:21  <rhavar> fair point
449 2017-07-05T21:41:40  <morcos> but i'm with gmaxwell, segwit didn't go quite far enough, and if we ever do have a HF, we should definitely go a bit further.
450 2017-07-05T21:41:43  <gmaxwell> rhavar: so in practice miners would impose a second limit, which would often be the operable limit, and now efficient fee computation becomes intractable, because you don't know what limit you're competing for when you make the transaction. ... plus all the above just degrades network stability.
451 2017-07-05T21:42:14  <gmaxwell> yea, with a HF we could go a bit further than segwit. E.g. counting the txin:vout data like witness data.
452 2017-07-05T21:42:51  <gmaxwell> I still don't think a factor much beyond 4 is well advised, but there are some other accounting changes that would be reasonable along these lines.
453 2017-07-05T21:43:01  <morcos> BlueMatt has a pAtent on that though, even more problematic than segwit pAtents
454 2017-07-05T21:43:15  <gmaxwell> lol
455 2017-07-05T21:43:33  <rhavar> I can't imagine it actually causing a problem with fee estimation. If one of the limits was just an extreme thing that was sustainably being able to hit (due to it requiring continual utxo decrease)  fee estimation could just ignore it
456 2017-07-05T21:43:41  *** Murch has quit IRC
457 2017-07-05T21:43:48  <rhavar> although multiple limits is nasty for transaction selection :(
458 2017-07-05T21:44:08  *** Murch has joined #bitcoin-core-dev
459 2017-07-05T21:44:15  <rhavar> that wasn't* able to be continually hit
460 2017-07-05T21:45:01  <gmaxwell> At least when I've played through these things, it seems to work out such that both limits should always be near getting hit the reason is that if the one limit isn't being hit, miners should pat their blocks creating UTXO to charge up to allow larger blocks later.
461 2017-07-05T21:45:38  <gmaxwell> In general I think anything where it can go negative immediately leads to non-trivial stratigies for income maximization.
462 2017-07-05T21:46:39  <morcos> gmaxwell: one easy change we could still make for 0.15 is if we think the amount you should be willing to discard entirely (just move to fees) should be higher than the DustThreshold
463 2017-07-05T21:47:01  <rhavar> Imagine you had a weight of: -2 for each byte removed from the utxo. 1 weight for each byte in the transaction. And 100 weight for each byte added to the utxo. Say you have two limits: block weight limit of 1e6 and  block size limit of 100MB
464 2017-07-05T21:47:07  <morcos> I like these changes that can be made without redoing coin selection.
465 2017-07-05T21:47:09  <rhavar> it'd be impossible for the block size limit to be hit frequently
466 2017-07-05T21:47:58  <morcos> It would be easy to add a new calculation.  GetDiscardRate  =  max(dustrate, min(discardrate, estimatesmartfee(1000)))
467 2017-07-05T21:48:50  <morcos> then if we configured discardrate default to something > 1 sat/Byte .
468 2017-07-05T21:49:22  <morcos> i'm the king of adding new rate variables though
469 2017-07-05T21:51:02  <morcos> say it was 5 sat/byte
470 2017-07-05T21:51:34  <morcos> at $3000 bitcoin, i think that means if you create an output thats less than 8 cents (or a bit smaller for segwit) that you'll just throw it away, and instead of redoing coin selection, you'll just add it to fee
471 2017-07-05T21:52:31  <morcos> you guys say sane wallets shouldn't create anything close to the dust threshold, but i think that number, which is just 5x dust would be hard to convince people is good idea
472 2017-07-05T21:53:17  <rhavar> what's the alternative though? redoing coin selection?
473 2017-07-05T21:53:22  <morcos> taking the min with estimatesmartfee(1000) though helps avoid it becoming bad if BTC denominated fees
474 2017-07-05T21:53:59  <morcos> drop
475 2017-07-05T21:54:00  <morcos> rhavar: the problem with coin selection, is you don't know if you actually could get a better result
476 2017-07-05T21:54:28  *** chjj has quit IRC
477 2017-07-05T21:54:56  <rhavar> with "redoing coin selection" i mean it would contain the same logic about omitting change
478 2017-07-05T21:55:58  <instagibbs> the coin selection could pick a similar sized set and get to keep the change, instead of dump it
479 2017-07-05T21:56:40  <morcos> i suppose when we redo coin selection you'll first aim for at least min_desired_change (which is now a CENT and we aim for it exactly, but screw that, just at least)
480 2017-07-05T21:56:42  <rhavar> yeah, i think it's strictly better or equal (from a fee perspective, not privacy)
481 2017-07-05T21:57:26  <morcos> if you can't get to min_desired_change, then you'll throw everything you have in there and just take what you get, and if its less than discard (right now just dust) just throw away change
482 2017-07-05T21:57:33  <gmaxwell> morcos: I'm fine with discarding more.  One way we could answer your concenr is making it configurable. Then people who want it different could adjust it.
483 2017-07-05T21:58:30  <morcos> i'll write it up.. it's small
484 2017-07-05T21:59:11  <gmaxwell> morcos: you could use the BNB hurestic: you can throw away up to the cost of creating and spending the change output.
485 2017-07-05T22:00:04  <morcos> gmaxwell: but then you're throwing it away twice
486 2017-07-05T22:00:18  <rhavar> "spending the change output"  how does it know the cost of spending the output? At what fee rate does it use?
487 2017-07-05T22:00:45  <gmaxwell> rhavar: achow101's implementation uses a 1008 block feerate estimate.
488 2017-07-05T22:00:55  <gmaxwell> rhavar: as the feerate.
489 2017-07-05T22:00:58  <rhavar> ah nic
490 2017-07-05T22:00:59  <rhavar> e
491 2017-07-05T22:01:09  <rhavar> same as my code then :D
492 2017-07-05T22:01:17  <gmaxwell> morcos: I don't get the 'throwing it away twice'?
493 2017-07-05T22:01:35  <BlueMatt> lol, morcos' troll game is strong today
494 2017-07-05T22:01:42  <instagibbs> We should never be keeping change that doesn't hit that threshold, the real Q is larger but still not great.
495 2017-07-05T22:01:46  <Murch> gmaxwell: One of the Trezor guys did some more experiments this weekend and found that he got better results by allowing a smaller window of just the change output size
496 2017-07-05T22:02:00  <morcos> well you've already done the coin selection and fee calculation to pay for the change, and now you're also throwing away the change output itself,so you are potentially overpaying the newly needed fee by double the cost of creating the change
497 2017-07-05T22:02:04  <BlueMatt> gmaxwell: what am I being dense about? how does merging txn during a bump cause issues w/ malleability? shouldnt it go the other way if anything?
498 2017-07-05T22:02:19  <BlueMatt> or are you suggesting we should explicitly not support chains in your wallet without segwit (which is true)
499 2017-07-05T22:02:32  <gmaxwell> morcos: ah okay, don't do that.
500 2017-07-05T22:03:41  <gmaxwell> BlueMatt: because you don't know what will get confirmed, will the orignal or the bump get confirmed?  So what you should do is make two transactions: a child and a bump. sign both, announce the child if the bump loses.  (and apply this recursively for more spends)
501 2017-07-05T22:04:08  <gmaxwell> BlueMatt: as soon as malleability enters the picture you can't do this anymore; and you're stuck hoping the user stays online and reenters their keys so you can resign when a malleation happens.
502 2017-07-05T22:04:20  <BlueMatt> what do you care if the child gets confirmed?
503 2017-07-05T22:04:28  <BlueMatt> great! you've saved the attempted-bump in fees?
504 2017-07-05T22:04:49  <BlueMatt> now the user is a bit confused, and may need to bump the child again, but thats ok
505 2017-07-05T22:07:21  *** chjj has joined #bitcoin-core-dev
506 2017-07-05T22:07:22  <morcos> i'm confused now too.  i agree we should not attach a child to a bumper or bumpee.  but what is wrong bumping something that already has a child if the bump is the merge of the parent and child?
507 2017-07-05T22:07:52  <morcos> if the bump loses, i don't think you've done too much harm to the child have you?
508 2017-07-05T22:09:47  <gmaxwell> When you create a _new_ child or a _new_ bump that adds outputs, you must also make children of all the existing ones.
509 2017-07-05T22:10:22  <gmaxwell> Perhaps I'm talking about something a bit more broad than bluematt.
510 2017-07-05T22:12:41  <BlueMatt> I believe you are talking about a very full-featured bumpfee, much more than I am thinking?
511 2017-07-05T22:12:57  <BlueMatt> Though I missed some of the above discussion, just waiting for them to reopen the airport after they closed it due to weather :(
512 2017-07-05T22:13:30  *** talmai has quit IRC
513 2017-07-05T22:18:34  <rhavar> I think it's pretty sane to support  the case of fee bumping a list of transactions, where all of them have no children.
514 2017-07-05T22:18:45  <BlueMatt> would those then get merged, or no?
515 2017-07-05T22:18:48  <rhavar> yeah
516 2017-07-05T22:18:57  <BlueMatt> yea, I agree, but I dont think thats an issue pre-segwit
517 2017-07-05T22:19:10  <rhavar> yeah, i don't see how malleability matters at all
518 2017-07-05T22:19:32  <rhavar> (at least if nothing has descendants)
519 2017-07-05T22:20:14  <gmaxwell> it doesn't matter if nothing has decendants. But BlueMatt was talking about decendants, unless I've misunderstood.
520 2017-07-05T22:20:16  * BlueMatt is kinda missing how it matters in any case, but I'm probably missing some crazy-full-featured feebump scenario that gmaxwell is thinking about
521 2017-07-05T22:20:31  <BlueMatt> i was, but I'm still confused
522 2017-07-05T22:21:07  <rhavar> if there's descendants, there's some super annoying cases. But i don't think anyone is ever going to do that, so i don't think it's worth worrying about
523 2017-07-05T22:21:36  <rhavar> i think it's only worth considering bumping shit without descendants, and i don't think bumping a list of them at once adds much more complexity :D
524 2017-07-05T22:21:59  <gmaxwell> BlueMatt: If you allow decendants comes up.   You pay A  then you bump A.  Then you go to pay B,  if you're going to chainbumb you now need to compute and sign three transactions   A->B, A'->B and AB.
525 2017-07-05T22:22:51  <gmaxwell> BlueMatt: and you can keep applying this for any number of chains and bumps and its all great. until you consider malleability.  E.g. maybe A gets mined but in malleated form, and now your payment to B is invalidated until you restart the wallet and enter your phassphrase.
526 2017-07-05T22:23:31  <gmaxwell> rhavar: I think without malleability there is no big deal on the bumps, just takes some code.  I also think greenaddress does bumps with decendants.
527 2017-07-05T22:23:33  <BlueMatt> well that has nothing to do with bumping
528 2017-07-05T22:23:44  <BlueMatt> thats just the general-case spending-unconfirmed
529 2017-07-05T22:24:05  <BlueMatt> and I dont see why you need to sign A'->B, you're just merging?
530 2017-07-05T22:24:07  <BlueMatt> what is A'?
531 2017-07-05T22:25:17  * BlueMatt -> boarding, bbl when we get off
532 2017-07-05T22:29:27  <morcos> gmaxwell: take a look at the comment I linked above: https://github.com/bitcoin/bitcoin/pull/8456#issuecomment-264734557
533 2017-07-05T22:29:30  <morcos> it's your comment
534 2017-07-05T22:30:04  <morcos> i think what we are talking about is a tx with descendants (or multiple txs each with descendants) and then bumpfee bumping all of them at once
535 2017-07-05T22:30:29  <morcos> the thing we already don't allow, which i agree we should not change, is adding a child to a tx that is a bumper or has been bumped
536 2017-07-05T22:31:01  <morcos> i don't see any issue with bumping a tx with children (presumably if the children are all yours) as long as you also pay all their outputs as well
537 2017-07-05T22:32:57  <gmaxwell> morcos: no, it's a problem with making a child of a transaction that has a bump.
538 2017-07-05T22:33:16  <morcos> ok agreed
539 2017-07-05T22:33:24  <gmaxwell> you can bump something that has a child without any big complexity, but you can't produce a child of anything that has been bumped.
540 2017-07-05T22:34:00  *** tiagotrs has quit IRC
541 2017-07-05T22:35:33  <rhavar> sounds good to me ;D
542 2017-07-05T22:38:28  *** Dyaheon has quit IRC
543 2017-07-05T22:39:36  *** Dyaheon has joined #bitcoin-core-dev
544 2017-07-05T22:50:31  *** Evel-Knievel has quit IRC
545 2017-07-05T22:59:26  *** PaulCapestany has quit IRC
546 2017-07-05T23:00:44  *** chjj has quit IRC
547 2017-07-05T23:01:15  *** chainhead has joined #bitcoin-core-dev
548 2017-07-05T23:08:02  *** Gabo has joined #bitcoin-core-dev
549 2017-07-05T23:11:20  *** Gabo has quit IRC
550 2017-07-05T23:14:03  *** chjj has joined #bitcoin-core-dev
551 2017-07-05T23:27:31  *** handlex has joined #bitcoin-core-dev
552 2017-07-05T23:38:01  *** chjj has quit IRC
553 2017-07-05T23:48:40  *** talmai has joined #bitcoin-core-dev
554 2017-07-05T23:48:46  *** handlex has quit IRC
555 2017-07-05T23:49:29  *** handlex has joined #bitcoin-core-dev
556 2017-07-05T23:51:37  *** chjj has joined #bitcoin-core-dev
557 2017-07-05T23:59:29  *** Chris_Stewart_5 has quit IRC